On 02/04/2022 22:48, Biju Das wrote: > 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. soc_id is independent mechanism and is not related to the discussion whether Devicetree binding is correct or not. Soc specific compatible in the driver does not solve this case, because the top level compatible describes the machine. In this case the machine is SMARC and it is indistinguishable from other SMARC machines, even though they are quite different. > >> >> 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. Yes, I understand that and you we agreed on that before. The last compatible (counting from the right in the list), according to devicetree, is the most specific compatible describing the device. Using here compatible for a generic carrier board is therefore not correct from the Devicetree point of view. > >> >> 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 No, that case will look different: Const - Board-SoCA - SoCA - SoC Const - Board-SoCB - SoCB - SoC > > Case 2: Our case > Enum > - Board > Enum > - SoCA > - SoCB > Const > - SoC > > Cheers, > Biju Best regards, Krzysztof
