On 07/26/2018 02:46 PM, Jassi Brar wrote: > On Thu, Jul 26, 2018 at 5:05 PM, Lucas Stach <l.stach@xxxxxxxxxxxxxx> wrote: >> Am Donnerstag, den 26.07.2018, 16:45 +0530 schrieb Jassi Brar: >>> 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. >>> >>> 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. >> >> Even if it is the same IP core, the SoC integration might have bugs >> that need different behavior from the driver. We've already had that >> case with the i.MX6 SPI controller. >> > For h/w quirks/bugs, a new "has-that-bug" property makes better sense. > Or, if you insist, a new compatible based on the first soc that has > the buggy block. > How do you propose to handle this property in the driver, if once flashed DTB does not contain it? >>> 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. >> >> That's way too late. If we want to keep DTs stable >> > How do you keep the DT stable by explicitly defining every new SoC to > the compatible list in DT, _add_ to the driver.... only to have the > driver absolutely not care which SoC is it? > Which is the situation right now with this patchset. > For sake of simplicity you can assume that a driver can be changed in future, and SoC/board device tree bindings can not be changed ever. -- 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
