Re: [PATCH v7 4/6] dt-bindings: mailbox: imx-mu: add i.MX6SX and i.MX7S SoCs.

[Vladimir Zapolskiy <vladimir_zapolskiy@mentor.com>]

On 07/26/2018 02:52 PM, Jassi Brar wrote:
> On Thu, Jul 26, 2018 at 5:14 PM, Vladimir Zapolskiy
> <vladimir_zapolskiy@mentor.com> wrote:
>> On 07/26/2018 02:15 PM, Jassi Brar wrote:
>>> On Thu, Jul 26, 2018 at 4:11 PM, Lucas Stach <l.stach@pengutronix.de> wrote:
>>>> Hi Jassi,
>>>>
>>>> Am Donnerstag, den 26.07.2018, 15:25 +0530 schrieb Jassi Brar:
>>>>> On Thu, Jul 26, 2018 at 12:23 PM, Oleksij Rempel
>>>>>> <o.rempel@pengutronix.de> wrote:
>>>>>> This are currently tested SoCs with imx-mailbox driver.
>>>>>>
>>>>>>>> Signed-off-by: Oleksij Rempel <o.rempel@pengutronix.de>
>>>>>> ---
>>>>>>  Documentation/devicetree/bindings/mailbox/fsl,mu.txt | 2 +-
>>>>>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>>>>>
>>>>>> diff --git a/Documentation/devicetree/bindings/mailbox/fsl,mu.txt b/Documentation/devicetree/bindings/mailbox/fsl,mu.txt
>>>>>> index 113d6ab931ef..5616d2afca45 100644
>>>>>> --- a/Documentation/devicetree/bindings/mailbox/fsl,mu.txt
>>>>>> +++ b/Documentation/devicetree/bindings/mailbox/fsl,mu.txt
>>>>>> @@ -18,7 +18,7 @@ Messaging Unit Device Node:
>>>>>>  Required properties:
>>>>>>  -------------------
>>>>>>  - compatible : should be "fsl,<chip>-mu", the supported chips include
>>>>>> -               imx8qxp, imx8qm.
>>>>>> +               imx6sx, imx7s, imx8qxp, imx8qm.
>>>>>>
>>>>>
>>>>> This is not scalable. Do we add every new SoC that contains the same controller?
>>>>
>>>> Yes, we do. This is a policy direction from the DT maintainers.
>>>>
>>> I would love to read the post/documentation.
>>
>> Some notes are found in Documentation/devicetree/bindings/ABI.txt
>>
> Thanks. I have been through the ABI.txt.
> 
>> To guarantee "a stable binding" of a compatible property, to avoid
>> unintentionally added incompatibilities and to fix a list of supported
>> compatibles in the device driver code there should be a SoC specific
>> compatible value in the list of 'compatible' property elements.
>>
>>> Consider the same h/w - controller and platforms, but only the the MU
>>> chapter said the controller name is, say, 'MU121'. I am sure now you
>>> will see it correct to call it "fsl,mu121" compatible.
>>> What changed? just the name, right?
>>>
>>>
>>>> If we
>>>> ever going to want to validate DTs against the binding, all compatibles
>>>> used in the DTs must be specified in the binding.
>>>>
>>>> As we can't really tell if the controller is exactly the same or even
>>>> has some SoC integration bugs, we generally add a new compatible for
>>>> each SoC to key off any workarounds necessary in the driver without the
>>>> need to change the DTs, breaking compatibility.
>>>>
>>> I think if the h/w resources and behaviour remain the same and the
>>> documentation does not call it by a different name -- it is safe to
>>> assume its the same IP. Especially when the driver is absolutely
>>> indifferent to the 5 SoC names.
>>>
>>> If/when we find the controller changes, we could revisit the binding
>>> and add another compatible option and modify the driver to catch that
>>> and adapt.
>>>
>>
>> Unfortunately it does not work well this way due to limited possibilities
>> to distinugush different device IPs on different SoCs, if identical
>> compatibles are given in both cases, and often it is not obvious that
>> two IPs are different.
>>
> Please note the submitted driver absolutely don't care which of the
> five SoCs it is.

True.

> In other words, all these SoCs have the same controller.

False :)

> So its about have just one compatible right now, and add more if some
> new SoC comes with a variation of the controller.
> 

True. The driver will be changed in this case, unfortunately the bindings
are not so volatile.

--
Best wishes,
Vladimir