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. >> 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. thnx. -- 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
