Re: [PATCH v4 1/5] dt-bindings: arm: renesas: Document Renesas RZ/G2UL SMARC EVK

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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.

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.


Best regards,
Krzysztof



[Index of Archives]     [Device Tree Compilter]     [Device Tree Spec]     [Linux Driver Backports]     [Video for Linux]     [Linux USB Devel]     [Linux PCI Devel]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Yosemite Backpacking]


  Powered by Linux