[PATCH v5 4/4] arm64: dts: fsd: Add Ethernet support for PERIC Block of FSD SoC

[Andrew Lunn]

On Wed, Jan 29, 2025 at 02:49:14PM +0530, Swathi K S wrote:
> 
> 
> > -----Original Message-----
> > From: Krzysztof Kozlowski <krzk at kernel.org>
> > Sent: 28 January 2025 19:48
> > To: Swathi K S <swathi.ks at samsung.com>; robh at kernel.org;
> > davem at davemloft.net; edumazet at google.com; kuba at kernel.org;
> > pabeni at redhat.com; conor+dt at kernel.org; richardcochran at gmail.com;
> > mcoquelin.stm32 at gmail.com; andrew at lunn.ch; alim.akhtar at samsung.com;
> > linux-fsd at tesla.com
> > Cc: netdev at vger.kernel.org; devicetree at vger.kernel.org; linux-
> > kernel at vger.kernel.org; linux-stm32 at st-md-mailman.stormreply.com;
> > linux-arm-kernel at lists.infradead.org; linux-samsung-soc at vger.kernel.org;
> > alexandre.torgue at foss.st.com; peppe.cavallaro at st.com;
> > joabreu at synopsys.com; rcsekar at samsung.com; ssiddha at tesla.com;
> > jayati.sahu at samsung.com; pankaj.dubey at samsung.com;
> > ravi.patel at samsung.com; gost.dev at samsung.com
> > Subject: Re: [PATCH v5 4/4] arm64: dts: fsd: Add Ethernet support for PERIC
> > Block of FSD SoC
> > 
> > On 28/01/2025 11:25, Swathi K S wrote:
> > >
> > >  &pinctrl_pmu {
> > > diff --git a/arch/arm64/boot/dts/tesla/fsd.dtsi
> > b/arch/arm64/boot/dts/tesla/fsd.dtsi
> > > index cc67930ebf78..670f6a852542 100644
> > > --- a/arch/arm64/boot/dts/tesla/fsd.dtsi
> > > +++ b/arch/arm64/boot/dts/tesla/fsd.dtsi
> > > @@ -1027,6 +1027,33 @@
> > >  			phy-mode = "rgmii-id";
> > >  			status = "disabled";
> > >  		};
> > > +
> > > +		ethernet_1: ethernet at 14300000 {
> > 
> > Don't add nodes to the end, because that lead to mess we have there.
> > Squeeze it somewhere where impact on resorting would be the smallest.
> 
> Just to clarify,  inserting the node somewhere in the middle, where it fits alphabetically, would minimize the impact on resorting.
> Is my understanding correct?

I think the coding style says to order them by address. So sort on
14300000.

The issue here is merging patches coming from different subsystems. If
these patches are merged via netdev, and there are other patches for
other devices coming from other subsystem, there is going to be a
merge conflict if they all append to the end. By keeping things
ordered, the chance of a merge conflict is much lower, since the
changes are likely to be separated. So you will find in Linux anything
which can be sorted is sorted. Makefile, Kconfig, order of #includes
etc.

	Andrew