[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