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

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

[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.

Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
---
 lsmmc.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/lsmmc.c b/lsmmc.c
index 799e1ea..7331c1b 100644
--- a/lsmmc.c
+++ b/lsmmc.c
@@ -589,7 +589,7 @@ static void print_mmc_cid(struct config *config, char *cid)
 
 	parse_bin(cid, "8u6r2u8u48a4u4u32u4u4u7u1r",
 		&mid, &cbx, &oid, &pnm[0], &prv_major, &prv_minor, &psn,
-		&mdt_year, &mdt_month, &crc);
+		&mdt_month, &mdt_year, &crc);
 
 	pnm[6] = '\0';
 
-- 
2.39.5

[PATCH 2/2] mmc-utils: lsmmc.c: print_{mmc,sd}_cid(): correct month names

[Peter Korsgaard]

The month nibble is 1-based, E.G. from JESD84:

The “m” field, most significant nibble, is the month code. 1 = January.

So mark 0 as invalid and shift all month names.

Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
---
 lsmmc.c | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/lsmmc.c b/lsmmc.c
index 7331c1b..dd3ab83 100644
--- a/lsmmc.c
+++ b/lsmmc.c
@@ -512,10 +512,10 @@ static void parse_bin(char *hexstr, char *fmt, ...)
 /* MMC/SD information parsing functions */
 static void print_sd_cid(struct config *config, char *cid)
 {
-	static const char *months[] = {
+	static const char *months[] = { "invalid0",
 		"jan", "feb", "mar", "apr", "may", "jun",
 		"jul", "aug", "sep", "oct", "nov", "dec",
-		"invalid0", "invalid1", "invalid2", "invalid3",
+		"invalid1", "invalid2", "invalid3",
 	};
 	unsigned int mid;
 	char oid[3];
@@ -570,10 +570,10 @@ static void print_sd_cid(struct config *config, char *cid)
 
 static void print_mmc_cid(struct config *config, char *cid)
 {
-	static const char *months[] = {
+	static const char *months[] = { "invalid0",
 		"jan", "feb", "mar", "apr", "may", "jun",
 		"jul", "aug", "sep", "oct", "nov", "dec",
-		"invalid0", "invalid1", "invalid2", "invalid3",
+		"invalid1", "invalid2", "invalid3",
 	};
 	unsigned int mid;
 	unsigned int cbx;
-- 
2.39.5

Re: [PATCH 2/2] mmc-utils: lsmmc.c: print_{mmc,sd}_cid(): correct month names

[Ulf Hansson]

On Tue, 4 Nov 2025 at 21:00, Peter Korsgaard <peter@korsgaard.com> wrote:
>
> The month nibble is 1-based, E.G. from JESD84:
>
> The “m” field, most significant nibble, is the month code. 1 = January.
>
> So mark 0 as invalid and shift all month names.
>
> Signed-off-by: Peter Korsgaard <peter@korsgaard.com>

Applied for mmc-utils master, thanks!

Kind regards
Uffe


> ---
>  lsmmc.c | 8 ++++----
>  1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/lsmmc.c b/lsmmc.c
> index 7331c1b..dd3ab83 100644
> --- a/lsmmc.c
> +++ b/lsmmc.c
> @@ -512,10 +512,10 @@ static void parse_bin(char *hexstr, char *fmt, ...)
>  /* MMC/SD information parsing functions */
>  static void print_sd_cid(struct config *config, char *cid)
>  {
> -       static const char *months[] = {
> +       static const char *months[] = { "invalid0",
>                 "jan", "feb", "mar", "apr", "may", "jun",
>                 "jul", "aug", "sep", "oct", "nov", "dec",
> -               "invalid0", "invalid1", "invalid2", "invalid3",
> +               "invalid1", "invalid2", "invalid3",
>         };
>         unsigned int mid;
>         char oid[3];
> @@ -570,10 +570,10 @@ static void print_sd_cid(struct config *config, char *cid)
>
>  static void print_mmc_cid(struct config *config, char *cid)
>  {
> -       static const char *months[] = {
> +       static const char *months[] = { "invalid0",
>                 "jan", "feb", "mar", "apr", "may", "jun",
>                 "jul", "aug", "sep", "oct", "nov", "dec",
> -               "invalid0", "invalid1", "invalid2", "invalid3",
> +               "invalid1", "invalid2", "invalid3",
>         };
>         unsigned int mid;
>         unsigned int cbx;
> --
> 2.39.5
>

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

[Shawn Lin]

在 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.

> Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
> ---
>   lsmmc.c | 2 +-
>   1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/lsmmc.c b/lsmmc.c
> index 799e1ea..7331c1b 100644
> --- a/lsmmc.c
> +++ b/lsmmc.c
> @@ -589,7 +589,7 @@ static void print_mmc_cid(struct config *config, char *cid)
>   
>   	parse_bin(cid, "8u6r2u8u48a4u4u32u4u4u7u1r",
>   		&mid, &cbx, &oid, &pnm[0], &prv_major, &prv_minor, &psn,
> -		&mdt_year, &mdt_month, &crc);
> +		&mdt_month, &mdt_year, &crc);
>   
>   	pnm[6] = '\0';
>   

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

[Peter Korsgaard]

>>>>> "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

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

[Peter Korsgaard]

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

Hi,

 > 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.

That tweak is even not enough, E.G. I see the kernel does:

       if (card->ext_csd.rev >= 5) {
                /* Adjust production date as per JEDEC JESD84-B451 */
                if (card->cid.year < 2010)
                        card->cid.year += 16;

2009 + 16 = 2025, so what will happen in a few months?

-- 
Bye, Peter Korsgaard

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

[Shawn Lin]

在 2025/11/05 星期三 15:07, Peter Korsgaard 写道:
>>>>>> "Shawn" == Shawn Lin <shawn.lin@rock-chips.com> writes:
> 
> Hi,
> 
>   > 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.
> 
> That tweak is even not enough, E.G. I see the kernel does:
> 
>         if (card->ext_csd.rev >= 5) {
>                  /* Adjust production date as per JEDEC JESD84-B451 */
>                  if (card->cid.year < 2010)
>                          card->cid.year += 16;
> 
> 2009 + 16 = 2025, so what will happen in a few months?
> 

TBH, I don't know if there is any update from JEDEC. :)

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

[Avri Altman]

> -----Original Message-----
> From: Shawn Lin <shawn.lin@rock-chips.com>
> Sent: Wednesday, November 5, 2025 9:24 AM
> To: Peter Korsgaard <peter@korsgaard.com>
> Cc: shawn.lin@rock-chips.com; linux-mmc@vger.kernel.org; Avri Altman
> <avri.altman@wdc.com>; Ulf Hansson <ulf.hansson@linaro.org>
> Subject: Re: [PATCH 1/2] mmc-utils: lsmmc.c: print_mmc_cid(): correct
> year/month parsing
> 
> CAUTION: This email originated from outside of Sandisk. Do not click on links or
> open attachments unless you recognize the sender and know that the contents
> are safe.
> 
> 
> 在 2025/11/05 星期三 15:07, Peter Korsgaard 写道:
> >>>>>> "Shawn" == Shawn Lin <shawn.lin@rock-chips.com> writes:
> >
> > Hi,
> >
> >   > 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.
> >
> > That tweak is even not enough, E.G. I see the kernel does:
> >
> >         if (card->ext_csd.rev >= 5) {
> >                  /* Adjust production date as per JEDEC JESD84-B451 */
> >                  if (card->cid.year < 2010)
> >                          card->cid.year += 16;
> >
> > 2009 + 16 = 2025, so what will happen in a few months?
> >
> 
> TBH, I don't know if there is any update from JEDEC. :)
Hi,
Yeah - they noticed that as well and proposed a similar approach by extending the ext-csd-rev to 9.0.
I had the code ready for a while now but somehow failed to submit it yet.
Here it is.
Thanks for fixing the year-month misplacement.

Thanks,
Avri


From c0e5ec1d3670161444943c8984b6cdafb82fac67 Mon Sep 17 00:00:00 2001
From: Avri Altman <avri.altman@sandisk.com>
Date: Thu, 13 Mar 2025 10:10:49 +0200
Subject: [PATCH] mmc: core: Adjust MDT beyond 2025
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

JEDEC JC64.1 proposal, which was recently approved, increases the
manufacturing year limit for eMMC devices. The eMMC manufacturing year
is stored in a 4-bit field in the CID register. Originally, it covered
1997–2012. Later, with EXT_CSD_REV=8, it was extended up to 2025. Now,
with EXT_CSD_REV=9, the range is rolled over by another 16 years, up to
2038.

The mapping is as follows:

| cid[8..11] | ver ≤ 4 | rev > 4 | rev > 8 |
|------------|---------|---------|---------|
| 0          | 1997    | 2013    | 2029    |
| 1          | 1998    | 2014    | 2030    |
| 2          | 1999    | 2015    | 2031    |
| 3          | 2000    | 2016    | 2032    |
| 4          | 2001    | 2017    | 2033    |
| 5          | 2002    | 2018    | 2034    |
| 6          | 2003    | 2019    | 2035    |
| 7          | 2004    | 2020    | 2036    |
| 8          | 2005    | 2021    | 2037    |
| 9          | 2006    | 2022    | 2038    |
| 10         | 2007    | 2023    |         |
| 11         | 2008    | 2024    |         |
| 12         | 2009    | 2025    |         |
| 13         | 2010    |         | 2026    |
| 14         | 2011    |         | 2027    |
| 15         | 2012    |         | 2028    |

Signed-off-by: Avri Altman <avri.altman@sandisk.com>
---
 drivers/mmc/core/mmc.c | 7 +++++++
 1 file changed, 7 insertions(+)

diff --git a/drivers/mmc/core/mmc.c b/drivers/mmc/core/mmc.c
index 3e7d9437477c..8f355a72b84c 100644
--- a/drivers/mmc/core/mmc.c
+++ b/drivers/mmc/core/mmc.c
@@ -672,6 +672,13 @@ static int mmc_decode_ext_csd(struct mmc_card *card, u8 *ext_csd)
 					(card->ext_csd.rel_param &
 					 EXT_CSD_WR_REL_PARAM_EN_RPMB_REL_WR);
 	}
+
+	if (card->ext_csd.rev >= 9) {
+		/* Adjust production date as per JEDEC JC64.1 */
+		if (card->cid.year < 2023)
+			card->cid.year += 16;
+	}
+
 out:
 	return err;
 }
-- 
2.34.1

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

[Peter Korsgaard]

>>>>> "Avri" == Avri Altman <Avri.Altman@sandisk.com> writes:

Hi,

 > Yeah - they noticed that as well and proposed a similar approach by
 > extending the ext-csd-rev to 9.0. I had the code ready for a while
 > now but somehow failed to submit it yet. Here it is.

Ahh, great!

> Thanks for fixing the year-month misplacement.

 > Thanks,
 > Avri


 > From c0e5ec1d3670161444943c8984b6cdafb82fac67 Mon Sep 17 00:00:00 2001
 > From: Avri Altman <avri.altman@sandisk.com>
 > Date: Thu, 13 Mar 2025 10:10:49 +0200
 > Subject: [PATCH] mmc: core: Adjust MDT beyond 2025
 > MIME-Version: 1.0
 > Content-Type: text/plain; charset=UTF-8
 > Content-Transfer-Encoding: 8bit

 > JEDEC JC64.1 proposal, which was recently approved, increases the
 > manufacturing year limit for eMMC devices. The eMMC manufacturing year
 > is stored in a 4-bit field in the CID register. Originally, it covered
 > 1997–2012. Later, with EXT_CSD_REV=8, it was extended up to 2025. Now,
 > with EXT_CSD_REV=9, the range is rolled over by another 16 years, up to
 > 2038.

 > The mapping is as follows:

 > | cid[8..11] | ver ≤ 4 | rev > 4 | rev > 8 |
 > |------------|---------|---------|---------|
 > | 0          | 1997    | 2013    | 2029    |
 > | 1          | 1998    | 2014    | 2030    |
 > | 2          | 1999    | 2015    | 2031    |
 > | 3          | 2000    | 2016    | 2032    |
 > | 4          | 2001    | 2017    | 2033    |
 > | 5          | 2002    | 2018    | 2034    |
 > | 6          | 2003    | 2019    | 2035    |
 > | 7          | 2004    | 2020    | 2036    |
 > | 8          | 2005    | 2021    | 2037    |
 > | 9          | 2006    | 2022    | 2038    |
 > | 10         | 2007    | 2023    |         |
 > | 11         | 2008    | 2024    |         |
 > | 12         | 2009    | 2025    |         |
 > | 13         | 2010    |         | 2026    |
 > | 14         | 2011    |         | 2027    |
 > | 15         | 2012    |         | 2028    |

 > Signed-off-by: Avri Altman <avri.altman@sandisk.com>

Acked-by: Peter Korsgaard <peter@korsgaard.com>

-- 
Bye, Peter Korsgaard

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

[Shawn Lin]

在 2025/11/06 星期四 3:57, Avri Altman 写道:
> 
> 
>> -----Original Message-----
>> From: Shawn Lin <shawn.lin@rock-chips.com>
>> Sent: Wednesday, November 5, 2025 9:24 AM
>> To: Peter Korsgaard <peter@korsgaard.com>
>> Cc: shawn.lin@rock-chips.com; linux-mmc@vger.kernel.org; Avri Altman
>> <avri.altman@wdc.com>; Ulf Hansson <ulf.hansson@linaro.org>
>> Subject: Re: [PATCH 1/2] mmc-utils: lsmmc.c: print_mmc_cid(): correct
>> year/month parsing
>>
>> CAUTION: This email originated from outside of Sandisk. Do not click on links or
>> open attachments unless you recognize the sender and know that the contents
>> are safe.
>>
>>
>> 在 2025/11/05 星期三 15:07, Peter Korsgaard 写道:
>>>>>>>> "Shawn" == Shawn Lin <shawn.lin@rock-chips.com> writes:
>>>
>>> Hi,
>>>
>>>    > 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.
>>>
>>> That tweak is even not enough, E.G. I see the kernel does:
>>>
>>>          if (card->ext_csd.rev >= 5) {
>>>                   /* Adjust production date as per JEDEC JESD84-B451 */
>>>                   if (card->cid.year < 2010)
>>>                           card->cid.year += 16;
>>>
>>> 2009 + 16 = 2025, so what will happen in a few months?
>>>
>>
>> TBH, I don't know if there is any update from JEDEC. :)
> Hi,
> Yeah - they noticed that as well and proposed a similar approach by extending the ext-csd-rev to 9.0.
> I had the code ready for a while now but somehow failed to submit it yet.
> Here it is.
> Thanks for fixing the year-month misplacement.
> 
> Thanks,
> Avri
> 
> 
>  From c0e5ec1d3670161444943c8984b6cdafb82fac67 Mon Sep 17 00:00:00 2001
> From: Avri Altman <avri.altman@sandisk.com>
> Date: Thu, 13 Mar 2025 10:10:49 +0200
> Subject: [PATCH] mmc: core: Adjust MDT beyond 2025
> MIME-Version: 1.0
> Content-Type: text/plain; charset=UTF-8
> Content-Transfer-Encoding: 8bit
> 
> JEDEC JC64.1 proposal, which was recently approved, increases the

Ah, I thinks I should have checked the JESD84-B51b.

> manufacturing year limit for eMMC devices. The eMMC manufacturing year
> is stored in a 4-bit field in the CID register. Originally, it covered
> 1997–2012. Later, with EXT_CSD_REV=8, it was extended up to 2025. Now,
> with EXT_CSD_REV=9, the range is rolled over by another 16 years, up to
> 2038.
> 
> The mapping is as follows:
> 
> | cid[8..11] | ver ≤ 4 | rev > 4 | rev > 8 |
> |------------|---------|---------|---------|
> | 0          | 1997    | 2013    | 2029    |
> | 1          | 1998    | 2014    | 2030    |
> | 2          | 1999    | 2015    | 2031    |
> | 3          | 2000    | 2016    | 2032    |
> | 4          | 2001    | 2017    | 2033    |
> | 5          | 2002    | 2018    | 2034    |
> | 6          | 2003    | 2019    | 2035    |
> | 7          | 2004    | 2020    | 2036    |
> | 8          | 2005    | 2021    | 2037    |
> | 9          | 2006    | 2022    | 2038    |
> | 10         | 2007    | 2023    |         |
> | 11         | 2008    | 2024    |         |
> | 12         | 2009    | 2025    |         |
> | 13         | 2010    |         | 2026    |
> | 14         | 2011    |         | 2027    |
> | 15         | 2012    |         | 2028    |
> 
> Signed-off-by: Avri Altman <avri.altman@sandisk.com>


LGTM,

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

> ---
>   drivers/mmc/core/mmc.c | 7 +++++++
>   1 file changed, 7 insertions(+)
> 
> diff --git a/drivers/mmc/core/mmc.c b/drivers/mmc/core/mmc.c
> index 3e7d9437477c..8f355a72b84c 100644
> --- a/drivers/mmc/core/mmc.c
> +++ b/drivers/mmc/core/mmc.c
> @@ -672,6 +672,13 @@ static int mmc_decode_ext_csd(struct mmc_card *card, u8 *ext_csd)
>   					(card->ext_csd.rel_param &
>   					 EXT_CSD_WR_REL_PARAM_EN_RPMB_REL_WR);
>   	}
> +
> +	if (card->ext_csd.rev >= 9) {
> +		/* Adjust production date as per JEDEC JC64.1 */
> +		if (card->cid.year < 2023)
> +			card->cid.year += 16;
> +	}
> +
>   out:
>   	return err;
>   }

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

[Ulf Hansson]

On Wed, 5 Nov 2025 at 20:58, Avri Altman <Avri.Altman@sandisk.com> wrote:
>
>
>
> > -----Original Message-----
> > From: Shawn Lin <shawn.lin@rock-chips.com>
> > Sent: Wednesday, November 5, 2025 9:24 AM
> > To: Peter Korsgaard <peter@korsgaard.com>
> > Cc: shawn.lin@rock-chips.com; linux-mmc@vger.kernel.org; Avri Altman
> > <avri.altman@wdc.com>; Ulf Hansson <ulf.hansson@linaro.org>
> > Subject: Re: [PATCH 1/2] mmc-utils: lsmmc.c: print_mmc_cid(): correct
> > year/month parsing
> >
> > CAUTION: This email originated from outside of Sandisk. Do not click on links or
> > open attachments unless you recognize the sender and know that the contents
> > are safe.
> >
> >
> > 在 2025/11/05 星期三 15:07, Peter Korsgaard 写道:
> > >>>>>> "Shawn" == Shawn Lin <shawn.lin@rock-chips.com> writes:
> > >
> > > Hi,
> > >
> > >   > 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.
> > >
> > > That tweak is even not enough, E.G. I see the kernel does:
> > >
> > >         if (card->ext_csd.rev >= 5) {
> > >                  /* Adjust production date as per JEDEC JESD84-B451 */
> > >                  if (card->cid.year < 2010)
> > >                          card->cid.year += 16;
> > >
> > > 2009 + 16 = 2025, so what will happen in a few months?
> > >
> >
> > TBH, I don't know if there is any update from JEDEC. :)
> Hi,
> Yeah - they noticed that as well and proposed a similar approach by extending the ext-csd-rev to 9.0.
> I had the code ready for a while now but somehow failed to submit it yet.
> Here it is.
> Thanks for fixing the year-month misplacement.
>
> Thanks,
> Avri
>
>
> From c0e5ec1d3670161444943c8984b6cdafb82fac67 Mon Sep 17 00:00:00 2001
> From: Avri Altman <avri.altman@sandisk.com>
> Date: Thu, 13 Mar 2025 10:10:49 +0200
> Subject: [PATCH] mmc: core: Adjust MDT beyond 2025
> MIME-Version: 1.0
> Content-Type: text/plain; charset=UTF-8
> Content-Transfer-Encoding: 8bit
>
> JEDEC JC64.1 proposal, which was recently approved, increases the
> manufacturing year limit for eMMC devices. The eMMC manufacturing year
> is stored in a 4-bit field in the CID register. Originally, it covered
> 1997–2012. Later, with EXT_CSD_REV=8, it was extended up to 2025. Now,
> with EXT_CSD_REV=9, the range is rolled over by another 16 years, up to
> 2038.
>
> The mapping is as follows:
>
> | cid[8..11] | ver ≤ 4 | rev > 4 | rev > 8 |
> |------------|---------|---------|---------|
> | 0          | 1997    | 2013    | 2029    |
> | 1          | 1998    | 2014    | 2030    |
> | 2          | 1999    | 2015    | 2031    |
> | 3          | 2000    | 2016    | 2032    |
> | 4          | 2001    | 2017    | 2033    |
> | 5          | 2002    | 2018    | 2034    |
> | 6          | 2003    | 2019    | 2035    |
> | 7          | 2004    | 2020    | 2036    |
> | 8          | 2005    | 2021    | 2037    |
> | 9          | 2006    | 2022    | 2038    |
> | 10         | 2007    | 2023    |         |
> | 11         | 2008    | 2024    |         |
> | 12         | 2009    | 2025    |         |
> | 13         | 2010    |         | 2026    |
> | 14         | 2011    |         | 2027    |
> | 15         | 2012    |         | 2028    |
>
> Signed-off-by: Avri Altman <avri.altman@sandisk.com>

Avri, would you mind re-submit the patch so I can pick it up via the
patch tracker, thanks!

Kind regards
Uffe

> ---
>  drivers/mmc/core/mmc.c | 7 +++++++
>  1 file changed, 7 insertions(+)
>
> diff --git a/drivers/mmc/core/mmc.c b/drivers/mmc/core/mmc.c
> index 3e7d9437477c..8f355a72b84c 100644
> --- a/drivers/mmc/core/mmc.c
> +++ b/drivers/mmc/core/mmc.c
> @@ -672,6 +672,13 @@ static int mmc_decode_ext_csd(struct mmc_card *card, u8 *ext_csd)
>                                         (card->ext_csd.rel_param &
>                                          EXT_CSD_WR_REL_PARAM_EN_RPMB_REL_WR);
>         }
> +
> +       if (card->ext_csd.rev >= 9) {
> +               /* Adjust production date as per JEDEC JC64.1 */
> +               if (card->cid.year < 2023)
> +                       card->cid.year += 16;
> +       }
> +
>  out:
>         return err;
>  }
> --
> 2.34.1
>
>

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

[Ulf Hansson]

On Tue, 4 Nov 2025 at 21:00, Peter Korsgaard <peter@korsgaard.com> wrote:
>
> 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.
>
> Signed-off-by: Peter Korsgaard <peter@korsgaard.com>

Applied for mmc-utils master, thanks!

Kind regards
Uffe


> ---
>  lsmmc.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/lsmmc.c b/lsmmc.c
> index 799e1ea..7331c1b 100644
> --- a/lsmmc.c
> +++ b/lsmmc.c
> @@ -589,7 +589,7 @@ static void print_mmc_cid(struct config *config, char *cid)
>
>         parse_bin(cid, "8u6r2u8u48a4u4u32u4u4u7u1r",
>                 &mid, &cbx, &oid, &pnm[0], &prv_major, &prv_minor, &psn,
> -               &mdt_year, &mdt_month, &crc);
> +               &mdt_month, &mdt_year, &crc);
>
>         pnm[6] = '\0';
>
> --
> 2.39.5
>