From: Dominique Martinet <asmadeus@codewreck.org>
To: Avri Altman <Avri.Altman@wdc.com>
Cc: Dominique Martinet <dominique.martinet@atmark-techno.com>,
"linux-mmc@vger.kernel.org" <linux-mmc@vger.kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"stable@vger.kernel.org" <stable@vger.kernel.org>,
Ulf Hansson <ulf.hansson@linaro.org>,
Alex Fetters <Alex.Fetters@garmin.com>
Subject: Re: [PATCH] mmc: truncate quirks' oemid to 8 bits
Date: Wed, 1 Nov 2023 13:37:15 +0900 [thread overview]
Message-ID: <ZUHV-wduEf12M86U@codewreck.org> (raw)
In-Reply-To: <DM6PR04MB657596E19EF3D7976197660EFCDDA@DM6PR04MB6575.namprd04.prod.outlook.com>
Avri Altman wrote on Thu, Oct 26, 2023 at 10:16:53AM +0000:
> Reviewed-by: Avri Altman <avri.altman@wdc.com>
Thanks for the review!
> > ---
> > Notes:
> > - mmc_fixup_device() was rewritten in 5.17, so older stable kernels
> > will need a separate patch... I suppose I can send it to stable
> > after this is merged if we go this way
> > - struct mmc_cid's and mmc_fixup's oemid fields are unsigned shorts,
> > we probably just want to make them unsigned char instead in which
> > case we don't need that check anymore?
> > But it's kind of nice to have a wider type so CID_OEMID_ANY can never
> > be a match.... Which unfortunately my patch makes moot as
> > ((unsigned short)-1) & 0xff will be 0xff which can match anything...
> > - this could also be worked around in the _FIXUP_EXT macro that builds
> > the fixup structs, but we're getting ugly here... Or we can just go
> > for the big boom and try to fix all MMC_FIXUP() users in tree and
> > call it a day, but that'll also be fun to backport.
> To me, your fix is clean, elegant and does the job.
> I would let the quirk owners to fix that hard-coded bogus oemid - should they choose to.
> I guess Sandisk would need to do that as well.
Yes, this was exactly my intention - leave the workaround in place for a
while while owners fix their quirks then eventually fix types and remove
this when it is no longer needed.
Meanwhile, all stable kernels including the newly released 6.6 have many
broken quirks and at the very least the MMC I have here would
periodically hang when issuing a flush, so as a selfish user I'd
appreciate if this (or something equivalent) could be making its way
towards Linus' tree.
Ulf, would you have a bit of time to move this forward, or should I ask
Greg to temporarily revert Avri's "mmc: core: Capture correct oemid-bits
for eMMC cards" commit in stable trees until the way forward is decided?
Thanks!
--
Dominique Martinet | Asmadeus
next prev parent reply other threads:[~2023-11-01 4:38 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 [this message]
2023-11-02 13:25 ` Ulf Hansson
2023-11-02 13:37 ` Avri Altman
2023-11-03 0:33 ` Dominique Martinet
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=ZUHV-wduEf12M86U@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