On 2023-11-22 09:21, Krzysztof Kozlowski wrote:
On 22/11/2023 09:09, Chen-Yu Tsai wrote:
On Wed, Nov 22, 2023 at 4:05 PM Krzysztof Kozlowski
<krzysztof.kozlowski@xxxxxxxxxx> wrote:
On 21/11/2023 14:50, Rafał Miłecki wrote:
+Order of Properties in Device Node
+----------------------------------
+
+Following order of properties in device nodes is preferred:
+
+1. compatible
+2. reg
+3. ranges
+4. Standard/common properties (defined by common bindings, e.g.
without
+ vendor-prefixes)
+5. Vendor-specific properties
+6. status (if applicable)
+7. Child nodes, where each node is preceded with a blank line
+
+The "status" property is by default "okay", thus it can be
omitted.
I think it would really help to include position of #address-cells
and
#size-cells here. In some files I saw them above "compatible" that
seems
unintuitive. Some prefer putting them at end which I think makes
sense
as they affect children nodes.
Whatever you choose it'd be just nice to have things consistent.
This is a standard/common property, thus it goes to (4) above.
It's probably a mix, but AFAIK a lot of the device trees in tree have
#*-cells after "status". In some cases they are added in the board
.dts files, not the chip/module .dtsi files.
Existing DTS is not a good example :)
+1 that it makes sense at the end as they affect child nodes.
I still insist that status must be the last, because:
1. Many SoC nodes have address/size cells but do not have any children
(I2C, SPI), so we put useless information at the end.
2. Status should be the final information to say whether the node is
ready or is not. I read the node, check properties and then look at the
end:
a. Lack of status means it is ready.
b. status=disabled means device still needs board
resources/customization
I agree with the "status" belonging to the very end, because it's both
logical and much more readable. Also, "status" is expected to be
modified in the dependent DT files, which makes it kind of volatile and
even more deserving to be placed last.
