Re: [PATCH 1/2] mmc-utils: lsmmc.c: print_mmc_cid(): correct year/month parsing

[Peter Korsgaard <peter@korsgaard.com>]

>>>>> "Shawn" == Shawn Lin <shawn.lin@rock-chips.com> writes:

 > 在 2025/11/05 星期三 4:00, Peter Korsgaard 写道:
 >> The parsing logic for the MMC manufacturing date had the year and month
 >> swapped.  From JESD84:
 >> The manufacturing date, MDT, is composed of two hexadecimal digits,
 >> four
 >> bits each, representing a two digits date code m/y; The “m” field, most
 >> significant nibble, is the month code.  1 = January.  The “y” field, least
 >> significant nibble, is the year code.
 >> Notice that this is the opposite of the SD bit ordering.
 >> 

 > That's ture.

 > Reviewed-by: Shawn Lin <shawn.lin@rock-chips.com>

 > Another problem I noticed when reading the code is:

 >  628                 printf("\tMDT: 0x%01x%01x %u %s\n", mdt_month,
 >  mdt_year,
 >  629                        1997 + mdt_year, months[mdt_month]);
 >  630                 printf("\tCRC: 0x%02x\n", crc);

 > From the JESD84-B51, section 7.2.7,

 > For e•MMC 4.41 and later devices, indicated by a value larger than 4 in
 > EXT_CSD_REV [192], the 4-bit“y” field shall roll over after 2012, so
 > that y=0 shall be used for 2013. See Table 77 for a list of valid y
 > values for specific e•MMC versions.

 > So mdt_year + 1997 seems wrong, too.

Yes, I noticed that as well. The print_mmc_cid() function does not
directly have access to the EXT_CSD_REV register though, so not trivial
to fix - Unless we read it at startup and stick it in the config
structure?

-- 
Bye, Peter Korsgaard