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. 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. Best regards, Krzysztof
