On Sun, Apr 24, 2022 at 12:16 AM Bean Huo huobean@gmail.com wrote:
From: Bean Huo beanhuo@micron.com
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 stable@vger.kernel.org Signed-off-by: Bean Huo beanhuo@micron.com
(...)
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,MMC_BUSY_IO);
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 of MMC_BLK_TIMEOUT_MS?
This knowledge (that RPMB commands can have long timeouts) is not something that should be hidden in userspace.
Yours, Linus Walleij