[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <YMw+weFvPxCXbvk+@kroah.com>
Date: Fri, 18 Jun 2021 08:35:45 +0200
From: Greg KH <greg@...ah.com>
To: Bjorn Andersson <bjorn.andersson@...aro.org>
Cc: Matthias Kaehlcke <mka@...omium.org>,
Stephen Rothwell <sfr@...b.auug.org.au>,
Olof Johansson <olof@...om.net>, Arnd Bergmann <arnd@...db.de>,
ARM <linux-arm-kernel@...ts.infradead.org>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
Linux Next Mailing List <linux-next@...r.kernel.org>
Subject: Re: linux-next: manual merge of the usb tree with the arm-soc tree
On Thu, Jun 17, 2021 at 12:30:28PM -0500, Bjorn Andersson wrote:
> On Thu 17 Jun 11:34 CDT 2021, Matthias Kaehlcke wrote:
>
> > On Thu, Jun 17, 2021 at 02:43:46PM +1000, Stephen Rothwell wrote:
> > > Hi all,
> > >
> > > Today's linux-next merge of the usb tree got conflicts in:
> > >
> > > arch/arm64/boot/dts/qcom/sc7180-trogdor-lazor-r0.dts
> > > arch/arm64/boot/dts/qcom/sc7180-trogdor-lazor-r1.dts
> > >
> > > between commit:
> > >
> > > 39441f73d91a ("arm64: dts: qcom: sc7180: lazor: Simplify disabling of charger thermal zone")
> > >
> > > from the arm-soc tree and commit:
> > >
> > > 1da8116eb0c5 ("arm64: dts: qcom: sc7180-trogdor: Add nodes for onboard USB hub")
> > >
> > > from the usb tree.
> > >
> > > I fixed it up (see below) and can carry the fix as necessary. This
> > > is now fixed as far as linux-next is concerned, but any non trivial
> > > conflicts should be mentioned to your upstream maintainer when your tree
> > > is submitted for merging. You may also want to consider cooperating
> > > with the maintainer of the conflicting tree to minimise any particularly
> > > complex conflicts.
> >
> > Thanks Stephen for fixing this up for -next!
> >
> > One option would be to revert 1da8116eb0c5 ("arm64: dts: qcom: sc7180-trogdor:
> > Add nodes for onboard USB hub") from usb-next and land it through the qcom/arm-soc
> > tree with the rest of the SC7180 device tree patches.
> >
> > Greg/Bjorn, does the above sound like a suitable solution to you or do you
> > think it would be better to deal with the conflict in a different way?
>
> Having the dts patch go through the Qualcomm tree instead would resolve
> the issue.
>
> I wasn't aware that the driver code had landed yet, so I haven't merged
> the DT patch, but can do so and include it in the pull request that I'm
> preparing for 5.14.
>
> Greg, does that sound reasonable to you?
I will revert the dts change in my tree now, along with the rest of this
specific series, as it is causing other build issues in linux-next at
the moment. That should resolve the merge issues now.
If you want to take the dts patch through your tree now, that's fine
with me. Or we can wait until after 5.14-rc1 is out, which might make
things easier to handle.
thanks,
greg k-h
Powered by blists - more mailing lists