Codify array values syntax

[konradybcio]

Currently dtc happily eats both:

val = <0 1 2 3 4 5 6 7>;

in the same way as:

val = <0 1>, <2 3>, <4 5>, <6 7>;

so long as the -cells values match.

Requiring the second format (one entry per <...>) would allow to dynamically derive -cells values and reduce boilerplate (by e.g. defaulting to #address-cells == #size-cells == <2> when ARRAY_SIZE(reg) is a multiple of 4 etc., while still allowing to manually override it where it's not obvious.

[robherring]

There's 2 things here I think. Just defining best practice or .dts coding style. That would be good I think, but I don't think that belongs in the spec (though could be an appendix). This is also something tools can check, so I'd rather see tools for this first rather than an appendix for people to ignore.

We went down this path effectively trying to enforce some bracketing practice when dtschema relied on bracketing. There's a bunch of patches changing .dts files for that. That hit a roadblock in dtc when I tried to output brackets using the knowledge the dtc checks already has. That was needed when checking of DTBs was needed where we don't have any DTS and any and all bracketing is lost. Anyway, any checks of bracketing are gone, but I would like to see some separate tool do that and other things. A DTS linter essentially (which has come up before: devicetree-org/dt-schema#18).

The 2nd thing here sounds like generating #foo-cells based on brackets (or from phandles in the phandle+args style bindings). Like dtschema, that's probably a deadend in dtc. I think it falls into a larger topic of defining a higher level syntax than DTS (or DTSv2 maybe). The systemdt folks are doing some of this I think including just what you described. Take a look at lopper or talk to @zeddii perhaps.

[konradybcio]

I was doing the dishes and suddenly had this idea... things like this could be required in a theoretical /dts-v2/, which we could perhaps open a meta discussion issue for.. Now that there are more eyes on shipping actual products with what we consider "proper" (a.k.a. in accordance to the upstream linux standards & dt-bindings) DTs that adhere to the backwards compatibility and ACPI (more-or-less-)equivalence, this could be a good forum for discussing possible evolutions.

There are some rough edges (like this one) that could be polished if things got less ambiguous, while retaining compatibility with what's here today. Another thing that immediately comes to mind is going little endian.