On Mon, 16 Jan 2023 at 15:38, Christian Löhle <CLoehle@xxxxxxxxxxxxxx> wrote:
>
> The ioctl interface allowed to set cmd_timeout_ms when polling for
> busy on R1B commands. This was often limited by the max hw timeout
> so work around it like for the sanitize command.
>
> Signed-off-by: Christian Loehle <cloehle@xxxxxxxxxxxxxx>
> ---
> drivers/mmc/core/block.c | 10 +++++++++-
> 1 file changed, 9 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/mmc/core/block.c b/drivers/mmc/core/block.c
> index 20da7ed43e6d..ba3bc9014179 100644
> --- a/drivers/mmc/core/block.c
> +++ b/drivers/mmc/core/block.c
> @@ -472,6 +472,8 @@ static int __mmc_blk_ioctl_cmd(struct mmc_card *card, struct mmc_blk_data *md,
> struct scatterlist sg;
> int err;
> unsigned int target_part;
> + unsigned int busy_timeout = MMC_BLK_TIMEOUT_MS;
> + int poll_prog = false;
>
> if (!card || !md || !idata)
> return -EINVAL;
> @@ -493,6 +495,12 @@ static int __mmc_blk_ioctl_cmd(struct mmc_card *card, struct mmc_blk_data *md,
> cmd.opcode = idata->ic.opcode;
> cmd.arg = idata->ic.arg;
> cmd.flags = idata->ic.flags;
> + /* R1B flag might be removed here to work around hw, so save it */
> + poll_prog = (idata->rpmb || (cmd.flags & MMC_RSP_R1B) == MMC_RSP_R1B);
> + busy_timeout = idata->ic.cmd_timeout_ms ? :
> + MMC_BLK_TIMEOUT_MS;
> + if (poll_prog)
> + mmc_prepare_busy_cmd(card->host, &cmd, busy_timeout);
This may end up using R1B for rpmb commands, we don't want that.
>
> if (idata->buf_bytes) {
> data.sg = &sg;
> @@ -596,7 +604,7 @@ static int __mmc_blk_ioctl_cmd(struct mmc_card *card, struct mmc_blk_data *md,
> if (idata->ic.postsleep_min_us)
> usleep_range(idata->ic.postsleep_min_us, idata->ic.postsleep_max_us);
>
> - if (idata->rpmb || (cmd.flags & MMC_RSP_R1B) == MMC_RSP_R1B) {
> + if (poll_prog) {
If we end up using R1B and the host supports HW busy detection, we
should skip polling.
> /*
> * Ensure RPMB/R1B command has completed by polling CMD13 "Send Status". Here we
> * allow to override the default timeout value if a custom timeout is specified.
I believe I understand the problem you are trying to address in the
$subject patch. Let me try to help out, by sending a re-worked patch
to try to cover the things I pointed out above in a more consistent
way.
Kind regards
Uffe
