linux-kernel - Re: [PATCH v2 4/5] ARM: dts: imx6sl: fix mmc compatibles

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]

Date:   Sat, 7 Jan 2023 17:39:09 +0100
From:   Andreas Kemnade <andreas@...nade.info>
To:     Krzysztof Kozlowski <krzysztof.kozlowski@...onical.com>
Cc:     Ahmad Fatoum <a.fatoum@...gutronix.de>, robh+dt@...nel.org,
        shawnguo@...nel.org, s.hauer@...gutronix.de, kernel@...gutronix.de,
        festevam@...il.com, linux-imx@....com, devicetree@...r.kernel.org,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        linux-arm-kernel@...ts.infradead.org,
        Krzysztof Kozlowski <krzk@...nel.org>,
        Lucas Stach <lst@...gutronix.de>
Subject: Re: [PATCH v2 4/5] ARM: dts: imx6sl: fix mmc compatibles

On Mon, 27 Sep 2021 09:34:57 +0200
Krzysztof Kozlowski <krzysztof.kozlowski@...onical.com> wrote:

> On Sun, 26 Sept 2021 at 20:33, Andreas Kemnade <andreas@...nade.info> wrote:
> >
> > Hi Ahmad,
> >
> > On Sun, 26 Sep 2021 08:54:35 +0200
> > Ahmad Fatoum <a.fatoum@...gutronix.de> wrote:
> >  
> > > Hello Andreas,
> > >
> > > On 24.09.21 11:14, Andreas Kemnade wrote:  
> > > > Binding specification only allows one compatible here.  
> > >
> > > This same change was NACKed by Lucas here:
> > > https://lore.kernel.org/linux-devicetree/72e1194e10ccb4f87aed96265114f0963e805092.camel@pengutronix.de/
> > >
> > > I also think the schema should be fixed instead.
> > >  
> > well, that argumentation makes sense. Feel free to drop this patch. I
> > will not repost the series if it is just about dropping patches.  
> 
> The argument of using a new DTB with an old kernel, therefore
> prohibiting changes in new DTB, does not make that much sense, except
> when caring about other systems which would like to directly reuse the
> DTB... anyway it's not that important to fight over it.
> 
hmm, imx6sl_data specifies
ESDHC_FLAG_ERR004536 
imx6sq_data does not specify it.

Than there is  ESDHC_FLAG_STD_TUNING vs. ESDHC_FLAG_MAN_TUNING.
So it the fsl,imx6q-usdhc really a technically valid fallback compatible?

Regards,
Andreas