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
Date: Fri, 3 Nov 2023 09:33:06 +0900 [thread overview]
Message-ID: <ZUQ_wm22gO7lLZ3N@codewreck.org> (raw)
In-Reply-To: <CAPDyKFqkKibcXnwjnhc3+W1iJBHLeqQ9BpcZrSwhW2u9K2oUtg@mail.gmail.com>
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
prev parent reply other threads:[~2023-11-03 0:33 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-10-26 7:52 [PATCH] mmc: truncate quirks' oemid to 8 bits Dominique Martinet
2023-10-26 10:16 ` Avri Altman
2023-11-01 4:37 ` Dominique Martinet
2023-11-02 13:25 ` Ulf Hansson
2023-11-02 13:37 ` Avri Altman
2023-11-03 0:33 ` Dominique Martinet [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=ZUQ_wm22gO7lLZ3N@codewreck.org \
--to=asmadeus@codewreck.org \
--cc=Alex.Fetters@garmin.com \
--cc=avri.altman@wdc.com \
--cc=dominique.martinet@atmark-techno.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mmc@vger.kernel.org \
--cc=stable@vger.kernel.org \
--cc=ulf.hansson@linaro.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox