[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <CAMdYzYqMgoOKuBw9gKuybcoGxiGYtwf3aA07C9Mqvq2gjB47rw@mail.gmail.com>
Date: Wed, 2 Mar 2022 13:24:24 -0500
From: Peter Geis <pgwipeout@...il.com>
To: Rob Herring <robh+dt@...nel.org>
Cc: Vinod Koul <vkoul@...nel.org>,
Kishon Vijay Abraham I <kishon@...com>,
"open list:GENERIC PHY FRAMEWORK" <linux-phy@...ts.infradead.org>,
Heiko Stuebner <heiko@...ech.de>,
Johan Jonker <jbx6244@...il.com>,
Jianqun Xu <jay.xu@...k-chips.com>,
Tobias Schramm <t.schramm@...jaro.org>,
Michael Riesch <michael.riesch@...fvision.net>,
devicetree <devicetree@...r.kernel.org>,
linux-arm-kernel <linux-arm-kernel@...ts.infradead.org>,
"open list:ARM/Rockchip SoC..." <linux-rockchip@...ts.infradead.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] dt-bindings: Revert "dt-bindings: soc: grf: add naneng
combo phy register compatible"
On Wed, Mar 2, 2022 at 12:34 PM Rob Herring <robh+dt@...nel.org> wrote:
>
> On Wed, Mar 2, 2022 at 11:25 AM Peter Geis <pgwipeout@...il.com> wrote:
> >
> > On Wed, Mar 2, 2022 at 12:14 PM Vinod Koul <vkoul@...nel.org> wrote:
> > >
> > > On 02-03-22, 11:04, Rob Herring wrote:
> > > > On Wed, Mar 2, 2022 at 8:34 AM Vinod Koul <vkoul@...nel.org> 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 <vkoul@...nel.org>
> > > > > ---
> > > > > 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
Powered by blists - more mailing lists