> Subject: Re: [PATCH v4 1/5] dt-bindings: arm: renesas: Document Renesas > RZ/G2UL SMARC EVK > > On 04/04/2022 14:29, Geert Uytterhoeven wrote: > >> > >> User-space is one example. We don't limit to this. Anyway, the > >> compatible is the main way to check it. Machine is just test, not > >> compatible, not part of ABI. soc_id and revision could help, but > >> these are separate ABIs. They can be not compiled-in and then you > >> have only compatible. > >> > >> Regardless whether there is another way for user-space to figure out > >> hardware, it does not change the fact that such usage of compatibles > >> does not look correct with Devicetree spec. > >> "...They > >> allow a device to express its compatibility with a family of similar > >> devices, potentially allowing a single device driver to match > >> against several devices." > >> > >> The "renesas,smarc-evk" compatible is not the most specific one, > >> because different configurations have it. > > > > From the letter of the spec, this is indeed not valid. > > It is also invalid from logical meaning of compatibles... The generic > compatible (SMARC board) is not compatible with a specific SoC. It's the > other way around. > > > However, we started doing this several years ago, as the various > > variants of the Salvator-X(S) and ULCB boards are identical, and just > > differ in SoC (actually SiP) mounted. > > > > E.g. arch/arm64/boot/dts/renesas/r8a77951-salvator-xs.dts has > > compatible = "renesas,salvator-xs", "renesas,r8a7795". > > > > While we could add e.g. "renesas,salvator-xs-r8a7791", doing so would > > inflate the bindings a lot. Rob, Any thoughts on this topic? > > That what is actually happening for example in SoM-like cases on NXP. I > understand that it grows, but that's why we have schema to find mistakes. > :) > > >> Again - you intend to use a pair or even a triple of compatibles to > >> uniquely identify type of hardware. I don't think it is correct - the > >> final, most specific compatible, uniquely identifies the hardware. > >> All other compatibles are just for fallback. > > > > And what to do when adding more DT overlays for expansion boards? > > This would become unmanageable soon. > > There are two topics here: > 1. Whether we should follow DT spec. If no, why Renesas is special and for > other cases we follow DT spec? "Unmanageable" is not the answer here, > because other platforms will have the same problem. > > 2. If the answer for above is yes, we follow DT spec, then the question is > how to deal with overlays. In current code - I don't know. Long term, > maybe we need a way to append to existing compatible (to extend it)? > Some expansion boards do not need to change top level compatible, because > they only add constrained features (like Arduino shields with some > regulator). You just add it to DT and presence of new compatible, e.g. of > regulator, is enough. You do not need to change the top level compatible. > Does the rules for compatible values (most to least descriptive) also apply to the root node? Cheers, Biju
