Hi Krzysztof, On Sat, Apr 2, 2022 at 10:03 PM Krzysztof Kozlowski <krzysztof.kozlowski@xxxxxxxxxx> wrote: > On 02/04/2022 21:54, Biju Das wrote: > >> I understand that carrier board is the same, so the SoM differs. > > > > For R9A07G043 case, even SoM is same, only SOC differs. > > I assumed that you cannot have same SoMs with different SoCs... > > > > >> In your > >> model to figure out what type of hardware is it, your choice is to compare > >> two compatibles: > >> renesas,smarc-evk + renesas,r9a07g043u11 > >> > >> If user-space compares only last compatible, it get's only SMARC, so it > >> does not know on what hardware it runs. > > > > But Here user-space can easily identify the H/W with existing scheme. See the logs from user-space. > > > > / # for i in machine family soc_id revision; do echo -n "$i: "; cat /sys/devices/soc0/$i;done > > machine: Renesas SMARC EVK based on r9a07g043u11 > > family: RZ/G2UL > > soc_id: r9a07g043 > > revision: 0 > > 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.
