Am Donnerstag, den 26.07.2018, 17:16 +0530 schrieb Jassi Brar: > > 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. > Hardware bugs might not be known at the the time the DT is deployed. The DT is not part of the kernel, but might be part of a fixed device firmware. > > > 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. It means we can later, in a newer kernel change the driver to use the compatible to change behavior without the need to update the DT at that point. Regards, Lucas -- 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
