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
