Hi Krzysztof Kozlowski, Thanks for the feedback. > Subject: Re: [PATCH v4 1/5] dt-bindings: arm: renesas: Document Renesas > RZ/G2UL SMARC EVK > > 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... OK, What I meant here is pin-mapping of 2 SoC's(RZ/G2UL and RZ/Five) are same on the SoM. > > > > >> 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." Soc specific driver compatible will take care of this. If any quirks to be added Soc-id and revision will take care that. > > The "renesas,smarc-evk" compatible is not the most specific one, because > different configurations have it. It is just a compatible for the carrier board. > > 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. See the examples we have discussed. Geert Do you agree with Krzysztof Kozlowski Suggestion? If we have 2 boards Board-a and Board-B based on SoCX ---------------------------------------------------- Case 1: As per your example with freescale, Enum - Board-a-SoCX - Board-b-SoCX Const - SoCX Case 2: our case Enum - Board-a - Board-b Const - SoCX If Same board used by different SoC's of same SoC faily ==================================== Case 1: As per your example with freescale, Enum - Board-SoCA - Board-SoCB Enum - SoCA - SoCB Const - SoC Case 2: Our case Enum - Board Enum - SoCA - SoCB Const - SoC Cheers, Biju
