Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:8 as permitted sender) client-ip=2620:137:e000::3:8;
Date:   Fri, 3 Nov 2023 09:33:06 +0900
From:   Dominique Martinet <asmadeus@codewreck.org>
To:     Ulf Hansson <ulf.hansson@linaro.org>
Cc:     Avri Altman <avri.altman@wdc.com>,
        Dominique Martinet <dominique.martinet@atmark-techno.com>,
        linux-mmc@vger.kernel.org, linux-kernel@vger.kernel.org,
        stable@vger.kernel.org, Alex Fetters <Alex.Fetters@garmin.com>
Subject: Re: [PATCH] mmc: truncate quirks' oemid to 8 bits
Message-ID: <ZUQ_wm22gO7lLZ3N@codewreck.org>
References: <20231026075230.414685-1-dominique.martinet@atmark-techno.com>
 <CAPDyKFqkKibcXnwjnhc3+W1iJBHLeqQ9BpcZrSwhW2u9K2oUtg@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <CAPDyKFqkKibcXnwjnhc3+W1iJBHLeqQ9BpcZrSwhW2u9K2oUtg@mail.gmail.com>
Precedence: bulk

Ulf Hansson wrote on Thu, Nov 02, 2023 at 02:25:09PM +0100:
> > Fixes: 84ee19bffc93 ("mmc: core: Capture correct oemid-bits for eMMC cards")
> 
> [...]
> 
> It looks to me that the offending commit (84ee19bffc93) should be
> reverted instead of trying to introduce some weird parsing of the card
> quirks.

I agree that's better -- that's what I did on our stable tree until the
dust settles down, I probably should have sent that instead.

As Avri pointed out the offending commit was picked up to stable, but
the revert should apply cleanly so if we send Greg a mail after Linus
picked it up it can be reverted on all stable branches quickly.

There's little value in me resending this as a revert, but process-wise
I guess it's easier if someone sends it as a mail so I'll whip up a
commit message and send that now.

> In fact, up until v5.1 it seems not to be a problem to use 16-bits for
> the OID, as the CBX and the reserved bits are probably just given some
> fixed values by the vendors, right?

Right, it's possible that using 8 bits here would apply the quirks to
more devices than what was intended if the other 8 bits made a
difference... Unfortunately that's something only vendors would know.

> Beyond v5.1A, we may have a problem as the BIN may actually be used
> for something valuable. Maybe Avri knows more here?
> 
> That said, if the offending commit is really needed to fix a problem,
> we need to figure out exactly what that problem is. The EXT_CSD_REV
> doesn't provide us with the exact version that the card is supporting,
> but at least we know if v5.1 and onwards is supported, so perhaps that
> can be used to fixup/improve the OID/CBX/BIN parsing.

Keep filling the full 16 bits unless rev is higher, in which case we
read half?
At this point (mmc_decode_cid) we can use card's ext_csd.rev so if v5.1A
bumped it then it's a possibility; I don't have access to the jedec
standard to check right now.

-- 
Dominique Martinet | Asmadeus