linux-kernel - Re: [PATCH] dt-bindings: mmc: fsl-imx-esdhc: allow more compatible combinations

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <20230110001557.204dd5da@aktux>
Date:   Tue, 10 Jan 2023 00:15:57 +0100
From:   Andreas Kemnade <andreas@...nade.info>
To:     Rob Herring <robh@...nel.org>
Cc:     Krzysztof Kozlowski <krzysztof.kozlowski@...aro.org>,
        ulf.hansson@...aro.org, krzysztof.kozlowski+dt@...aro.org,
        shawnguo@...nel.org, s.hauer@...gutronix.de, kernel@...gutronix.de,
        festevam@...il.com, linux-imx@....com, linux-mmc@...r.kernel.org,
        devicetree@...r.kernel.org, linux-arm-kernel@...ts.infradead.org,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH] dt-bindings: mmc: fsl-imx-esdhc: allow more compatible
 combinations

Hi Rob,

On Sun, 8 Jan 2023 16:46:33 -0600
Rob Herring <robh@...nel.org> wrote:

> A is either compatible with B or it isn't.

I think English and many natural languages allow to use the adjective
in a non-black and white way to express things. So there can be things
more compatible than others with certain levels of "gray" in between.
But "compatible" in an artifical language like the devicetree can of course
be more restrictive, so there needs to be a certian level of gray where the
limit needs to be defined.The definition you give below.
Thanks for that.

> You can look at that from 
> the h/w perspective and client/OS perspective. From the h/w side, is the 
> h/w interface the same or only has additions which can be ignored? On 
> the client side, the question is whether a client that only understands 
> B could use A's h/w without change. Looking at the match data is a 
> good indicator of that for Linux.

It seems that from a Linux client perspective that is a no in different
cases, so B is not compatible.

> It's also possible the answer is 
> different for different clients, but we only need 1 client that could 
> benefit from compatibility.
> 
On U-Boot side things seem to look different, since high speed modes
are not enabled at all and pm is not done that much, so no quirks needed
for that.
Looking at recent mainline u-boot.
       { .compatible = "fsl,imx51-esdhc", },
        { .compatible = "fsl,imx53-esdhc", },
        { .compatible = "fsl,imx6ul-usdhc", },
        { .compatible = "fsl,imx6sx-usdhc", },
        { .compatible = "fsl,imx6sl-usdhc", },
        { .compatible = "fsl,imx6q-usdhc", },

So U-Boot will benefit from that additional compatible for fsl,imx6[su]ll-usdhc.

The first list of compatibles in U-Boot commit (96f0407b00f) was:
       { .compatible = "fsl,imx6ul-usdhc", },
       { .compatible = "fsl,imx6sx-usdhc", },
       { .compatible = "fsl,imx6sl-usdhc", },
       { .compatible = "fsl,imx6q-usdhc", },
       { .compatible = "fsl,imx7d-usdhc", },

So replacing imx5X fallback compatibles with imx6something might be
helpful for that old U-Boot. But I cannot fully jugde that,
so I will not touch. 

Well, I could also delete entries of this list and push a bunch of U-Boot forks
somewhere, so creating a large number of different clients, which would then
justify a long list of compatibles ;-)

But what initially worried me would be that there could be a client out there
knowing only "B" and using all features but missing the in that case needed
quirks for "A". Then adding "B" would cause harm. But apparently that is nothing
to worry about.

I will send a reduced patch with just the things which are 100% clear to me.

Regards,
Andreas