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.