Device tree node order sort tool

Device tree node order sort tool

[Frank Li]

All:
	I write a simple tools to sort device tree to make sure nodes and
properties sort as correct order.
	https://github.com/lznuaa/dt-format

	There are many dt files, which have node order trivial issue, when
try to upstream. To reduce reviewer's time, dt-format can help correct the
order.

	I just want to make sure my understand about node order is correct.

	Rule 1: node@hexvalue,  	order by hexvalue
	Rule 2: label: node,  		order by node name
	Rule 3: node, 			order by node name
	Rule 3: &label			order by label
	Rule 4: children node already after property
	Rule 5: "status" always is last one.
	Rule 6: property order as below list[unfinished], otherwise, order
	        by name.

compatible
reg
reg-names
ranges
#interrupt-cells
interrupt-controller
interrupts
interrupt-names
#gpio-cells
gpio-controller
gpio-ranges
#address-cells
#size-cells
clocks
clock-names
assigned-clocks
assigned-clock-parents
assigned-clock-rates
dmas
dma-names

Frank

Re: Device tree node order sort tool

[Krzysztof Kozlowski]

On Tue, Sep 17, 2024 at 11:43:53AM -0400, Frank Li wrote:
> All:
> 	I write a simple tools to sort device tree to make sure nodes and
> properties sort as correct order.
> 	https://github.com/lznuaa/dt-format
> 
> 	There are many dt files, which have node order trivial issue, when
> try to upstream. To reduce reviewer's time, dt-format can help correct the
> order.
> 

Hey Frank,

Cool idea!

> 	I just want to make sure my understand about node order is correct.
> 
> 	Rule 1: node@hexvalue,  	order by hexvalue
> 	Rule 2: label: node,  		order by node name
> 	Rule 3: node, 			order by node name
> 	Rule 3: &label			order by label

Some subsystems have different ordering, like expressed in DTS coding
style:
1. DTS: keep order of DTSI file
2. DTSI: group similar nodes together (e.g. serial engines).

> 	Rule 4: children node already after property
> 	Rule 5: "status" always is last one.
> 	Rule 6: property order as below list[unfinished], otherwise, order
> 	        by name.
> 
> compatible
> reg
> reg-names
> ranges

Up to here everything above seems about right, except above caveats.

> #interrupt-cells
> interrupt-controller
> interrupts
> interrupt-names
> #gpio-cells
> gpio-controller
> gpio-ranges
> #address-cells
> #size-cells
> clocks
> clock-names
> assigned-clocks
> assigned-clock-parents
> assigned-clock-rates
> dmas
> dma-names

I don't think we have defined order for these.

Best regards,
Krzysztof

Re: Device tree node order sort tool

[Conor Dooley]

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

On Wed, Sep 18, 2024 at 10:03:32AM +0200, Krzysztof Kozlowski wrote:
> On Tue, Sep 17, 2024 at 11:43:53AM -0400, Frank Li wrote:
> > All:
> > 	I write a simple tools to sort device tree to make sure nodes and
> > properties sort as correct order.
> > 	https://github.com/lznuaa/dt-format
> > 
> > 	There are many dt files, which have node order trivial issue, when
> > try to upstream. To reduce reviewer's time, dt-format can help correct the
> > order.
> > 
> 
> Hey Frank,
> 
> Cool idea!

I concur, it is a useful idea.

> > 	I just want to make sure my understand about node order is correct.
> > 
> > 	Rule 1: node@hexvalue,  	order by hexvalue
> > 	Rule 2: label: node,  		order by node name
> > 	Rule 3: node, 			order by node name
> > 	Rule 3: &label			order by label
> 
> Some subsystems have different ordering, like expressed in DTS coding
> style:
> 1. DTS: keep order of DTSI file
> 2. DTSI: group similar nodes together (e.g. serial engines).

I think it's fine to pick whatever is used by іmx/nxp and start with
that style, get something working and then decide based on whether or
not there are many users (or interest) if it is worth allowing the
"style" to be configured.

> 
> > 	Rule 4: children node already after property
> > 	Rule 5: "status" always is last one.
> > 	Rule 6: property order as below list[unfinished], otherwise, order
> > 	        by name.
> > 
> > compatible
> > reg
> > reg-names
> > ranges
> 
> Up to here everything above seems about right, except above caveats.
> 
> > #interrupt-cells
> > interrupt-controller
> > interrupts
> > interrupt-names
> > #gpio-cells
> > gpio-controller
> > gpio-ranges
> > #address-cells
> > #size-cells
> > clocks
> > clock-names
> > assigned-clocks
> > assigned-clock-parents
> > assigned-clock-rates
> > dmas
> > dma-names
> 
> I don't think we have defined order for these.

We may not, but I don't think there's anything wrong with the order that
Frank has chosen here being a ‶default".
That said, I'd not enjoy getting a bunch of patches for the platforms
that I maintain redoing things in this order, so it is worth asking the
platform maintainer for their take on whether it should be used for
anything other than new code, before sending a rake of patches.

Cheers,
Conor.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

Re: Device tree node order sort tool

[Frank Li]

On Wed, Sep 18, 2024 at 09:17:37AM +0100, Conor Dooley wrote:
> On Wed, Sep 18, 2024 at 10:03:32AM +0200, Krzysztof Kozlowski wrote:
> > On Tue, Sep 17, 2024 at 11:43:53AM -0400, Frank Li wrote:
> > > All:
> > > 	I write a simple tools to sort device tree to make sure nodes and
> > > properties sort as correct order.
> > > 	https://github.com/lznuaa/dt-format
> > >
> > > 	There are many dt files, which have node order trivial issue, when
> > > try to upstream. To reduce reviewer's time, dt-format can help correct the
> > > order.
> > >
> >
> > Hey Frank,
> >
> > Cool idea!
>
> I concur, it is a useful idea.
>
> > > 	I just want to make sure my understand about node order is correct.
> > >
> > > 	Rule 1: node@hexvalue,  	order by hexvalue
> > > 	Rule 2: label: node,  		order by node name
> > > 	Rule 3: node, 			order by node name
> > > 	Rule 3: &label			order by label
> >
> > Some subsystems have different ordering, like expressed in DTS coding
> > style:
> > 1. DTS: keep order of DTSI file
> > 2. DTSI: group similar nodes together (e.g. serial engines).
>
> I think it's fine to pick whatever is used by іmx/nxp and start with
> that style, get something working and then decide based on whether or
> not there are many users (or interest) if it is worth allowing the
> "style" to be configured.
>
> >
> > > 	Rule 4: children node already after property
> > > 	Rule 5: "status" always is last one.
> > > 	Rule 6: property order as below list[unfinished], otherwise, order
> > > 	        by name.
> > >
> > > compatible
> > > reg
> > > reg-names
> > > ranges
> >
> > Up to here everything above seems about right, except above caveats.
> >
> > > #interrupt-cells
> > > interrupt-controller
> > > interrupts
> > > interrupt-names
> > > #gpio-cells
> > > gpio-controller
> > > gpio-ranges
> > > #address-cells
> > > #size-cells
> > > clocks
> > > clock-names
> > > assigned-clocks
> > > assigned-clock-parents
> > > assigned-clock-rates
> > > dmas
> > > dma-names
> >
> > I don't think we have defined order for these.

It should be good for less special case. I got some comments during dts
review such as

	#gpio-cells just before gpio-controller, the same as
#interrupt-cells before interrupt-controller.
	*-names after *.

	Does above rule is widely adaptive?

Frank

>
> We may not, but I don't think there's anything wrong with the order that
> Frank has chosen here being a ‶default".
> That said, I'd not enjoy getting a bunch of patches for the platforms
> that I maintain redoing things in this order, so it is worth asking the
> platform maintainer for their take on whether it should be used for
> anything other than new code, before sending a rake of patches.

At beginning, I just want to compare upstream dts and downstream dts
easily. I supposed just help new code.

>
> Cheers,
> Conor.

Re: Device tree node order sort tool

[Shawn Guo]

On Wed, Sep 18, 2024 at 09:17:37AM +0100, Conor Dooley wrote:
> That said, I'd not enjoy getting a bunch of patches for the platforms
> that I maintain redoing things in this order, so it is worth asking the
> platform maintainer for their take on whether it should be used for
> anything other than new code, before sending a rake of patches.

+1

I do not like to receive tons of patches churning the existing files
with such order changes.

Shawn

Re: Device tree node order sort tool

[Frank Li]

On Thu, Sep 26, 2024 at 05:04:39PM +0800, Shawn Guo wrote:
> On Wed, Sep 18, 2024 at 09:17:37AM +0100, Conor Dooley wrote:
> > That said, I'd not enjoy getting a bunch of patches for the platforms
> > that I maintain redoing things in this order, so it is worth asking the
> > platform maintainer for their take on whether it should be used for
> > anything other than new code, before sending a rake of patches.
>
> +1
>
> I do not like to receive tons of patches churning the existing files
> with such order changes.

Yes, I agree! Can you focus on checking if order is what you want? Some
rule is quite complex. I don't intent to change existed one.

Frank

>
> Shawn
>

Re: Device tree node order sort tool

[Krzysztof Kozlowski]

On 26/09/2024 11:04, Shawn Guo wrote:
> On Wed, Sep 18, 2024 at 09:17:37AM +0100, Conor Dooley wrote:
>> That said, I'd not enjoy getting a bunch of patches for the platforms
>> that I maintain redoing things in this order, so it is worth asking the
>> platform maintainer for their take on whether it should be used for
>> anything other than new code, before sending a rake of patches.
> 
> +1
> 
> I do not like to receive tons of patches churning the existing files
> with such order changes.

Yeah, it would seriously affect backporting and git blame.

Best regards,
Krzysztof