[PATCH][Trusty/Utopic/Vivid] mmc: card: Don't access RPMB partitions for normal read/write
Andy Whitcroft
apw at canonical.com
Wed May 13 14:15:22 UTC 2015
On Wed, May 13, 2015 at 03:21:15PM +0800, Adam Lee wrote:
> From: Chuanxiao Dong <chuanxiao.dong at intel.com>
>
> During kernel boot, it will try to read some logical sectors
> of each block device node for the possible partition table.
>
> But since RPMB partition is special and can not be accessed
> by normal eMMC read / write CMDs, it will cause below error
> messages during kernel boot:
> ...
> mmc0: Got data interrupt 0x00000002 even though no data operation was in progress.
> mmcblk0rpmb: error -110 transferring data, sector 0, nr 32, cmd response 0x900, card status 0xb00
> mmcblk0rpmb: retrying using single block read
> mmcblk0rpmb: timed out sending r/w cmd command, card status 0x400900
> mmcblk0rpmb: timed out sending r/w cmd command, card status 0x400900
> mmcblk0rpmb: timed out sending r/w cmd command, card status 0x400900
> mmcblk0rpmb: timed out sending r/w cmd command, card status 0x400900
> mmcblk0rpmb: timed out sending r/w cmd command, card status 0x400900
> mmcblk0rpmb: timed out sending r/w cmd command, card status 0x400900
> end_request: I/O error, dev mmcblk0rpmb, sector 0
> Buffer I/O error on device mmcblk0rpmb, logical block 0
> end_request: I/O error, dev mmcblk0rpmb, sector 8
> Buffer I/O error on device mmcblk0rpmb, logical block 1
> end_request: I/O error, dev mmcblk0rpmb, sector 16
> Buffer I/O error on device mmcblk0rpmb, logical block 2
> end_request: I/O error, dev mmcblk0rpmb, sector 24
> Buffer I/O error on device mmcblk0rpmb, logical block 3
> ...
>
> This patch will discard the access request in eMMC queue if
> it is RPMB partition access request. By this way, it avoids
> trigger above error messages.
>
> Fixes: 090d25fe224c ("mmc: core: Expose access to RPMB partition")
> Signed-off-by: Yunpeng Gao <yunpeng.gao at intel.com>
> Signed-off-by: Chuanxiao Dong <chuanxiao.dong at intel.com>
> Tested-by: Michael Shigorin <mike at altlinux.org>
> Signed-off-by: Ulf Hansson <ulf.hansson at linaro.org>
> (cherry picked from commit 4e93b9a6abc0d028daf3c8a00cb77b679d8a4df4)
> Signed-off-by: Adam Lee <adam.lee at canonical.com>
> ---
> drivers/mmc/card/block.c | 12 ++++++++++++
> drivers/mmc/card/queue.c | 2 +-
> drivers/mmc/card/queue.h | 2 ++
> 3 files changed, 15 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/mmc/card/block.c b/drivers/mmc/card/block.c
> index 7b5424f..42e4c88 100644
> --- a/drivers/mmc/card/block.c
> +++ b/drivers/mmc/card/block.c
> @@ -951,6 +951,18 @@ static inline void mmc_blk_reset_success(struct mmc_blk_data *md, int type)
> md->reset_done &= ~type;
> }
>
> +int mmc_access_rpmb(struct mmc_queue *mq)
> +{
> + struct mmc_blk_data *md = mq->data;
> + /*
> + * If this is a RPMB partition access, return ture
> + */
> + if (md && md->part_type == EXT_CSD_PART_CONFIG_ACC_RPMB)
> + return true;
> +
> + return false;
> +}
> +
> static int mmc_blk_issue_discard_rq(struct mmc_queue *mq, struct request *req)
> {
> struct mmc_blk_data *md = mq->data;
> diff --git a/drivers/mmc/card/queue.c b/drivers/mmc/card/queue.c
> index 3e049c1..6ceede0 100644
> --- a/drivers/mmc/card/queue.c
> +++ b/drivers/mmc/card/queue.c
> @@ -38,7 +38,7 @@ static int mmc_prep_request(struct request_queue *q, struct request *req)
> return BLKPREP_KILL;
> }
>
> - if (mq && mmc_card_removed(mq->card))
> + if (mq && (mmc_card_removed(mq->card) || mmc_access_rpmb(mq)))
> return BLKPREP_KILL;
>
> req->cmd_flags |= REQ_DONTPREP;
> diff --git a/drivers/mmc/card/queue.h b/drivers/mmc/card/queue.h
> index 5752d50..99e6521 100644
> --- a/drivers/mmc/card/queue.h
> +++ b/drivers/mmc/card/queue.h
> @@ -73,4 +73,6 @@ extern void mmc_queue_bounce_post(struct mmc_queue_req *);
> extern int mmc_packed_init(struct mmc_queue *, struct mmc_card *);
> extern void mmc_packed_clean(struct mmc_queue *);
>
> +extern int mmc_access_rpmb(struct mmc_queue *);
> +
> #endif
This seems to just quiet a small number of benign errors on boot? Do we
really need to worry about these?? It does not feel like they are
harmful?
-apw
More information about the kernel-team
mailing list