[lkml]   [2022]   [Apr]   [24]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH v1 2/2] mmc: core: Allows to override the timeout value for ioctl() path
On Sun, Apr 24, 2022 at 12:16 AM Bean Huo <> wrote:

> From: Bean Huo <>
> Occasionally, user-land applications initiate longer timeout values for certain commands
> through ioctl() system call. But so far we are still using a fixed timeout of 10 seconds
> in mmc_poll_for_busy() on the ioctl() path, even if a custom timeout is specified in the
> userspace application. This patch allows custom timeout values to override this default
> timeout values on the ioctl path.
> Cc: stable <>
> Signed-off-by: Bean Huo <>
> if (idata->rpmb || (cmd.flags & MMC_RSP_R1B) == MMC_RSP_R1B) {
> /*
> - * Ensure RPMB/R1B command has completed by polling CMD13
> - * "Send Status".
> + * 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.
> */
> - err = mmc_poll_for_busy(card, MMC_BLK_TIMEOUT_MS, false,
> + err = mmc_poll_for_busy(card, idata->ic.cmd_timeout_ms ? : MMC_BLK_TIMEOUT_MS,
> + false, MMC_BUSY_IO);

I suppose it's OK (albeit dubious) that we have a userspace interface setting
a hardware-specific thing such as a timeout.

However: is MMC_BLK_TIMEOUT_MS even reasonable here? If you guys
know a better timeout for RPMB operations (from your experience)
what about defining MMC_RPMB_TIMEOUT_MS to something more
reasonable (and I suppose longer) and use that as fallback instead

This knowledge (that RPMB commands can have long timeouts) is not
something that should be hidden in userspace.

Linus Walleij

 \ /
  Last update: 2022-04-24 15:30    [W:0.073 / U:8.572 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site