linux-next: manual merge of the phy-next tree with the gcom tree

linux-next: manual merge of the phy-next tree with the gcom tree

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 813 bytes --]

Hi all,

Today's linux-next merge of the phy-next tree got a conflict in:

  arch/arm64/boot/dts/qcom/apq8096-db820c.dtsi

between commit:

  442ee1fc60c4 ("arm64: dts: qcom: Drop unneeded extra device-specific includes")

from the gcom tree and commit:

  956bbf2a94e8 ("arm64: dts: qcom: Add missing vdd-supply for QUSB2 PHY")

from the phy-next tree.

I fixed it up (the former removed the file, so I did that) 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.

-- 
Cheers,
Stephen Rothwell

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: linux-next: manual merge of the phy-next tree with the gcom tree

[Stephan Gerhold]

Hi,

On Tue, Oct 26, 2021 at 03:44:15PM +1100, Stephen Rothwell wrote:
> Hi all,
> 
> Today's linux-next merge of the phy-next tree got a conflict in:
> 
>   arch/arm64/boot/dts/qcom/apq8096-db820c.dtsi
> 
> between commit:
> 
>   442ee1fc60c4 ("arm64: dts: qcom: Drop unneeded extra device-specific includes")
> 
> from the gcom tree and commit:
> 
>   956bbf2a94e8 ("arm64: dts: qcom: Add missing vdd-supply for QUSB2 PHY")
> 
> from the phy-next tree.
> 

Sorry about that.

> I fixed it up (the former removed the file, so I did that) and can

The commit actually simply moves all of apq8096-db820c.dtsi into
apq8096-db820c.dts. So we should make sure that the vdd-supply added in
956bbf2a94e8 ("arm64: dts: qcom: Add missing vdd-supply for QUSB2 PHY")
ends up in almost the same position in apq8096-db820c.dts instead.

But I'm confused why the arm64 dts commit is in the phy-next tree. There
is no compile time dependency between it and the related phy commits so
it could have just been applied to the qcom tree to avoid this conflict.

And actually Vinod wrote 2 minutes after applying this patch that Bjorn
should take it through the qcom tree:

https://lore.kernel.org/linux-arm-msm/YVwDbUC5WUHmcRJh@matsya/

Vinod, did you apply it accidentally or am I missing something here? :)

Thanks,
Stephan

Re: linux-next: manual merge of the phy-next tree with the gcom tree

[Vinod Koul]

On 26-10-21, 08:28, Stephan Gerhold wrote:
> Hi,
> 
> On Tue, Oct 26, 2021 at 03:44:15PM +1100, Stephen Rothwell wrote:
> > Hi all,
> > 
> > Today's linux-next merge of the phy-next tree got a conflict in:
> > 
> >   arch/arm64/boot/dts/qcom/apq8096-db820c.dtsi
> > 
> > between commit:
> > 
> >   442ee1fc60c4 ("arm64: dts: qcom: Drop unneeded extra device-specific includes")
> > 
> > from the gcom tree and commit:
> > 
> >   956bbf2a94e8 ("arm64: dts: qcom: Add missing vdd-supply for QUSB2 PHY")
> > 
> > from the phy-next tree.
> > 
> 
> Sorry about that.
> 
> > I fixed it up (the former removed the file, so I did that) and can
> 
> The commit actually simply moves all of apq8096-db820c.dtsi into
> apq8096-db820c.dts. So we should make sure that the vdd-supply added in
> 956bbf2a94e8 ("arm64: dts: qcom: Add missing vdd-supply for QUSB2 PHY")
> ends up in almost the same position in apq8096-db820c.dts instead.
> 
> But I'm confused why the arm64 dts commit is in the phy-next tree. There
> is no compile time dependency between it and the related phy commits so
> it could have just been applied to the qcom tree to avoid this conflict.
> 
> And actually Vinod wrote 2 minutes after applying this patch that Bjorn
> should take it through the qcom tree:
> 
> https://lore.kernel.org/linux-arm-msm/YVwDbUC5WUHmcRJh@matsya/
> 
> Vinod, did you apply it accidentally or am I missing something here? :)

So dts was supposed to go thru qcom tree, I guess I missed giving right
args to b4!

Fixed by dropping this

Thanks
-- 
~Vinod