The OEMID is an 8-bit binary number that identifies the Device OEM and/or the Device contents (when used as a distribution media either on ROM or FLASH Devices). It occupies bits [111:104] in the CID register: see the eMMC spec JESD84-B51 paragraph 7.2.3.
So it is 8 bits, and has been so since ever - this bug is so ancients I couldn't even find its source. The furthest I could go is to commit 335eadf2ef6a (sd: initialize SD cards) but its already was wrong. Could be because in SD its indeed 16 bits (a 2-characters ASCII string). Another option as pointed out by Alex (offlist), it seems like this comes from the legacy MMC specs (v3.31 and before).
It is important to fix it because we are using it as one of our quirk's token, as well as other tools, e.g. the LVFS (https://github.com/fwupd/fwupd/).
Signed-off-by: Avri Altman avri.altman@wdc.com Cc: stable@vger.kernel.org --- Changelog:
v1--v2: Add Alex's note of the possible origin of this bug. --- drivers/mmc/core/mmc.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/mmc/core/mmc.c b/drivers/mmc/core/mmc.c index 89cd48fcec79..4a4bab9aa726 100644 --- a/drivers/mmc/core/mmc.c +++ b/drivers/mmc/core/mmc.c @@ -104,7 +104,7 @@ static int mmc_decode_cid(struct mmc_card *card) case 3: /* MMC v3.1 - v3.3 */ case 4: /* MMC v4 */ card->cid.manfid = UNSTUFF_BITS(resp, 120, 8); - card->cid.oemid = UNSTUFF_BITS(resp, 104, 16); + card->cid.oemid = UNSTUFF_BITS(resp, 104, 8); card->cid.prod_name[0] = UNSTUFF_BITS(resp, 96, 8); card->cid.prod_name[1] = UNSTUFF_BITS(resp, 88, 8); card->cid.prod_name[2] = UNSTUFF_BITS(resp, 80, 8);