On 07/26/2018 02:52 PM, Jassi Brar wrote: > On Thu, Jul 26, 2018 at 5:14 PM, Vladimir Zapolskiy > <vladimir_zapolskiy@xxxxxxxxxx> wrote: >> On 07/26/2018 02:15 PM, Jassi Brar wrote: >>> On Thu, Jul 26, 2018 at 4:11 PM, Lucas Stach <l.stach@xxxxxxxxxxxxxx> 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@xxxxxxxxxxxxxx> wrote: >>>>>> This are currently tested SoCs with imx-mailbox driver. >>>>>> >>>>>>>> Signed-off-by: Oleksij Rempel <o.rempel@xxxxxxxxxxxxxx> >>>>>> --- >>>>>> 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 -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
