Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Date:   Sat, 7 Jan 2023 17:39:09 +0100
From:   Andreas Kemnade <andreas@kemnade.info>
To:     Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com>
Cc:     Ahmad Fatoum <a.fatoum@pengutronix.de>, robh+dt@kernel.org,
        shawnguo@kernel.org, s.hauer@pengutronix.de, kernel@pengutronix.de,
        festevam@gmail.com, linux-imx@nxp.com, devicetree@vger.kernel.org,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
        linux-arm-kernel@lists.infradead.org,
        Krzysztof Kozlowski <krzk@kernel.org>,
        Lucas Stach <lst@pengutronix.de>
Subject: Re: [PATCH v2 4/5] ARM: dts: imx6sl: fix mmc compatibles
Message-ID: <20230107173909.6c798f47@aktux>
In-Reply-To: <CA+Eumj50L-bbVBX99Q-6y1-o_R58JvJFsStck+O2-18qJSUT1g@mail.gmail.com>
References: <20210924091439.2561931-1-andreas@kemnade.info>
        <20210924091439.2561931-5-andreas@kemnade.info>
        <a5ec87f2-7e72-9c23-e13a-75498287b451@pengutronix.de>
        <20210926203314.7c187191@aktux>
        <CA+Eumj50L-bbVBX99Q-6y1-o_R58JvJFsStck+O2-18qJSUT1g@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Precedence: bulk

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

> On Sun, 26 Sept 2021 at 20:33, Andreas Kemnade <andreas@kemnade.info> wrote:
> >
> > Hi Ahmad,
> >
> > On Sun, 26 Sep 2021 08:54:35 +0200
> > Ahmad Fatoum <a.fatoum@pengutronix.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