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] [thread-next>] [day] [month] [year] [list]
Date:   Wed, 23 Mar 2022 12:23:16 -0500
From:   Adam Ford <aford173@...il.com>
To:     Krzysztof Kozlowski <krzk@...nel.org>
Cc:     arm-soc <linux-arm-kernel@...ts.infradead.org>,
        Adam Ford-BE <aford@...conembedded.com>,
        Ulf Hansson <ulf.hansson@...aro.org>,
        Rob Herring <robh+dt@...nel.org>,
        Krzysztof Kozlowski <krzk+dt@...nel.org>,
        Shawn Guo <shawnguo@...nel.org>,
        Sascha Hauer <s.hauer@...gutronix.de>,
        Pengutronix Kernel Team <kernel@...gutronix.de>,
        Fabio Estevam <festevam@...il.com>,
        NXP Linux Team <linux-imx@....com>,
        linux-mmc <linux-mmc@...r.kernel.org>,
        devicetree <devicetree@...r.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 1/3] dt-bindings: mmc: imx-esdhc: Change imx8mn and imx8mp
 compatible fallback

On Wed, Mar 23, 2022 at 9:11 AM Krzysztof Kozlowski <krzk@...nel.org> wrote:
>
> On 23/03/2022 15:00, Adam Ford wrote:
> > On Wed, Mar 23, 2022 at 8:56 AM Krzysztof Kozlowski <krzk@...nel.org> wrote:
> >>
> >> On 23/03/2022 14:40, Adam Ford wrote:
> >>> The SDHC controller in the imx8mn and imx8mp have the same controller
> >>> as the imx8mm which is slightly different than that of the imx7d.
> >>> Using the fallback of the imx8mm enables the controllers to support
> >>> HS400-ES which is not available on the imx7d.
> >>>
> >>> Signed-off-by: Adam Ford <aford173@...il.com>
> >>>
> >>> diff --git a/Documentation/devicetree/bindings/mmc/fsl-imx-esdhc.yaml b/Documentation/devicetree/bindings/mmc/fsl-imx-esdhc.yaml
> >>> index 7dbbcae9485c..d6ea73d76bdd 100644
> >>> --- a/Documentation/devicetree/bindings/mmc/fsl-imx-esdhc.yaml
> >>> +++ b/Documentation/devicetree/bindings/mmc/fsl-imx-esdhc.yaml
> >>> @@ -39,14 +39,14 @@ properties:
> >>>        - items:
> >>>            - enum:
> >>>                - fsl,imx8mm-usdhc
> >>
> >> Your change looks reasonable, but why imx8mm is compatible with imx7d?
> >
> > I saw that, and I wasn't sure the best way to go about  fixing it.  If
> > I move the 8mm out of the imx7d category, do I need to add it to the
> > enum list associated with the imx8mm, or can I just delete it from the
> > enum leaving the const for imx8mm good enough?
> >
>
> The DTS is using:
>   compatible = "fsl,imx8mm-usdhc", "fsl,imx7d-usdhc"
> which looks incorrect, based on what you wrote in commit description.
> Since fsl,imx8mm-usdhc has its own compatibility-group and defines the
> properties for entire family (imx8mm + imx8mn + imx8mp), then I would
> assume that either fsl,imx8mm-usdhc is not be compatible with imx7d or
> everything is compatible with imx7d. IOW, DTS and bindings should be
> changed to one of following:
> 1. Everything compatible with imx7d:
>   compatible = "fsl,imx8mm-usdhc", "fsl,imx7d-usdhc";
>   compatible = "fsl,imx8mq-usdhc", "fsl,imx8mm-usdhc", "fsl,imx7d-usdhc";
>
> 2. A new group:
>   compatible = "fsl,imx8mm-usdhc";
>   compatible = "fsl,imx8mq-usdhc", "fsl,imx8mm-usdhc";
>
> Which one, I am not sure. My commit 80fd350b95 organized it in (1)
> approach, because also that time there was no new group for 8mm (added
> in commit 431fae8). I assume NXP engineer knows better, so the better
> solution would be (2). In such case, imx8mm has to be moved to the first
> enum and all DTS have to be adjusted.

I pulled NXP's downtream kernel based on 5.15.y, and grepped the code
for imx8mm-usdhc.  It looks like the imx8mm, imx8mn, imx8mp, and
imx8ulp use the imx8mm compatible flag.
The imx8mq uses the older imx7d.  I'll do a second revision later
today or tomorrow.  Looking inside the driver, it appears there are
some other quirks that different between the imx7d and imx8mm beyond
just support for HS400-ES, so I think your option 2 is appropriate.
Hopefully someone from NXP can comment.

adam
>
>
> Best regards,
> Krzysztof

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ