dts/board format property node order

[kylebonnici]

This PR addresse the style guide issues to ensure properties are on top on nodes and that properties are sorted as per

(https://docs.kernel.org/devicetree/bindings/dts-coding-style.html)

Order of Properties in Device Node
The following order of properties in device nodes is preferred:

“compatible”
“reg”
“ranges”
Standard/common properties (defined by common bindings, e.g. without vendor-prefixes)
Vendor-specific properties
“status” (if applicable)
Child nodes, where each node is preceded with a blank line

This PR does not address sorting of nodes.

The style guide says

Nodes on any bus, thus using unit addresses for children, shall be ordered by unit address in ascending order. Alternatively for some subarchitectures, nodes of the same type can be grouped together, e.g. all I2C controllers one after another even if this breaks unit address ordering.

If sorting of nodes is also desired, to avoid parsing bindings for linting to determine the bus type, "Nodes on any bus, thus using unit addresses for children, shall be ordered by unit address in ascending order." would be the only feasible solution IMO

[yishai1999]

Is this enforced in the current version of linter?

[kylebonnici]

Is this enforced in the current version of linter?

No not yet PR in the dts-lsp is still pending to be merged depending on the outcome of this PR

i.e. #92334 can go in main, then we can bump up the version of the Linter should we agree on this PR

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[yishai1999]

I think in cases like this status should either be in its own block or the empty line on line 192 should be removed. Either way, status and cs-gpios don't have a connection which would warrant them being in a block of their own. What do you think?

[kylebonnici]

As I see it, currently we have "4 blocks/groups"

Block 1:

• “compatible”
• “reg”
• “ranges”

Block 2:

• Standard/common properties (defined by common bindings, e.g. without vendor-prefixes)

Block 3:

• Vendor-specific properties

Block 4:

• “status” (if applicable)

if we are to do something about status perhaps should do some thing about the other blocks.

I am open to this if this if the coding standard we want to apply.

@nordicjm, @fabiobaltieri, @kartben , @keith-zephyr what are your thoughts

[pdgendt]

Not against any of these changes, but I do think we should have enforcement in CI before doing these cleanups.

EDIT: If we want to enforce these preferred guidelines.

[kartben]

So a challenge with this is that the following guideline is a MAY, not a SHALL: "The following order of properties in device nodes is preferred" ; are you planning on making it a warning in CI checks? This will likely be very verbose for folks though...

[kylebonnici]

So a challenge with this is that the following guideline is a MAY, not a SHALL: "The following order of properties in device nodes is preferred" ; are you planning on making it a warning in CI checks? This will likely be very verbose for folks though...

This was a proof of concept to show what else we can enforce!. Side note, my idea here is to also open the door for us discuss if we want to do more. I am open for more ideas on what can help readability even if not this one.

Back to this PR ... This could be mandatory, an additional flag in the linter/lsp the user may opt in or out of for there code base or non of the above.

I am also not applying the last line of the style guide ...The individual properties inside each group shall use natural sort order by the property name.... which I can also do if required.

I do not think showing warning will be reasonable, as showing a warning is pointless if we do not enforce due to the quantity. Also, a warning hints something Is wrong and if will threat this as a preferred and not SHELL then nothing is wrong.

The issue I personally had with the SHELL vs MAY is that in part of the style guide says 'shall' as ....Nodes on any bus, thus using unit addresses for children, shall be ordered by unit address in ascending order....

while in other case it states preferred... such as ...The following order of properties in device nodes is preferred:...

I will leave it up to you all to decide what is best for the community and what you decide to enforce I will do my best make sure this tooling will respect it inside the linter and lsp.