* [PATCH v3 1/5] mmc: core: Expose access to RPMB partition
2012-08-06 15:12 [PATCH v3 0/5] mmc: Add access to RPMB partition Loic Pallardy
@ 2012-08-06 15:12 ` Loic Pallardy
[not found] ` <CAJOk3oHfTMr7-esASZKV0kmiFmeGzD1OjgwMZrTtz8Pk61Lswg@mail.gmail.com>
2012-08-06 15:12 ` [PATCH v3 2/5] mmc: card: Do not scan RPMB partitions Loic Pallardy
` (5 subsequent siblings)
6 siblings, 1 reply; 26+ messages in thread
From: Loic Pallardy @ 2012-08-06 15:12 UTC (permalink / raw)
To: linux-mmc, Chris Ball
Cc: Linus Walleij, STEricsson_nomadik_linux, Ulf Hansson,
Loic Pallardy, Alex Macro, Loic Pallardy
Following JEDEC standard, if the mmc support RPMB partition,
a new interface is created and exposed via /dev/block.
Users will be able to access RPMB partition using standard
mmc IOCTL command.
Signed-off-by: Alex Macro <alex.macro@stericsson.com>
Signed-off-by: Loic Pallardy <loic.pallardy@stericsson.com>
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Acked-by: Johan Rudholm <johan.rudholm@stericsson.com>
Reviewed-by: Namjae Jeon <linkinjeon@gmail.com>
---
drivers/mmc/core/mmc.c | 11 +++++++++++
include/linux/mmc/card.h | 2 ++
include/linux/mmc/mmc.h | 2 ++
3 files changed, 15 insertions(+)
diff --git a/drivers/mmc/core/mmc.c b/drivers/mmc/core/mmc.c
index 258b203..8a459cb 100644
--- a/drivers/mmc/core/mmc.c
+++ b/drivers/mmc/core/mmc.c
@@ -480,6 +480,17 @@ static int mmc_read_ext_csd(struct mmc_card *card, u8 *ext_csd)
card->ext_csd.rel_param = ext_csd[EXT_CSD_WR_REL_PARAM];
card->ext_csd.rst_n_function = ext_csd[EXT_CSD_RST_N_FUNCTION];
+
+ /*
+ * RPMB regions are defined in multiples of 128K.
+ */
+ card->ext_csd.raw_rpmb_size_mult = ext_csd[EXT_CSD_RPMB_MULT];
+ if (ext_csd[EXT_CSD_RPMB_MULT]) {
+ mmc_part_add(card, ext_csd[EXT_CSD_RPMB_MULT] << 17,
+ EXT_CSD_PART_CONFIG_ACC_RPMB,
+ "rpmb", 0, false,
+ MMC_BLK_DATA_AREA_RPMB);
+ }
}
card->ext_csd.raw_erased_mem_count = ext_csd[EXT_CSD_ERASED_MEM_CONT];
diff --git a/include/linux/mmc/card.h b/include/linux/mmc/card.h
index d76513b..46a5502 100644
--- a/include/linux/mmc/card.h
+++ b/include/linux/mmc/card.h
@@ -81,6 +81,7 @@ struct mmc_ext_csd {
unsigned int boot_ro_lock; /* ro lock support */
bool boot_ro_lockable;
u8 raw_partition_support; /* 160 */
+ u8 raw_rpmb_size_mult; /* 168 */
u8 raw_erased_mem_count; /* 181 */
u8 raw_ext_csd_structure; /* 194 */
u8 raw_card_type; /* 196 */
@@ -200,6 +201,7 @@ struct mmc_part {
#define MMC_BLK_DATA_AREA_MAIN (1<<0)
#define MMC_BLK_DATA_AREA_BOOT (1<<1)
#define MMC_BLK_DATA_AREA_GP (1<<2)
+#define MMC_BLK_DATA_AREA_RPMB (1<<3)
};
/*
diff --git a/include/linux/mmc/mmc.h b/include/linux/mmc/mmc.h
index d425cab..e73136a 100644
--- a/include/linux/mmc/mmc.h
+++ b/include/linux/mmc/mmc.h
@@ -282,6 +282,7 @@ struct _mmc_csd {
#define EXT_CSD_RST_N_FUNCTION 162 /* R/W */
#define EXT_CSD_SANITIZE_START 165 /* W */
#define EXT_CSD_WR_REL_PARAM 166 /* RO */
+#define EXT_CSD_RPMB_MULT 168 /* RO */
#define EXT_CSD_BOOT_WP 173 /* R/W */
#define EXT_CSD_ERASE_GROUP_DEF 175 /* R/W */
#define EXT_CSD_PART_CONFIG 179 /* R/W */
@@ -333,6 +334,7 @@ struct _mmc_csd {
#define EXT_CSD_PART_CONFIG_ACC_MASK (0x7)
#define EXT_CSD_PART_CONFIG_ACC_BOOT0 (0x1)
+#define EXT_CSD_PART_CONFIG_ACC_RPMB (0x3)
#define EXT_CSD_PART_CONFIG_ACC_GP0 (0x4)
#define EXT_CSD_PART_SUPPORT_PART_EN (0x1)
--
1.7.11.1
^ permalink raw reply related [flat|nested] 26+ messages in thread* [PATCH v3 2/5] mmc: card: Do not scan RPMB partitions
2012-08-06 15:12 [PATCH v3 0/5] mmc: Add access to RPMB partition Loic Pallardy
2012-08-06 15:12 ` [PATCH v3 1/5] mmc: core: Expose " Loic Pallardy
@ 2012-08-06 15:12 ` Loic Pallardy
[not found] ` <CAJOk3oE2gXH1AQQBqq-nuLCEb4--vcMZRYnQJNWOdCP8c0JcAA@mail.gmail.com>
2012-08-06 15:12 ` [PATCH v3 3/5] mmc: core: Extend sysfs to ext_csd parameters for RPMB support Loic Pallardy
` (4 subsequent siblings)
6 siblings, 1 reply; 26+ messages in thread
From: Loic Pallardy @ 2012-08-06 15:12 UTC (permalink / raw)
To: linux-mmc, Chris Ball
Cc: Linus Walleij, STEricsson_nomadik_linux, Ulf Hansson,
Loic Pallardy, Johan Rudholm
Do not scan rpmb partitions for "soft" partitions, since the rpmb
partition contains protected data. Silences the following
message during boot:
mmcblkXRPMB: unknown partition table
Signed-off-by: Johan Rudholm <johan.rudholm@stericsson.com>
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Reviewed-by: Namjae Jeon <linkinjeon@gmail.com>
---
drivers/mmc/card/block.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/mmc/card/block.c b/drivers/mmc/card/block.c
index 276d21c..d8edb8d 100644
--- a/drivers/mmc/card/block.c
+++ b/drivers/mmc/card/block.c
@@ -1521,6 +1521,8 @@ static struct mmc_blk_data *mmc_blk_alloc_req(struct mmc_card *card,
md->disk->queue = md->queue.queue;
md->disk->driverfs_dev = parent;
set_disk_ro(md->disk, md->read_only || default_ro);
+ if (area_type & MMC_BLK_DATA_AREA_RPMB)
+ md->disk->flags |= GENHD_FL_NO_PART_SCAN;
/*
* As discussed on lkml, GENHD_FL_REMOVABLE should:
--
1.7.11.1
^ permalink raw reply related [flat|nested] 26+ messages in thread* [PATCH v3 3/5] mmc: core: Extend sysfs to ext_csd parameters for RPMB support
2012-08-06 15:12 [PATCH v3 0/5] mmc: Add access to RPMB partition Loic Pallardy
2012-08-06 15:12 ` [PATCH v3 1/5] mmc: core: Expose " Loic Pallardy
2012-08-06 15:12 ` [PATCH v3 2/5] mmc: card: Do not scan RPMB partitions Loic Pallardy
@ 2012-08-06 15:12 ` Loic Pallardy
[not found] ` <CAJOk3oHSTygZBkj847a+OKcSAB8=G0YN8vrz07080sUdPB0+_Q@mail.gmail.com>
2012-08-06 15:12 ` [PATCH v3 4/5] mmc: core: Add mmc_set_blockcount feature Loic Pallardy
` (3 subsequent siblings)
6 siblings, 1 reply; 26+ messages in thread
From: Loic Pallardy @ 2012-08-06 15:12 UTC (permalink / raw)
To: linux-mmc, Chris Ball
Cc: Linus Walleij, STEricsson_nomadik_linux, Ulf Hansson,
Loic Pallardy, Loic Pallardy
Extend current sysfs access to ext_csd rpmb
parameters (RPMB partition size) and rel_sector
information.
Signed-off-by: Loic Pallardy <loic.pallardy@stericsson.com>
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Acked-by: Johan Rudholm <johan.rudholm@stericsson.com>
Reviewed-by: Namjae Jeon <linkinjeon@gmail.com>
---
Documentation/mmc/mmc-dev-attrs.txt | 7 +++++++
drivers/mmc/core/mmc.c | 4 ++++
2 files changed, 11 insertions(+)
diff --git a/Documentation/mmc/mmc-dev-attrs.txt b/Documentation/mmc/mmc-dev-attrs.txt
index 22ae844..0d98fac 100644
--- a/Documentation/mmc/mmc-dev-attrs.txt
+++ b/Documentation/mmc/mmc-dev-attrs.txt
@@ -25,6 +25,8 @@ All attributes are read-only.
serial Product Serial Number (from CID Register)
erase_size Erase group size
preferred_erase_size Preferred erase size
+ raw_rpmb_size_mult RPMB partition size
+ rel_sectors Reliable write sector count
Note on Erase Size and Preferred Erase Size:
@@ -65,6 +67,11 @@ Note on Erase Size and Preferred Erase Size:
"preferred_erase_size" is in bytes.
+Note on raw_rpmb_size_mult:
+ "raw_rpmb_size_mult" is a mutliple of 128kB block.
+ RPMB size in byte is calculated by using the following equation:
+ RPMB partition size = 128kB x raw_rpmb_size_mult
+
SD/MMC/SDIO Clock Gating Attribute
==================================
diff --git a/drivers/mmc/core/mmc.c b/drivers/mmc/core/mmc.c
index 8a459cb..0f2449c 100644
--- a/drivers/mmc/core/mmc.c
+++ b/drivers/mmc/core/mmc.c
@@ -615,6 +615,8 @@ MMC_DEV_ATTR(serial, "0x%08x\n", card->cid.serial);
MMC_DEV_ATTR(enhanced_area_offset, "%llu\n",
card->ext_csd.enhanced_area_offset);
MMC_DEV_ATTR(enhanced_area_size, "%u\n", card->ext_csd.enhanced_area_size);
+MMC_DEV_ATTR(raw_rpmb_size_mult, "%#x\n", card->ext_csd.raw_rpmb_size_mult);
+MMC_DEV_ATTR(rel_sectors, "%#x\n", card->ext_csd.rel_sectors);
static struct attribute *mmc_std_attrs[] = {
&dev_attr_cid.attr,
@@ -630,6 +632,8 @@ static struct attribute *mmc_std_attrs[] = {
&dev_attr_serial.attr,
&dev_attr_enhanced_area_offset.attr,
&dev_attr_enhanced_area_size.attr,
+ &dev_attr_raw_rpmb_size_mult.attr,
+ &dev_attr_rel_sectors.attr,
NULL,
};
--
1.7.11.1
^ permalink raw reply related [flat|nested] 26+ messages in thread* [PATCH v3 4/5] mmc: core: Add mmc_set_blockcount feature
2012-08-06 15:12 [PATCH v3 0/5] mmc: Add access to RPMB partition Loic Pallardy
` (2 preceding siblings ...)
2012-08-06 15:12 ` [PATCH v3 3/5] mmc: core: Extend sysfs to ext_csd parameters for RPMB support Loic Pallardy
@ 2012-08-06 15:12 ` Loic Pallardy
[not found] ` <CAJOk3oEvYUEBAP729nbkxA9XKn=1H6076OPLDSsvq5GP7Z8Qxg@mail.gmail.com>
2012-08-06 15:12 ` [PATCH v3 5/5] mmc: card: Add RPMB support in IOCTL interface Loic Pallardy
` (2 subsequent siblings)
6 siblings, 1 reply; 26+ messages in thread
From: Loic Pallardy @ 2012-08-06 15:12 UTC (permalink / raw)
To: linux-mmc, Chris Ball
Cc: Linus Walleij, STEricsson_nomadik_linux, Ulf Hansson,
Loic Pallardy, Alex Macro, Loic Pallardy
Provide support for automatically sending Set Block Count
(CMD23) messages. Used at least for RPMB support.
Signed-off-by: Alex Macro <alex.macro@stericsson.com>
Signed-off-by: Loic Pallardy <loic.pallardy@stericsson.com>
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Acked-by: Johan Rudholm <johan.rudholm@stericsson.com>
Reviewed-by: Namjae Jeon <linkinjeon@gmail.com>
---
drivers/mmc/core/core.c | 14 ++++++++++++++
include/linux/mmc/core.h | 2 ++
2 files changed, 16 insertions(+)
diff --git a/drivers/mmc/core/core.c b/drivers/mmc/core/core.c
index 0b6141d..7990e2c 100644
--- a/drivers/mmc/core/core.c
+++ b/drivers/mmc/core/core.c
@@ -1827,6 +1827,20 @@ int mmc_set_blocklen(struct mmc_card *card, unsigned int blocklen)
}
EXPORT_SYMBOL(mmc_set_blocklen);
+int mmc_set_blockcount(struct mmc_card *card, unsigned int blockcount,
+ bool is_rel_write)
+{
+ struct mmc_command cmd = {0};
+
+ cmd.opcode = MMC_SET_BLOCK_COUNT;
+ cmd.arg = blockcount & 0x0000FFFF;
+ if (is_rel_write)
+ cmd.arg |= 1 << 31;
+ cmd.flags = MMC_RSP_SPI_R1 | MMC_RSP_R1 | MMC_CMD_AC;
+ return mmc_wait_for_cmd(card->host, &cmd, 5);
+}
+EXPORT_SYMBOL(mmc_set_blockcount);
+
static void mmc_hw_reset_for_init(struct mmc_host *host)
{
if (!(host->caps & MMC_CAP_HW_RESET) || !host->ops->hw_reset)
diff --git a/include/linux/mmc/core.h b/include/linux/mmc/core.h
index 1b431c7..098b7dd 100644
--- a/include/linux/mmc/core.h
+++ b/include/linux/mmc/core.h
@@ -166,6 +166,8 @@ extern int mmc_erase_group_aligned(struct mmc_card *card, unsigned int from,
extern unsigned int mmc_calc_max_discard(struct mmc_card *card);
extern int mmc_set_blocklen(struct mmc_card *card, unsigned int blocklen);
+extern int mmc_set_blockcount(struct mmc_card *card, unsigned int blockcount,
+ bool is_rel_write);
extern int mmc_hw_reset(struct mmc_host *host);
extern int mmc_hw_reset_check(struct mmc_host *host);
extern int mmc_can_reset(struct mmc_card *card);
--
1.7.11.1
^ permalink raw reply related [flat|nested] 26+ messages in thread* [PATCH v3 5/5] mmc: card: Add RPMB support in IOCTL interface
2012-08-06 15:12 [PATCH v3 0/5] mmc: Add access to RPMB partition Loic Pallardy
` (3 preceding siblings ...)
2012-08-06 15:12 ` [PATCH v3 4/5] mmc: core: Add mmc_set_blockcount feature Loic Pallardy
@ 2012-08-06 15:12 ` Loic Pallardy
2012-08-21 7:17 ` shashidhar hiremath
[not found] ` <CAJOk3oERiGjxm-u6iGZLxK0Mq5noC76d33ojwVtY3gtdRBju3g@mail.gmail.com>
[not found] ` <CAJOk3oGMtZvrkw9ic306BKNSKCAzPQCYmJrvq5=zDi1pHjjQxg@mail.gmail.com>
2012-11-17 23:12 ` Chris Ball
6 siblings, 2 replies; 26+ messages in thread
From: Loic Pallardy @ 2012-08-06 15:12 UTC (permalink / raw)
To: linux-mmc, Chris Ball
Cc: Linus Walleij, STEricsson_nomadik_linux, Ulf Hansson,
Loic Pallardy, Alex Macro, Loic Pallardy
RPMB partition is accessing though /dev/block/mmcXrpmb device
User callers can read and write entire data frame(s) as defined
by JEDEC Standard JESD84-A441, using standard IOCTL interface.
Signed-off-by: Alex Macro <alex.macro@stericsson.com>
Signed-off-by: Loic Pallardy <loic.pallardy@stericsson.com>
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Reviewed-by: Namjae Jeon <linkinjeon@gmail.com>
---
drivers/mmc/card/block.c | 64 ++++++++++++++++++++++++++++++++++++++++++++++++
1 file changed, 64 insertions(+)
diff --git a/drivers/mmc/card/block.c b/drivers/mmc/card/block.c
index d8edb8d..a9e1f1f 100644
--- a/drivers/mmc/card/block.c
+++ b/drivers/mmc/card/block.c
@@ -126,6 +126,10 @@ enum mmc_blk_status {
module_param(perdev_minors, int, 0444);
MODULE_PARM_DESC(perdev_minors, "Minors numbers to allocate per device");
+static inline int mmc_blk_part_switch(struct mmc_card *card,
+ struct mmc_blk_data *md);
+static int get_card_status(struct mmc_card *card, u32 *status, int retries);
+
static struct mmc_blk_data *mmc_blk_get(struct gendisk *disk)
{
struct mmc_blk_data *md;
@@ -357,6 +361,38 @@ out:
return ERR_PTR(err);
}
+static int ioctl_rpmb_card_status_poll(struct mmc_card *card, u32 *status,
+ u32 retries_max)
+{
+ int err;
+ u32 retry_count = 0;
+
+ if (!status || !retries_max)
+ return -EINVAL;
+
+ do {
+ err = get_card_status(card, status, 5);
+ if (err)
+ break;
+
+ if (!R1_STATUS(*status) &&
+ (R1_CURRENT_STATE(*status) != R1_STATE_PRG))
+ break; /* RPMB programming operation complete */
+
+ /*
+ * Rechedule to give the MMC device a chance to continue
+ * processing the previous command without being polled too
+ * frequently.
+ */
+ usleep_range(1000, 5000);
+ } while (++retry_count < retries_max);
+
+ if (retry_count == retries_max)
+ err = -EPERM;
+
+ return err;
+}
+
static int mmc_blk_ioctl_cmd(struct block_device *bdev,
struct mmc_ioc_cmd __user *ic_ptr)
{
@@ -368,6 +404,8 @@ static int mmc_blk_ioctl_cmd(struct block_device *bdev,
struct mmc_request mrq = {NULL};
struct scatterlist sg;
int err;
+ int is_rpmb = false;
+ u32 status = 0;
/*
* The caller must have CAP_SYS_RAWIO, and must be calling this on the
@@ -387,6 +425,9 @@ static int mmc_blk_ioctl_cmd(struct block_device *bdev,
goto cmd_err;
}
+ if (md->area_type & MMC_BLK_DATA_AREA_RPMB)
+ is_rpmb = true;
+
card = md->queue.card;
if (IS_ERR(card)) {
err = PTR_ERR(card);
@@ -437,12 +478,23 @@ static int mmc_blk_ioctl_cmd(struct block_device *bdev,
mmc_claim_host(card->host);
+ err = mmc_blk_part_switch(card, md);
+ if (err)
+ goto cmd_rel_host;
+
if (idata->ic.is_acmd) {
err = mmc_app_cmd(card->host, card);
if (err)
goto cmd_rel_host;
}
+ if (is_rpmb) {
+ err = mmc_set_blockcount(card, data.blocks,
+ idata->ic.write_flag & (1 << 31));
+ if (err)
+ goto cmd_rel_host;
+ }
+
mmc_wait_for_req(card->host, &mrq);
if (cmd.error) {
@@ -478,6 +530,18 @@ static int mmc_blk_ioctl_cmd(struct block_device *bdev,
}
}
+ if (is_rpmb) {
+ /*
+ * Ensure RPMB command has completed by polling CMD13
+ * "Send Status".
+ */
+ err = ioctl_rpmb_card_status_poll(card, &status, 5);
+ if (err)
+ dev_err(mmc_dev(card->host),
+ "%s: Card Status=0x%08X, error %d\n",
+ __func__, status, err);
+ }
+
cmd_rel_host:
mmc_release_host(card->host);
--
1.7.11.1
^ permalink raw reply related [flat|nested] 26+ messages in thread* Re: [PATCH v3 5/5] mmc: card: Add RPMB support in IOCTL interface
2012-08-06 15:12 ` [PATCH v3 5/5] mmc: card: Add RPMB support in IOCTL interface Loic Pallardy
@ 2012-08-21 7:17 ` shashidhar hiremath
2012-08-22 7:43 ` Loic pallardy
[not found] ` <CAJOk3oERiGjxm-u6iGZLxK0Mq5noC76d33ojwVtY3gtdRBju3g@mail.gmail.com>
1 sibling, 1 reply; 26+ messages in thread
From: shashidhar hiremath @ 2012-08-21 7:17 UTC (permalink / raw)
To: Loic Pallardy
Cc: linux-mmc, Chris Ball, Linus Walleij, STEricsson_nomadik_linux,
Ulf Hansson, Alex Macro, Loic Pallardy
On Mon, Aug 6, 2012 at 8:42 PM, Loic Pallardy
<loic.pallardy-ext@stericsson.com> wrote:
>
> RPMB partition is accessing though /dev/block/mmcXrpmb device
> User callers can read and write entire data frame(s) as defined
> by JEDEC Standard JESD84-A441, using standard IOCTL interface.
>
> Signed-off-by: Alex Macro <alex.macro@stericsson.com>
> Signed-off-by: Loic Pallardy <loic.pallardy@stericsson.com>
> Acked-by: Linus Walleij <linus.walleij@linaro.org>
> Reviewed-by: Namjae Jeon <linkinjeon@gmail.com>
> ---
> drivers/mmc/card/block.c | 64 ++++++++++++++++++++++++++++++++++++++++++++++++
> 1 file changed, 64 insertions(+)
>
> diff --git a/drivers/mmc/card/block.c b/drivers/mmc/card/block.c
> index d8edb8d..a9e1f1f 100644
> --- a/drivers/mmc/card/block.c
> +++ b/drivers/mmc/card/block.c
> @@ -126,6 +126,10 @@ enum mmc_blk_status {
> module_param(perdev_minors, int, 0444);
> MODULE_PARM_DESC(perdev_minors, "Minors numbers to allocate per device");
>
> +static inline int mmc_blk_part_switch(struct mmc_card *card,
> + struct mmc_blk_data *md);
> +static int get_card_status(struct mmc_card *card, u32 *status, int retries);
> +
> static struct mmc_blk_data *mmc_blk_get(struct gendisk *disk)
> {
> struct mmc_blk_data *md;
> @@ -357,6 +361,38 @@ out:
> return ERR_PTR(err);
> }
>
> +static int ioctl_rpmb_card_status_poll(struct mmc_card *card, u32 *status,
> + u32 retries_max)
> +{
> + int err;
> + u32 retry_count = 0;
> +
> + if (!status || !retries_max)
> + return -EINVAL;
> +
> + do {
> + err = get_card_status(card, status, 5);
> + if (err)
> + break;
> +
> + if (!R1_STATUS(*status) &&
> + (R1_CURRENT_STATE(*status) != R1_STATE_PRG))
> + break; /* RPMB programming operation complete */
> +
> + /*
> + * Rechedule to give the MMC device a chance to continue
> + * processing the previous command without being polled too
> + * frequently.
> + */
> + usleep_range(1000, 5000);
> + } while (++retry_count < retries_max);
> +
> + if (retry_count == retries_max)
> + err = -EPERM;
> +
> + return err;
> +}
> +
> static int mmc_blk_ioctl_cmd(struct block_device *bdev,
> struct mmc_ioc_cmd __user *ic_ptr)
> {
> @@ -368,6 +404,8 @@ static int mmc_blk_ioctl_cmd(struct block_device *bdev,
> struct mmc_request mrq = {NULL};
> struct scatterlist sg;
> int err;
> + int is_rpmb = false;
> + u32 status = 0;
>
> /*
> * The caller must have CAP_SYS_RAWIO, and must be calling this on the
> @@ -387,6 +425,9 @@ static int mmc_blk_ioctl_cmd(struct block_device *bdev,
> goto cmd_err;
> }
>
> + if (md->area_type & MMC_BLK_DATA_AREA_RPMB)
> + is_rpmb = true;
> +
> card = md->queue.card;
> if (IS_ERR(card)) {
> err = PTR_ERR(card);
> @@ -437,12 +478,23 @@ static int mmc_blk_ioctl_cmd(struct block_device *bdev,
>
> mmc_claim_host(card->host);
>
> + err = mmc_blk_part_switch(card, md);
> + if (err)
> + goto cmd_rel_host;
> +
> if (idata->ic.is_acmd) {
> err = mmc_app_cmd(card->host, card);
> if (err)
> goto cmd_rel_host;
> }
>
> + if (is_rpmb) {
> + err = mmc_set_blockcount(card, data.blocks,
> + idata->ic.write_flag & (1 << 31));
> + if (err)
> + goto cmd_rel_host;
> + }
> +
> mmc_wait_for_req(card->host, &mrq);
>
> if (cmd.error) {
> @@ -478,6 +530,18 @@ static int mmc_blk_ioctl_cmd(struct block_device *bdev,
> }
> }
>
> + if (is_rpmb) {
> + /*
> + * Ensure RPMB command has completed by polling CMD13
> + * "Send Status".
> + */
> + err = ioctl_rpmb_card_status_poll(card, &status, 5);
> + if (err)
> + dev_err(mmc_dev(card->host),
> + "%s: Card Status=0x%08X, error %d\n",
> + __func__, status, err);
> + }
> +
> cmd_rel_host:
> mmc_release_host(card->host);
>
> --
> 1.7.11.1
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-mmc" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
Hi,
Any specific reason why the RPMB support is implemented using the
IOCTL interface. Can this be done by the Kernel itself instead of
being initiated by a user space application ?
--
regards,
Shashidhar Hiremath
^ permalink raw reply [flat|nested] 26+ messages in thread* Re: [PATCH v3 5/5] mmc: card: Add RPMB support in IOCTL interface
2012-08-21 7:17 ` shashidhar hiremath
@ 2012-08-22 7:43 ` Loic pallardy
0 siblings, 0 replies; 26+ messages in thread
From: Loic pallardy @ 2012-08-22 7:43 UTC (permalink / raw)
To: shashidhar hiremath
Cc: Loic Pallardy, linux-mmc, Chris Ball, Linus Walleij,
STEricsson_nomadik_linux, Ulf Hansson, Loic Pallardy
>
>
> Hi,
> Any specific reason why the RPMB support is implemented using the
> IOCTL interface. Can this be done by the Kernel itself instead of
> being initiated by a user space application ?
>
> --
> regards,
> Shashidhar Hiremath
> --
Hi,
There are several reasons for that:
- RPMB partition supports only few commands, it is not a "standard" partition
- RPMB data access requests a dedicated data frame which contains MAC,
write counter, address...
- Only trusted/secured applications owns authentification key to
calculate MAC (message authentification code) for each data frame.
So implementing RPMB access in kernel will complexify the driver (link
with security, data frame management...) and create vulnerability from
security point of view.
With this solution, kernel driver provides just a pipe between secured
application and eMMC.
Regards,
Loic
^ permalink raw reply [flat|nested] 26+ messages in thread
[parent not found: <CAJOk3oERiGjxm-u6iGZLxK0Mq5noC76d33ojwVtY3gtdRBju3g@mail.gmail.com>]
* Re: Fwd: [PATCH v3 5/5] mmc: card: Add RPMB support in IOCTL interface
[not found] ` <CAJOk3oERiGjxm-u6iGZLxK0Mq5noC76d33ojwVtY3gtdRBju3g@mail.gmail.com>
@ 2012-11-16 21:23 ` Krishna Konda
0 siblings, 0 replies; 26+ messages in thread
From: Krishna Konda @ 2012-11-16 21:23 UTC (permalink / raw)
To: loic.pallardy-ext, linux-mmc, cjb
Cc: linus.walleij, STEricsson_nomadik_linux, ulf.hansson, alex.macro
On Fri, 2012-11-16 at 13:17 -0800, Krishna Konda wrote:
>
>
> From: Loic Pallardy <loic.pallardy-ext@stericsson.com>
> Date: Mon, Aug 6, 2012 at 8:12 AM
> Subject: [PATCH v3 5/5] mmc: card: Add RPMB support in IOCTL interface
> To: linux-mmc@vger.kernel.org, Chris Ball <cjb@laptop.org>
> Cc: Linus Walleij <linus.walleij@linaro.org>, STEricsson_nomadik_linux
> <STEricsson_nomadik_linux@list.st.com>, Ulf Hansson
> <ulf.hansson@stericcson.com>, Loic Pallardy
> <loic.pallardy-ext@stericsson.com>, Alex Macro
> <alex.macro@stericsson.com>, Loic Pallardy
> <loic.pallardy@stericsson.com>
>
>
> RPMB partition is accessing though /dev/block/mmcXrpmb device
> User callers can read and write entire data frame(s) as defined
> by JEDEC Standard JESD84-A441, using standard IOCTL interface.
>
> Signed-off-by: Alex Macro <alex.macro@stericsson.com>
> Signed-off-by: Loic Pallardy <loic.pallardy@stericsson.com>
> Acked-by: Linus Walleij <linus.walleij@linaro.org>
> Reviewed-by: Namjae Jeon <linkinjeon@gmail.com>
Acked-by: Krishna Konda <kkonda@codeaurora.org>
--
Thanks,
Krishna Konda
-----------------------------------------------------------------------
Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation
-----------------------------------------------------------------------
^ permalink raw reply [flat|nested] 26+ messages in thread
[parent not found: <CAJOk3oGMtZvrkw9ic306BKNSKCAzPQCYmJrvq5=zDi1pHjjQxg@mail.gmail.com>]
* Re: Fwd: [PATCH v3 0/5] mmc: Add access to RPMB partition
[not found] ` <CAJOk3oGMtZvrkw9ic306BKNSKCAzPQCYmJrvq5=zDi1pHjjQxg@mail.gmail.com>
@ 2012-11-14 21:14 ` Krishna Konda
2012-11-15 8:04 ` Linus Walleij
0 siblings, 1 reply; 26+ messages in thread
From: Krishna Konda @ 2012-11-14 21:14 UTC (permalink / raw)
To: loic.pallardy-ext, cjb, linux-mmc
Cc: linus.walleij, STEricsson_nomadik_linux, ulf.hansson
On Wed, 2012-11-14 at 12:58 -0800, Krishna Konda wrote:
> From: Loic Pallardy <loic.pallardy-ext@stericsson.com>
> Date: Mon, Aug 6, 2012 at 8:12 AM
> Subject: [PATCH v3 0/5] mmc: Add access to RPMB partition
> To: linux-mmc@vger.kernel.org, Chris Ball <cjb@laptop.org>
> Cc: Linus Walleij <linus.walleij@linaro.org>, STEricsson_nomadik_linux
> <STEricsson_nomadik_linux@list.st.com>, Ulf Hansson
> <ulf.hansson@stericcson.com>, Loic Pallardy
> <loic.pallardy-ext@stericsson.com>
>
>
> The goal of this patchserie is to offer access to MMC RPMB
> (Replay Protected Memory Block) partition.
> The RPMB partition is used in general to store some secure data.
> It is accessible through a trusted mechanism described in
> JEDEC standard JESD84-A441.
>
> This patchserie proposes following modifications:
> - detect RPMB capability and create RPMB block device if supported
> - extend MMC sysfs to provide access to RPMB partition size and
> reliable write sector count (information needed by user space to
> acces RPMB partition)
> - update IOCTL to support RPMB access. This includes automatic
> partition
> switch and sending of Set Block Count (CMD23) message.
>
> RPMB partition becomes accessible using standard IOCTL interface.
> Patches don't include trusted mechanism or any verification.
> It is user space or secure application responsability to provide the
> right
> command and the entire data frame as defined by JEDEC standard.
> ---
> Changes in v2:
> - Correction in patch 2: mmc: card: Do not scan RPMB partitions
> Remove GENHD_FL_EXT_DEVT flag
>
> Changes in v3:
> - Add acked-by and reviewed-by tags
> ---
> Loic Pallardy (5):
> mmc: core: Expose access to RPMB partition
> mmc: card: Do not scan RPMB partitions
> mmc: core: Extend sysfs to ext_csd parameters for RPMB support
> mmc: core: Add mmc_set_blockcount feature
> mmc: card: Add RPMB support in IOCTL interface
>
> Documentation/mmc/mmc-dev-attrs.txt | 7 ++++
> drivers/mmc/card/block.c | 66
> +++++++++++++++++++++++++++++++++++++
> drivers/mmc/core/core.c | 14 ++++++++
> drivers/mmc/core/mmc.c | 15 +++++++++
> include/linux/mmc/card.h | 2 ++
> include/linux/mmc/core.h | 2 ++
> include/linux/mmc/mmc.h | 2 ++
> 7 files changed, 108 insertions(+)
>
Hi Loic, Chris, are there any plans to merge these patchsets? I did not
see this in mmc-next.
Thanks,
Krishna Konda
--
Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation
^ permalink raw reply [flat|nested] 26+ messages in thread* Re: Fwd: [PATCH v3 0/5] mmc: Add access to RPMB partition
2012-11-14 21:14 ` Fwd: [PATCH v3 0/5] mmc: Add access to RPMB partition Krishna Konda
@ 2012-11-15 8:04 ` Linus Walleij
2012-11-16 21:11 ` Krishna Konda
0 siblings, 1 reply; 26+ messages in thread
From: Linus Walleij @ 2012-11-15 8:04 UTC (permalink / raw)
To: Krishna Konda, Chris Ball
Cc: loic.pallardy-ext, linux-mmc, STEricsson_nomadik_linux, ulf.hansson
On Wed, Nov 14, 2012 at 10:14 PM, Krishna Konda <kkonda@codeaurora.org> wrote:
> On Wed, 2012-11-14 at 12:58 -0800, Krishna Konda wrote:
>
>> The goal of this patchserie is to offer access to MMC RPMB
>> (Replay Protected Memory Block) partition.
>> The RPMB partition is used in general to store some secure data.
>> It is accessible through a trusted mechanism described in
>> JEDEC standard JESD84-A441.
>
> Hi Loic, Chris, are there any plans to merge these patchsets? I did not
> see this in mmc-next.
I was sort of wondering the same.
Krishna, could you provide your Acked-by/Reviewed-by
tag so as to convince Chris that this is a nice feature?
Yours,
Linus Walleij
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: Fwd: [PATCH v3 0/5] mmc: Add access to RPMB partition
2012-11-15 8:04 ` Linus Walleij
@ 2012-11-16 21:11 ` Krishna Konda
2012-11-17 20:19 ` Linus Walleij
0 siblings, 1 reply; 26+ messages in thread
From: Krishna Konda @ 2012-11-16 21:11 UTC (permalink / raw)
To: Linus Walleij
Cc: Chris Ball, loic.pallardy-ext, linux-mmc,
STEricsson_nomadik_linux, ulf.hansson
On Thu, 2012-11-15 at 09:04 +0100, Linus Walleij wrote:
> > Hi Loic, Chris, are there any plans to merge these patchsets? I did not
> > see this in mmc-next.
>
> I was sort of wondering the same.
>
> Krishna, could you provide your Acked-by/Reviewed-by
> tag so as to convince Chris that this is a nice feature?
>
Sure thing.
--
Thanks,
Krishna Konda
-----------------------------------------------------------------------
Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation
-----------------------------------------------------------------------
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: Fwd: [PATCH v3 0/5] mmc: Add access to RPMB partition
2012-11-16 21:11 ` Krishna Konda
@ 2012-11-17 20:19 ` Linus Walleij
0 siblings, 0 replies; 26+ messages in thread
From: Linus Walleij @ 2012-11-17 20:19 UTC (permalink / raw)
To: Krishna Konda, Chris Ball
Cc: loic.pallardy-ext, linux-mmc, STEricsson_nomadik_linux, ulf.hansson
On Fri, Nov 16, 2012 at 10:11 PM, Krishna Konda <kkonda@codeaurora.org> wrote:
> On Thu, 2012-11-15 at 09:04 +0100, Linus Walleij wrote:
>> > Hi Loic, Chris, are there any plans to merge these patchsets? I did not
>> > see this in mmc-next.
>>
>> I was sort of wondering the same.
>>
>> Krishna, could you provide your Acked-by/Reviewed-by
>> tag so as to convince Chris that this is a nice feature?
>
> Sure thing.
Thanks, Chris you have both ST-Ericsson and CodeAurora ACKs
on this patch set, and no technical remarks seen on v3, can
it be applied?
Yours,
Linus Walleij
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [PATCH v3 0/5] mmc: Add access to RPMB partition
2012-08-06 15:12 [PATCH v3 0/5] mmc: Add access to RPMB partition Loic Pallardy
` (5 preceding siblings ...)
[not found] ` <CAJOk3oGMtZvrkw9ic306BKNSKCAzPQCYmJrvq5=zDi1pHjjQxg@mail.gmail.com>
@ 2012-11-17 23:12 ` Chris Ball
2012-11-19 10:09 ` Linus Walleij
2012-11-19 18:12 ` Krishna Konda
6 siblings, 2 replies; 26+ messages in thread
From: Chris Ball @ 2012-11-17 23:12 UTC (permalink / raw)
To: Loic Pallardy
Cc: linux-mmc, Linus Walleij, STEricsson_nomadik_linux, Ulf Hansson,
Krishna Konda
Hi Loic,
On Mon, Aug 06 2012, Loic Pallardy wrote:
> The goal of this patchserie is to offer access to MMC RPMB
> (Replay Protected Memory Block) partition.
> The RPMB partition is used in general to store some secure data.
> It is accessible through a trusted mechanism described in
> JEDEC standard JESD84-A441.
>
> This patchserie proposes following modifications:
> - detect RPMB capability and create RPMB block device if supported
> - extend MMC sysfs to provide access to RPMB partition size and
> reliable write sector count (information needed by user space to
> acces RPMB partition)
> - update IOCTL to support RPMB access. This includes automatic partition
> switch and sending of Set Block Count (CMD23) message.
>
> RPMB partition becomes accessible using standard IOCTL interface.
> Patches don't include trusted mechanism or any verification.
> It is user space or secure application responsability to provide the right
> command and the entire data frame as defined by JEDEC standard.
I've merged this to mmc-next for 3.8 now; thanks to everyone who Acked.
If you have any userspace sample code that could be added to mmc-utils
to show how the interface can be used, feel free to send a patch.
Thanks,
- Chris.
--
Chris Ball <cjb@laptop.org> <http://printf.net/>
One Laptop Per Child
^ permalink raw reply [flat|nested] 26+ messages in thread* Re: [PATCH v3 0/5] mmc: Add access to RPMB partition
2012-11-17 23:12 ` Chris Ball
@ 2012-11-19 10:09 ` Linus Walleij
2012-11-19 18:12 ` Krishna Konda
1 sibling, 0 replies; 26+ messages in thread
From: Linus Walleij @ 2012-11-19 10:09 UTC (permalink / raw)
To: Chris Ball, Loic PALLARDY, Johan Rudholm, Per Forlin
Cc: Loic Pallardy, linux-mmc, STEricsson_nomadik_linux, Ulf Hansson,
Krishna Konda
On Sun, Nov 18, 2012 at 12:12 AM, Chris Ball <cjb@laptop.org> wrote:
> I've merged this to mmc-next for 3.8 now; thanks to everyone who Acked.
Thanks Chris :-)
> If you have any userspace sample code that could be added to mmc-utils
> to show how the interface can be used, feel free to send a patch.
Loïc, Johan: do you have an RPMB example at hand, or could you
cook some nice patch for mmc-utils?
Yours,
Linus Walleij
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [PATCH v3 0/5] mmc: Add access to RPMB partition
2012-11-17 23:12 ` Chris Ball
2012-11-19 10:09 ` Linus Walleij
@ 2012-11-19 18:12 ` Krishna Konda
2012-11-20 8:25 ` Loic PALLARDY
1 sibling, 1 reply; 26+ messages in thread
From: Krishna Konda @ 2012-11-19 18:12 UTC (permalink / raw)
To: Chris Ball
Cc: Loic Pallardy, linux-mmc, Linus Walleij,
STEricsson_nomadik_linux, Ulf Hansson
On Sat, 2012-11-17 at 18:12 -0500, Chris Ball wrote:
> I've merged this to mmc-next for 3.8 now; thanks to everyone who Acked.
>
> If you have any userspace sample code that could be added to mmc-utils
> to show how the interface can be used, feel free to send a patch.
> Thanks,
>
> - Chris.
Thanks Chris. Currently we dont have anything mmc-utils for using this
interface.
--
Thanks,
Krishna Konda
-----------------------------------------------------------------------
Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation
-----------------------------------------------------------------------
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [PATCH v3 0/5] mmc: Add access to RPMB partition
2012-11-19 18:12 ` Krishna Konda
@ 2012-11-20 8:25 ` Loic PALLARDY
2012-11-20 18:54 ` Krishna Konda
0 siblings, 1 reply; 26+ messages in thread
From: Loic PALLARDY @ 2012-11-20 8:25 UTC (permalink / raw)
To: Krishna Konda
Cc: Chris Ball, Loic PALLARDY STE, linux-mmc, Linus Walleij,
STEricsson_nomadik_linux
On 11/19/2012 07:12 PM, Krishna Konda wrote:
> On Sat, 2012-11-17 at 18:12 -0500, Chris Ball wrote:
>> I've merged this to mmc-next for 3.8 now; thanks to everyone who Acked.
>>
>> If you have any userspace sample code that could be added to mmc-utils
>> to show how the interface can be used, feel free to send a patch.
>> Thanks,
>>
>> - Chris.
>
> Thanks Chris. Currently we dont have anything mmc-utils for using this
> interface.
>
Hi,
I have a test program I'll integrate in mmc-utils.
Regards,
Loic
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [PATCH v3 0/5] mmc: Add access to RPMB partition
2012-11-20 8:25 ` Loic PALLARDY
@ 2012-11-20 18:54 ` Krishna Konda
2012-11-21 9:55 ` Loic PALLARDY
0 siblings, 1 reply; 26+ messages in thread
From: Krishna Konda @ 2012-11-20 18:54 UTC (permalink / raw)
To: Loic PALLARDY
Cc: Chris Ball, Loic PALLARDY STE, linux-mmc, Linus Walleij,
STEricsson_nomadik_linux
On Tue, 2012-11-20 at 09:25 +0100, Loic PALLARDY wrote:
>
> I have a test program I'll integrate in mmc-utils.
>
> Regards,
> Loic
Loic/Linus/Chris, I think the IOCTL is not complete in terms of handling
the RPMB requests. Here is why I think that is - let me know your
opinion
There are four request types that are needed to be supported - two under
read category and two under write. They are
Reads
-------
1. Read Write Counter
2. Authenticated data read
Writes
-------
1. Provision RPMB key (though it might be done in a secure environment)
2. Authenticated data read
While its given that the rpmb data frames are going to have that
information encoded in it and the frames will be generated by a secure
piece of code, the request types can be classified as above.
The ioctl interface to do this but currently that does the following
1. Switch partition
2. Set block count
3. One command - whatever is passed in by the userspace application.
So here are the set of commands that need to happen in a rpmb read
operation
1. Switch partition
2. Set block count
3. Write data frame - CMD25 to write the rpmb data frame
4. Set block count
5. Read the data - CMD18 to do the actual read
I am guessing that you would expect the userspace application too call
into the ioctl twice to take care of the 4 & 5 and that might not be an
issue if there was no request processed for mmcqd i.e. no other
process/thread claims the host. But if that were to happen, then the
rpmb operation will fail - please let me know if this assumption or my
understanding of the spec is wrong.
Similarly for rpmb write operation, these are the step involved
1. Switch partition
2. Set block count
3. Write data frame - CMD25 to write the rpmb data frame with data
4. Set block count
5. Read the data - CMD25 to write rpmb data frame indicating that rpmb
result register is about to be read
6. Set block count
7. Read rpmb result - CMD18 to read the rpmb result register
In the case of write, there are an additional two commands compared to
reads. Since all of these needs to be done in one shot, I believe the
current ioctl is not sufficient and this can be handled in the following
ways
1. Extend the current ioctl to handle both cases
2. Add a new ioctl cmd for rpmb requests
Personally I think adding another ioctl is a better way to do this since
the current ioctl will get cumbersome and technically the rpmb requests
are different kind of requests that need to be done atomically. I am
coding this up as a separate ioctl but before I post the patch, I wanted
feedback on this approach.
--
Thanks,
Krishna Konda
-----------------------------------------------------------------------
Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation
-----------------------------------------------------------------------
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [PATCH v3 0/5] mmc: Add access to RPMB partition
2012-11-20 18:54 ` Krishna Konda
@ 2012-11-21 9:55 ` Loic PALLARDY
2012-11-21 11:02 ` Sundar J. Dev
0 siblings, 1 reply; 26+ messages in thread
From: Loic PALLARDY @ 2012-11-21 9:55 UTC (permalink / raw)
To: Krishna Konda
Cc: Chris Ball, Loic PALLARDY STE, linux-mmc, Linus Walleij,
STEricsson_nomadik_linux
Hi Krishna,
On 11/20/2012 07:54 PM, Krishna Konda wrote:
>
> Loic/Linus/Chris, I think the IOCTL is not complete in terms of handling
> the RPMB requests. Here is why I think that is - let me know your
> opinion
>
> There are four request types that are needed to be supported - two under
> read category and two under write. They are
>
> Reads
> -------
> 1. Read Write Counter
> 2. Authenticated data read
>
>
> Writes
> -------
> 1. Provision RPMB key (though it might be done in a secure environment)
> 2. Authenticated data read
Agree
>
> While its given that the rpmb data frames are going to have that
> information encoded in it and the frames will be generated by a secure
> piece of code, the request types can be classified as above.
>
> The ioctl interface to do this but currently that does the following
> 1. Switch partition
> 2. Set block count
> 3. One command - whatever is passed in by the userspace application.
>
> So here are the set of commands that need to happen in a rpmb read
> operation
> 1. Switch partition
> 2. Set block count
> 3. Write data frame - CMD25 to write the rpmb data frame
> 4. Set block count
> 5. Read the data - CMD18 to do the actual read
>
> I am guessing that you would expect the userspace application too call
> into the ioctl twice to take care of the 4& 5
Yes exactly, you have to first send your command and then to read the
result, 2 IOCTLs are needed
> and that might not be an
> issue if there was no request processed for mmcqd i.e. no other
> process/thread claims the host. But if that were to happen, then the
> rpmb operation will fail - please let me know if this assumption or my
> understanding of the spec is wrong.
I tested this and I don't identify issue.
I have Android running in parallel of my test and lot of other mmc
accesses are performed in parallel, so my test suite doesn't guarantee
that the 2 ioctls are contiguous.
I had the same understanding of the RPMB specification, but after tests
and discussion with our eMMC provider, it appears that RPMB state
machine is independent of the rest.
>
> Similarly for rpmb write operation, these are the step involved
> 1. Switch partition
> 2. Set block count
> 3. Write data frame - CMD25 to write the rpmb data frame with data
> 4. Set block count
> 5. Read the data - CMD25 to write rpmb data frame indicating that rpmb
> result register is about to be read
> 6. Set block count
> 7. Read rpmb result - CMD18 to read the rpmb result register
>
> In the case of write, there are an additional two commands compared to
> reads. Since all of these needs to be done in one shot, I believe the
> current ioctl is not sufficient and this can be handled in the following
> ways
No needed to do it in one shot. You can send the write and check status
later.
I tested it, didn't detect any problem.
>
> 1. Extend the current ioctl to handle both cases
> 2. Add a new ioctl cmd for rpmb requests
It was my first implementation, but after internal STE review and eMMC
check I merge it in existing ioctl.
Please let me know if you detect any issue.
Regards,
Loic
>
> Personally I think adding another ioctl is a better way to do this since
> the current ioctl will get cumbersome and technically the rpmb requests
> are different kind of requests that need to be done atomically. I am
> coding this up as a separate ioctl but before I post the patch, I wanted
> feedback on this approach.
>
>
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [PATCH v3 0/5] mmc: Add access to RPMB partition
2012-11-21 9:55 ` Loic PALLARDY
@ 2012-11-21 11:02 ` Sundar J. Dev
2012-11-21 17:32 ` Loic PALLARDY
0 siblings, 1 reply; 26+ messages in thread
From: Sundar J. Dev @ 2012-11-21 11:02 UTC (permalink / raw)
To: Loic PALLARDY
Cc: Krishna Konda, Chris Ball, Loic PALLARDY STE, linux-mmc,
Linus Walleij, STEricsson_nomadik_linux
Hi Loic,
On Wed, Nov 21, 2012 at 3:25 PM, Loic PALLARDY <loic.pallardy@st.com> wrote:
>
> Hi Krishna,
>
> On 11/20/2012 07:54 PM, Krishna Konda wrote:
> >
> > Loic/Linus/Chris, I think the IOCTL is not complete in terms of handling
> > the RPMB requests. Here is why I think that is - let me know your
> > opinion
> >
> > There are four request types that are needed to be supported - two under
> > read category and two under write. They are
> >
> > Reads
> > -------
> > 1. Read Write Counter
> > 2. Authenticated data read
> >
> >
> > Writes
> > -------
> > 1. Provision RPMB key (though it might be done in a secure environment)
> > 2. Authenticated data read
> Agree
> >
> > While its given that the rpmb data frames are going to have that
> > information encoded in it and the frames will be generated by a secure
> > piece of code, the request types can be classified as above.
> >
> > The ioctl interface to do this but currently that does the following
> > 1. Switch partition
> > 2. Set block count
> > 3. One command - whatever is passed in by the userspace application.
> >
> > So here are the set of commands that need to happen in a rpmb read
> > operation
> > 1. Switch partition
> > 2. Set block count
> > 3. Write data frame - CMD25 to write the rpmb data frame
> > 4. Set block count
> > 5. Read the data - CMD18 to do the actual read
> >
> > I am guessing that you would expect the userspace application too call
> > into the ioctl twice to take care of the 4& 5
> Yes exactly, you have to first send your command and then to read the
> result, 2 IOCTLs are needed
>
> > and that might not be an
> > issue if there was no request processed for mmcqd i.e. no other
> > process/thread claims the host. But if that were to happen, then the
> > rpmb operation will fail - please let me know if this assumption or my
> > understanding of the spec is wrong.
> I tested this and I don't identify issue.
> I have Android running in parallel of my test and lot of other mmc
> accesses are performed in parallel, so my test suite doesn't guarantee
> that the 2 ioctls are contiguous.
> I had the same understanding of the RPMB specification, but after tests
> and discussion with our eMMC provider, it appears that RPMB state
> machine is independent of the rest.
I have seen the issue described by Krishna in one of the Micron eMMC
parts that I tested on. I captured the below CMD snapshot to explain
this better:
-------> ***** START RPMB TRANSACTION *****
--> RPMB CMD6 - Switch to RPMB partition
--> RPMB CMD23 - Set BLK_CNT
--> RPMB CMD25 - Issue a Mult Blk Write
--> RPMB CMD13 - Issue Status CMD and and check for Write completion
-------> ***** RPMB TRANSACTION ABORTED BY NON-RPMB ACCESS *****
--> NON-RPMB CMD6 - Switch to Userdata partition
--> NON-RPMB CMD23 - Set BLK_CNT
--> NON-RPMB CMD25 - Issue Mutl Blk Write
--> NON-RPMB CMD12 - Issue Status CMD and and check for completion
-------> ***** SWITCH BACK TO RPMB PARTITION *****
--> RPMB CMD6 - Switch back to RPMB partition
--> RPMB CMD23 - Set BLK_CNT
--> RPMB CMD18 - Issue a Mult Blk Read
The RPMB device returns GENERAL FAILURE in the Read data Packet.
Actually, the eMMC JEDEC spec is not very clear on what is the expected
behavior from eMMC chip if a rpmb sequence is interrupted by a non-rpmb
command sequence. It works fine on most Samsung and Toshiba
eMMC parts that I tested rpmb on. But this one Micron eMMC part showed
this problem.
> >
> > Similarly for rpmb write operation, these are the step involved
> > 1. Switch partition
> > 2. Set block count
> > 3. Write data frame - CMD25 to write the rpmb data frame with data
> > 4. Set block count
> > 5. Read the data - CMD25 to write rpmb data frame indicating that rpmb
> > result register is about to be read
> > 6. Set block count
> > 7. Read rpmb result - CMD18 to read the rpmb result register
> >
> > In the case of write, there are an additional two commands compared to
> > reads. Since all of these needs to be done in one shot, I believe the
> > current ioctl is not sufficient and this can be handled in the following
> > ways
>
> No needed to do it in one shot. You can send the write and check status
> later.
> I tested it, didn't detect any problem.
> >
> > 1. Extend the current ioctl to handle both cases
> > 2. Add a new ioctl cmd for rpmb requests
> It was my first implementation, but after internal STE review and eMMC
> check I merge it in existing ioctl.
>
> Please let me know if you detect any issue.
>
> Regards,
> Loic
> >
> > Personally I think adding another ioctl is a better way to do this since
> > the current ioctl will get cumbersome and technically the rpmb requests
> > are different kind of requests that need to be done atomically. I am
> > coding this up as a separate ioctl but before I post the patch, I wanted
> > feedback on this approach.
> >
> >
Thanks,
--
Sundar Jayakumar Dev
^ permalink raw reply [flat|nested] 26+ messages in thread* Re: [PATCH v3 0/5] mmc: Add access to RPMB partition
2012-11-21 11:02 ` Sundar J. Dev
@ 2012-11-21 17:32 ` Loic PALLARDY
2012-11-22 4:32 ` Sundar J. Dev
0 siblings, 1 reply; 26+ messages in thread
From: Loic PALLARDY @ 2012-11-21 17:32 UTC (permalink / raw)
To: Sundar J. Dev
Cc: Krishna Konda, Chris Ball, Loic PALLARDY STE, linux-mmc,
Linus Walleij, STEricsson_nomadik_linux
Hi Sundar,
On 11/21/2012 12:02 PM, Sundar J. Dev wrote:
> Hi Loic,
>
> On Wed, Nov 21, 2012 at 3:25 PM, Loic PALLARDY<loic.pallardy@st.com> wrote:
>>
>>>
>>> I am guessing that you would expect the userspace application too call
>>> into the ioctl twice to take care of the 4& 5
>> Yes exactly, you have to first send your command and then to read the
>> result, 2 IOCTLs are needed
>>
>>> and that might not be an
>>> issue if there was no request processed for mmcqd i.e. no other
>>> process/thread claims the host. But if that were to happen, then the
>>> rpmb operation will fail - please let me know if this assumption or my
>>> understanding of the spec is wrong.
>> I tested this and I don't identify issue.
>> I have Android running in parallel of my test and lot of other mmc
>> accesses are performed in parallel, so my test suite doesn't guarantee
>> that the 2 ioctls are contiguous.
>> I had the same understanding of the RPMB specification, but after tests
>> and discussion with our eMMC provider, it appears that RPMB state
>> machine is independent of the rest.
> I have seen the issue described by Krishna in one of the Micron eMMC
> parts that I tested on. I captured the below CMD snapshot to explain
> this better:
> -------> ***** START RPMB TRANSACTION *****
> --> RPMB CMD6 - Switch to RPMB partition
> --> RPMB CMD23 - Set BLK_CNT
> --> RPMB CMD25 - Issue a Mult Blk Write
> --> RPMB CMD13 - Issue Status CMD and and check for Write completion
> -------> ***** RPMB TRANSACTION ABORTED BY NON-RPMB ACCESS *****
> --> NON-RPMB CMD6 - Switch to Userdata partition
> --> NON-RPMB CMD23 - Set BLK_CNT
> --> NON-RPMB CMD25 - Issue Mutl Blk Write
> --> NON-RPMB CMD12 - Issue Status CMD and and check for completion
> -------> ***** SWITCH BACK TO RPMB PARTITION *****
> --> RPMB CMD6 - Switch back to RPMB partition
> --> RPMB CMD23 - Set BLK_CNT
> --> RPMB CMD18 - Issue a Mult Blk Read
> The RPMB device returns GENERAL FAILURE in the Read data Packet.
>
Humm yes log is clear. Micron eMMC doesn't seem to accept interruption
during RPMB sequence.
Is it working when transfer is not interrupted?
I tested on Toshiba and Sandisk without issue but it is not exhaustive
enough.
In your test, how many half sectors (256B) are you programming?
I got some general failure when writing more than one half sector on
some devices, but it has been explained by vendor.
> Actually, the eMMC JEDEC spec is not very clear on what is the expected
> behavior from eMMC chip if a rpmb sequence is interrupted by a non-rpmb
> command sequence. It works fine on most Samsung and Toshiba
> eMMC parts that I tested rpmb on. But this one Micron eMMC part showed
> this problem.
Yes unclear eMMC JEDEC spec about RPMB was reported by our eMMC provider.
>>>
>>> Similarly for rpmb write operation, these are the step involved
>>> 1. Switch partition
>>> 2. Set block count
>>> 3. Write data frame - CMD25 to write the rpmb data frame with data
>>> 4. Set block count
>>> 5. Read the data - CMD25 to write rpmb data frame indicating that rpmb
>>> result register is about to be read
>>> 6. Set block count
>>> 7. Read rpmb result - CMD18 to read the rpmb result register
>>>
>>> In the case of write, there are an additional two commands compared to
>>> reads. Since all of these needs to be done in one shot, I believe the
>>> current ioctl is not sufficient and this can be handled in the following
>>> ways
>>
>> No needed to do it in one shot. You can send the write and check status
>> later.
>> I tested it, didn't detect any problem.
>>>
>>> 1. Extend the current ioctl to handle both cases
>>> 2. Add a new ioctl cmd for rpmb requests
>> It was my first implementation, but after internal STE review and eMMC
>> check I merge it in existing ioctl.
>>
>> Please let me know if you detect any issue.
>>
>> Regards,
>> Loic
>>>
>>> Personally I think adding another ioctl is a better way to do this since
>>> the current ioctl will get cumbersome and technically the rpmb requests
>>> are different kind of requests that need to be done atomically. I am
>>> coding this up as a separate ioctl but before I post the patch, I wanted
>>> feedback on this approach.
>>>
Solution must be driven by the most constrained device.
In that case, I agree with Krishna, in that case a new ioctl seems to be
the better approach.
Regards,
Loic
>>>
>
> Thanks,
> --
> Sundar Jayakumar Dev
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [PATCH v3 0/5] mmc: Add access to RPMB partition
2012-11-21 17:32 ` Loic PALLARDY
@ 2012-11-22 4:32 ` Sundar J. Dev
0 siblings, 0 replies; 26+ messages in thread
From: Sundar J. Dev @ 2012-11-22 4:32 UTC (permalink / raw)
To: Loic PALLARDY
Cc: Krishna Konda, Chris Ball, Loic PALLARDY STE, linux-mmc,
Linus Walleij, STEricsson_nomadik_linux
Hi Loic,
On Wed, Nov 21, 2012 at 11:02 PM, Loic PALLARDY <loic.pallardy@st.com> wrote:
> Hi Sundar,
>
> On 11/21/2012 12:02 PM, Sundar J. Dev wrote:
>> Hi Loic,
>>
>> On Wed, Nov 21, 2012 at 3:25 PM, Loic PALLARDY<loic.pallardy@st.com> wrote:
>>>
>>>>
>>>> I am guessing that you would expect the userspace application too call
>>>> into the ioctl twice to take care of the 4& 5
>>> Yes exactly, you have to first send your command and then to read the
>>> result, 2 IOCTLs are needed
>>>
>>>> and that might not be an
>>>> issue if there was no request processed for mmcqd i.e. no other
>>>> process/thread claims the host. But if that were to happen, then the
>>>> rpmb operation will fail - please let me know if this assumption or my
>>>> understanding of the spec is wrong.
>>> I tested this and I don't identify issue.
>>> I have Android running in parallel of my test and lot of other mmc
>>> accesses are performed in parallel, so my test suite doesn't guarantee
>>> that the 2 ioctls are contiguous.
>>> I had the same understanding of the RPMB specification, but after tests
>>> and discussion with our eMMC provider, it appears that RPMB state
>>> machine is independent of the rest.
>> I have seen the issue described by Krishna in one of the Micron eMMC
>> parts that I tested on. I captured the below CMD snapshot to explain
>> this better:
>> -------> ***** START RPMB TRANSACTION *****
>> --> RPMB CMD6 - Switch to RPMB partition
>> --> RPMB CMD23 - Set BLK_CNT
>> --> RPMB CMD25 - Issue a Mult Blk Write
>> --> RPMB CMD13 - Issue Status CMD and and check for Write completion
>> -------> ***** RPMB TRANSACTION ABORTED BY NON-RPMB ACCESS *****
>> --> NON-RPMB CMD6 - Switch to Userdata partition
>> --> NON-RPMB CMD23 - Set BLK_CNT
>> --> NON-RPMB CMD25 - Issue Mutl Blk Write
>> --> NON-RPMB CMD12 - Issue Status CMD and and check for completion
>> -------> ***** SWITCH BACK TO RPMB PARTITION *****
>> --> RPMB CMD6 - Switch back to RPMB partition
>> --> RPMB CMD23 - Set BLK_CNT
>> --> RPMB CMD18 - Issue a Mult Blk Read
>> The RPMB device returns GENERAL FAILURE in the Read data Packet.
>>
> Humm yes log is clear. Micron eMMC doesn't seem to accept interruption
> during RPMB sequence.
> Is it working when transfer is not interrupted?
Yes, it was working when the rpmb transaction is not interrupted by
non-rpmb access.
> I tested on Toshiba and Sandisk without issue but it is not exhaustive
> enough.
> In your test, how many half sectors (256B) are you programming?
I was programming one half sector.
> I got some general failure when writing more than one half sector on
> some devices, but it has been explained by vendor.
>
>> Actually, the eMMC JEDEC spec is not very clear on what is the expected
>> behavior from eMMC chip if a rpmb sequence is interrupted by a non-rpmb
>> command sequence. It works fine on most Samsung and Toshiba
>> eMMC parts that I tested rpmb on. But this one Micron eMMC part showed
>> this problem.
> Yes unclear eMMC JEDEC spec about RPMB was reported by our eMMC provider.
>
>>>>
>>>> Similarly for rpmb write operation, these are the step involved
>>>> 1. Switch partition
>>>> 2. Set block count
>>>> 3. Write data frame - CMD25 to write the rpmb data frame with data
>>>> 4. Set block count
>>>> 5. Read the data - CMD25 to write rpmb data frame indicating that rpmb
>>>> result register is about to be read
>>>> 6. Set block count
>>>> 7. Read rpmb result - CMD18 to read the rpmb result register
>>>>
>>>> In the case of write, there are an additional two commands compared to
>>>> reads. Since all of these needs to be done in one shot, I believe the
>>>> current ioctl is not sufficient and this can be handled in the following
>>>> ways
>>>
>>> No needed to do it in one shot. You can send the write and check status
>>> later.
>>> I tested it, didn't detect any problem.
>>>>
>>>> 1. Extend the current ioctl to handle both cases
>>>> 2. Add a new ioctl cmd for rpmb requests
>>> It was my first implementation, but after internal STE review and eMMC
>>> check I merge it in existing ioctl.
>>>
>>> Please let me know if you detect any issue.
>>>
>>> Regards,
>>> Loic
>>>>
>>>> Personally I think adding another ioctl is a better way to do this since
>>>> the current ioctl will get cumbersome and technically the rpmb requests
>>>> are different kind of requests that need to be done atomically. I am
>>>> coding this up as a separate ioctl but before I post the patch, I wanted
>>>> feedback on this approach.
>>>>
> Solution must be driven by the most constrained device.
> In that case, I agree with Krishna, in that case a new ioctl seems to be
> the better approach.
I second that. This must be the right way to do it. I can help test the patch
on this Micron eMMC if needed.
>
> Regards,
> Loic
>>>>
>>
>> Thanks,
>> --
>> Sundar Jayakumar Dev
Thanks,
--
Sundar Jayakumar Dev
^ permalink raw reply [flat|nested] 26+ messages in thread