boards: silabs: fix boards DTS files coding style issues

[yishai1999]

Fix board DTS coding style issues to prevent them from spreading when a new board is introduced and uses an existing DTS as a referance.

Issues addressed from Zephyr devicetree style guidelines [1]:

• Don’t insert empty lines before a deindenting };.
• Insert a single empty line to separate nodes at the same hierarchy level.
• status is "okay" by default.
• compatible property comes first in node.
• reg property comes second in node.
• status property comes last in node.
• the rest of the properties within are nodes naturally sorted.
• child nodes are sorted by address or alphabetically if there is no address.

No functional change.

Link: https://docs.zephyrproject.org/latest/contribute/style/devicetree.html [1]

Took inspiration from #90312

[asmellby]

Nice! Thanks for taking the initative to clean things up! I only have some comments/questions when it comes to pinctrl nodes specifically.

[asmellby]

According to the style guidelines:

Use dashes (-) as word separators for node and property names.
Use underscores (_) as word separators in node labels.

This suggests that this should be itm_default: itm-default {. However, that doesn't match with any of the examples in the Pin Control documentation at https://docs.zephyrproject.org/latest/hardware/pinctrl/index.html.

The same documentation also consistently lists the pin selections before the properties that apply to the pins. IMO, it's more readable to consistently have the pin list come as the first child of the pinctrl node and for any pin properties to come after it, rather than having the pin list as a random node in the middle of the properties. But if this is consistent with how the project wants it, I'm not going to protest.

@gmarull @mbolivar As maintainers of pinctrl and devicetree respectively, what are your thoughts on this?

[jerome-pouiller]

the rest of the properties within are nodes naturally sorted.

I feel many people try to go from the most generic attributes to the most specific (with an exception for status): compatible, reg, pinctrl, dma, clock, then device class attributes, then driver specific attributes.

That's said, this is not a big deal.

[yishai1999]

Nice! Thanks for taking the initative to clean things up! I only have some comments/questions when it comes to pinctrl nodes specifically.

Reverted the pins property to be first.

Regarding the - vs _ - We can either wait for people to reply to your comment or do it at another time.

[yishai1999]

the rest of the properties within are nodes naturally sorted.

I feel many people try to go from the most generic attributes to the most specific (with an exception for status): compatible, reg, pinctrl, dma, clock, then device class attributes, then driver specific attributes.

That's said, this is not a big deal.

That makes some sense but unfortunately that's not what the guidelines say so I think that precedes.

[rettichschnidi]

Thanks for the sgrm.dts improvements. Did not check the other changes.

[asmellby]

Found a couple of minor inconsistencies, but that shouldn't block the big improvements for everything else.

[asmellby]

Looks like this one was missed, other #-prefixed properties have been sorted first (using the # rather than the s).

[yishai1999]

Yup. My bad

[asmellby]

Missing blank line before section or these should come before height?

[yishai1999]

According to the guidelines, vendor specific properties like these come last.

[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