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 for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-Id: <B67A91BD-DAE9-468B-8731-251DE86E6B5B@benettiengineering.com>
Date:   Thu, 4 Nov 2021 03:30:33 +0100
From:   Giulio Benetti <giulio.benetti@...ettiengineering.com>
To:     Rob Herring <robh@...nel.org>
Cc:     Jesse Taube <mr.bossman075@...il.com>,
        Fabio Estevam <festevam@...il.com>,
        NXP Linux Team <linux-imx@....com>,
        Michael Turquette <mturquette@...libre.com>,
        Stephen Boyd <sboyd@...nel.org>,
        Shawn Guo <shawnguo@...nel.org>,
        Sascha Hauer <s.hauer@...gutronix.de>,
        Sascha Hauer <kernel@...gutronix.de>,
        Ulf Hansson <ulf.hansson@...aro.org>,
        Dong Aisheng <aisheng.dong@....com>,
        Stefan Agner <stefan@...er.ch>,
        Linus Walleij <linus.walleij@...aro.org>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Arnd Bergmann <arnd@...db.de>, Olof Johansson <olof@...om.net>,
        soc@...nel.org, Russell King - ARM Linux <linux@...linux.org.uk>,
        Abel Vesa <abel.vesa@....com>,
        Adrian Hunter <adrian.hunter@...el.com>,
        Jiri Slaby <jirislaby@...nel.org>,
        Nobuhiro Iwamatsu <nobuhiro1.iwamatsu@...hiba.co.jp>,
        linux-clk <linux-clk@...r.kernel.org>,
        "open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS" 
        <devicetree@...r.kernel.org>,
        "moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE" 
        <linux-arm-kernel@...ts.infradead.org>,
        linux-kernel <linux-kernel@...r.kernel.org>,
        linux-mmc <linux-mmc@...r.kernel.org>,
        "open list:GPIO SUBSYSTEM" <linux-gpio@...r.kernel.org>,
        linux-serial@...r.kernel.org
Subject: Re: [PATCH v2 11/13] mmc: sdhci-esdhc-imx: Add sdhc support for i.MXRT series

Hello Rob, Jesse, All,

> Il giorno 4 nov 2021, alle ore 02:05, Rob Herring <robh@...nel.org> ha scritto:
> 
> On Wed, Nov 03, 2021 at 12:30:17AM +0100, Giulio Benetti wrote:
>> Hi Fabio, Jesse, All,
>> 
>>> On 11/3/21 12:25 AM, Jesse Taube wrote:
>>> 
>>> 
>>> On 11/2/21 19:17, Fabio Estevam wrote:
>>>> On Tue, Nov 2, 2021 at 7:57 PM Jesse Taube <mr.bossman075@...il.com> wrote:
>>>> 
>>>>>   static struct esdhc_soc_data usdhc_imx8qxp_data = {
>>>>>          .flags = ESDHC_FLAG_USDHC | ESDHC_FLAG_STD_TUNING
>>>>> @@ -357,6 +363,7 @@ static const struct of_device_id imx_esdhc_dt_ids[] = {
>>>>>          { .compatible = "fsl,imx7ulp-usdhc", .data = &usdhc_imx7ulp_data, },
>>>>>          { .compatible = "fsl,imx8qxp-usdhc", .data = &usdhc_imx8qxp_data, },
>>>>>          { .compatible = "fsl,imx8mm-usdhc", .data = &usdhc_imx8mm_data, },
>>>>> +       { .compatible = "fsl,imxrt-usdhc", .data = &usdhc_imxrt_data, },
>>>> 
>>>> I thought Rob suggested to use the SoC name, so this would be:
>>>> 
>>> Uh i think that may have been for the UART.
>>>> { .compatible = "fsl,imxrt1050-usdhc", .data = &usdhc_imxrt1050_data, },
>>>> 
>>>> The same applies to the other bindings in the series.
>>>> 
>>>> This way it would be possible to differentiate between future
>>>> supported i.MX RT devices.
>>>> 
>>> This makes sense will do in V3.
>>> 
>> 
>> If we add every SoC we will end up having a long list for every device
>> driver. At the moment it would be 7 parts:
>> 1) imxrt1020
>> 2) imxrt1024
>> .
>> .
>> .
>> 7) imxrt1170
> 
> You don't need a driver update if you use a fallback. When you add 
> the 2nd chip, if you think it is 'the same', then you do:
> 
> compatible = "fsl,imxrt1024-usdhc", "fsl,imxrt1050-usdhc";
> 
> That requires no driver update until the driver needs to handle some 
> difference. And when there is a difference, you don't need a DT update.

This solution is pretty fine, we’re going with that then, for this and every driver involved.

Thank you for pointing us.

Best regards
Giulio Benetti
Benetti Engineering sas

> 
> You could make "fsl,imxrt-usdhc" the fallback from the start if you are 
> adverse to the first way.
> 
> Rob

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ