[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <YMuGtNTvZKHx4Rhr@yoga>
Date: Thu, 17 Jun 2021 12:30:28 -0500
From: Bjorn Andersson <bjorn.andersson@...aro.org>
To: Matthias Kaehlcke <mka@...omium.org>
Cc: Stephen Rothwell <sfr@...b.auug.org.au>, Greg KH <greg@...ah.com>,
Olof Johansson <olof@...om.net>, Arnd Bergmann <arnd@...db.de>,
ARM <linux-arm-kernel@...ts.infradead.org>,
Greg Kroah-Hartman <gregkh@...uxfoundation.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 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?
Regards,
Bjorn
Powered by blists - more mailing lists