On Wed, Mar 2, 2022 at 11:25 AM Peter Geis <[email protected]> wrote:
>
> On Wed, Mar 2, 2022 at 12:14 PM Vinod Koul <[email protected]> wrote:
> >
> > On 02-03-22, 11:04, Rob Herring wrote:
> > > On Wed, Mar 2, 2022 at 8:34 AM Vinod Koul <[email protected]> wrote:
> > > >
> > > > This reverts commit b3df807e1fb0 ("dt-bindings: soc: grf: add naneng
> > > > combo phy register compatible") as that was wrongly merged, so better to
> > > > drop the wrong patch
> > > >
> > > > Signed-off-by: Vinod Koul <[email protected]>
> > > > ---
> > > > I am applying this to phy-next to fix the issue
> > >
> > > Reverting will just cause a different warning that it is undocumented.
> >
> > Right, but a patch for that would fix that
> >
> > > The fix in the other thread won't apply either if you revert.
> >
> > It is not applying for me, so that needs to be updated anyways..
>
> It seems phy-next has fallen out of sync with -next.
> It's missing this patch:
> https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/Documentation/devicetree/bindings/soc/rockchip/grf.yaml?h=next-20220302&id=7dbb47d64acf4aac131a2aaade726913aa62abe7
That is not how things work. linux-next is a tree that no one can
apply patches to (in the worst case like this one). It's useful for
integration testing and a shortcut for getting a maintainer's tree,
but should not be the basis for patches to the lists. You should
generally use the last rc1 or a maintainer's tree when there is a
known dependency. Using a stable base means 'git am -3' works and the
merge tools work rather than git just failing to apply anything.
Rob
On Wed, Mar 2, 2022 at 12:34 PM Rob Herring <[email protected]> wrote:
>
> On Wed, Mar 2, 2022 at 11:25 AM Peter Geis <[email protected]> wrote:
> >
> > On Wed, Mar 2, 2022 at 12:14 PM Vinod Koul <[email protected]> wrote:
> > >
> > > On 02-03-22, 11:04, Rob Herring wrote:
> > > > On Wed, Mar 2, 2022 at 8:34 AM Vinod Koul <[email protected]> wrote:
> > > > >
> > > > > This reverts commit b3df807e1fb0 ("dt-bindings: soc: grf: add naneng
> > > > > combo phy register compatible") as that was wrongly merged, so better to
> > > > > drop the wrong patch
> > > > >
> > > > > Signed-off-by: Vinod Koul <[email protected]>
> > > > > ---
> > > > > I am applying this to phy-next to fix the issue
> > > >
> > > > Reverting will just cause a different warning that it is undocumented.
> > >
> > > Right, but a patch for that would fix that
> > >
> > > > The fix in the other thread won't apply either if you revert.
> > >
> > > It is not applying for me, so that needs to be updated anyways..
> >
> > It seems phy-next has fallen out of sync with -next.
> > It's missing this patch:
> > https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/Documentation/devicetree/bindings/soc/rockchip/grf.yaml?h=next-20220302&id=7dbb47d64acf4aac131a2aaade726913aa62abe7
>
> That is not how things work. linux-next is a tree that no one can
> apply patches to (in the worst case like this one). It's useful for
> integration testing and a shortcut for getting a maintainer's tree,
> but should not be the basis for patches to the lists. You should
> generally use the last rc1 or a maintainer's tree when there is a
> known dependency. Using a stable base means 'git am -3' works and the
> merge tools work rather than git just failing to apply anything.
I apologize, as I'm not the progenitor of the original patch or the
merge conflict I'm missing insight here.
My series is dependent on patches that were pulled in several trees
and the only place they are all currently available is in -next.
I attempted to correct the merge issue in my series, but I don't know
how I would do so when it needs to be based on multiple trees to be
correct.
I will wait until this all settles down and resubmit based on 5.18-rc1
Respectfully,
Peter
>
> Rob