e⋅MMC forward compatibility

e⋅MMC forward compatibility

[Romain Izard]

Hello,

The e⋅MMC 5.0 specification has been published by JEDEC on September
2013 [1], and contains a note in section B.8, which says: "A host
system should work properly considering future eMMC version. For
example, a host system is expected not to exit only due to the
EXT_CSD_REV[192] value greater than 7 which will be used for next
e•MMC revision."

Right now, the kernel controls the value of both fields 192 and 194,
and rejects any device where CSD_STRUCTURE > 2 or EXT_CSD_REV > 7.

During the updates to the specification, JEDEC has maintained forward
compatibility, setting reserved bits in the EXT_CSD register to
describe new mandatory and optional features. If the specification
changes in an incompatible way, it is expected that the value in
CSD_STRUCTURE will change. As a result, I believe it would not be an
issue to remove the control on EXT_CSD_REV.

I propose this change because e⋅MMC manufacturers are rapidly changing
available references, and products with a long production life can
encounter the situation where the kernel image, frozen at the
beginning of the production, cannot support newer chips only because
of this rule.


[1] http://www.jedec.org/standards-documents/docs/jesd84-b50 (Free
registration required)

Best regards,
-- 
Romain Izard

Re: e⋅MMC forward compatibility

[Chris Ball]

Hi Romain,

On Thu, Nov 28 2013, Romain Izard wrote:
> The e⋅MMC 5.0 specification has been published by JEDEC on September
> 2013 [1], and contains a note in section B.8, which says: "A host
> system should work properly considering future eMMC version. For
> example, a host system is expected not to exit only due to the
> EXT_CSD_REV[192] value greater than 7 which will be used for next
> e•MMC revision."
>
> Right now, the kernel controls the value of both fields 192 and 194,
> and rejects any device where CSD_STRUCTURE > 2 or EXT_CSD_REV > 7.

Sounds good to me -- want to send a patch?

Thanks,

- Chris.
-- 
Chris Ball   <cjb@laptop.org>   <http://printf.net/>

[PATCH] mmc: Allow forward compatibility for e⋅MMC

[Romain Izard]

As stated by the e⋅MMC 5.0 specification, a chip should not be rejected
only because of the revision stated in the EXT_CSD_REV field of the
EXT_CSD register.

Remove the control on this value, the control of the CSD_STRUCTURE field
should be sufficient to reject future incompatible changes.

Signed-off-by: Romain Izard <romain.izard.pro@gmail.com>
---
 drivers/mmc/core/mmc.c | 11 +++++------
 1 file changed, 5 insertions(+), 6 deletions(-)

diff --git a/drivers/mmc/core/mmc.c b/drivers/mmc/core/mmc.c
index f631f5a9bf79..73b43574e1b4 100644
--- a/drivers/mmc/core/mmc.c
+++ b/drivers/mmc/core/mmc.c
@@ -293,13 +293,12 @@ static int mmc_read_ext_csd(struct mmc_card *card, u8 *ext_csd)
 		}
 	}
 
+	/*
+	 * The EXT_CSD format is meant to be forward compatible. As long
+	 * as CSD_STRUCTURE does not change, all values for EXT_CSD_REV
+	 * are authorized, see JEDEC JESD84-B50 section B.8.
+	 */
 	card->ext_csd.rev = ext_csd[EXT_CSD_REV];
-	if (card->ext_csd.rev > 7) {
-		pr_err("%s: unrecognised EXT_CSD revision %d\n",
-			mmc_hostname(card->host), card->ext_csd.rev);
-		err = -EINVAL;
-		goto out;
-	}
 
 	card->ext_csd.raw_sectors[0] = ext_csd[EXT_CSD_SEC_CNT + 0];
 	card->ext_csd.raw_sectors[1] = ext_csd[EXT_CSD_SEC_CNT + 1];
-- 
1.8.3.2

Re: [PATCH] mmc: Allow forward compatibility for e⋅MMC

[Ulf Hansson]

On 29 November 2013 09:38, Romain Izard <romain.izard.pro@gmail.com> wrote:
> As stated by the e⋅MMC 5.0 specification, a chip should not be rejected
> only because of the revision stated in the EXT_CSD_REV field of the
> EXT_CSD register.
>
> Remove the control on this value, the control of the CSD_STRUCTURE field
> should be sufficient to reject future incompatible changes.
>
> Signed-off-by: Romain Izard <romain.izard.pro@gmail.com>

Acked-by: Ulf Hansson <ulf.hansson@linaro.org>

> ---
>  drivers/mmc/core/mmc.c | 11 +++++------
>  1 file changed, 5 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/mmc/core/mmc.c b/drivers/mmc/core/mmc.c
> index f631f5a9bf79..73b43574e1b4 100644
> --- a/drivers/mmc/core/mmc.c
> +++ b/drivers/mmc/core/mmc.c
> @@ -293,13 +293,12 @@ static int mmc_read_ext_csd(struct mmc_card *card, u8 *ext_csd)
>                 }
>         }
>
> +       /*
> +        * The EXT_CSD format is meant to be forward compatible. As long
> +        * as CSD_STRUCTURE does not change, all values for EXT_CSD_REV
> +        * are authorized, see JEDEC JESD84-B50 section B.8.
> +        */
>         card->ext_csd.rev = ext_csd[EXT_CSD_REV];
> -       if (card->ext_csd.rev > 7) {
> -               pr_err("%s: unrecognised EXT_CSD revision %d\n",
> -                       mmc_hostname(card->host), card->ext_csd.rev);
> -               err = -EINVAL;
> -               goto out;
> -       }
>
>         card->ext_csd.raw_sectors[0] = ext_csd[EXT_CSD_SEC_CNT + 0];
>         card->ext_csd.raw_sectors[1] = ext_csd[EXT_CSD_SEC_CNT + 1];
> --
> 1.8.3.2
>

[PATCH RESEND] mmc: Allow forward compatibility for e⋅MMC

[Romain Izard]

As stated by the e⋅MMC 5.0 specification, a chip should not be rejected
only because of the revision stated in the EXT_CSD_REV field of the
EXT_CSD register.

Remove the control on this value, the control of the CSD_STRUCTURE field
should be sufficient to reject future incompatible changes.

Acked-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Romain Izard <romain.izard.pro@gmail.com>
---
 drivers/mmc/core/mmc.c | 11 +++++------
 1 file changed, 5 insertions(+), 6 deletions(-)

diff --git a/drivers/mmc/core/mmc.c b/drivers/mmc/core/mmc.c
index 98e9eb0f6643..81c23e4db704 100644
--- a/drivers/mmc/core/mmc.c
+++ b/drivers/mmc/core/mmc.c
@@ -293,13 +293,12 @@ static int mmc_read_ext_csd(struct mmc_card *card, u8 *ext_csd)
 		}
 	}
 
+	/*
+	 * The EXT_CSD format is meant to be forward compatible. As long
+	 * as CSD_STRUCTURE does not change, all values for EXT_CSD_REV
+	 * are authorized, see JEDEC JESD84-B50 section B.8.
+	 */
 	card->ext_csd.rev = ext_csd[EXT_CSD_REV];
-	if (card->ext_csd.rev > 7) {
-		pr_err("%s: unrecognised EXT_CSD revision %d\n",
-			mmc_hostname(card->host), card->ext_csd.rev);
-		err = -EINVAL;
-		goto out;
-	}
 
 	card->ext_csd.raw_sectors[0] = ext_csd[EXT_CSD_SEC_CNT + 0];
 	card->ext_csd.raw_sectors[1] = ext_csd[EXT_CSD_SEC_CNT + 1];
-- 
1.8.3.2