On Thu, Jul 26, 2018 at 5:05 PM, Lucas Stach [off-list ref] wrote:

Am Donnerstag, den 26.07.2018, 16:45 +0530 schrieb Jassi Brar:

quoted

On Thu, Jul 26, 2018 at 4:11 PM, Lucas Stach [off-list ref]
wrote:

quoted

Hi Jassi,

Am Donnerstag, den 26.07.2018, 15:25 +0530 schrieb Jassi Brar:

quoted

On Thu, Jul 26, 2018 at 12:23 PM, Oleksij Rempel

quoted

[off-list ref] wrote:
This are currently tested SoCs with imx-mailbox driver.

quoted

quoted

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.

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?

quoted

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.

quoted

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.