From: Linus Walleij <linus.walleij@linaro.org>
To: Bean Huo <huobean@gmail.com>
Cc: ulf.hansson@linaro.org, adrian.hunter@intel.com,
linux-mmc@vger.kernel.org, linux-kernel@vger.kernel.org,
beanhuo@micron.com, stable <stable@vger.kernel.org>
Subject: Re: [PATCH v1 2/2] mmc: core: Allows to override the timeout value for ioctl() path
Date: Mon, 25 Apr 2022 22:15:43 +0200 [thread overview]
Message-ID: <CACRpkdbM_qhwmFhwJNx0J_r2jUHoSsE6B=bKhGwKG=dXtX7uEg@mail.gmail.com> (raw)
In-Reply-To: <89845bec6c827d7012cda916ee50b16c8eb08755.camel@gmail.com>
On Mon, Apr 25, 2022 at 10:02 PM Bean Huo <huobean@gmail.com> wrote:
> I think the current solution is the most flexible way, if the customer
> wants to override the kernel default timeout, they know how to initiate
> the correct timeout value in ioctl() based on their specific
> hardware/software system. I don't know how to convince every maintainer
> and reviewer if we don't want to give this permission or want to
> maintain a unified timeout value in the kernel driver. Given that we
> already have eMMC ioctl() support, and we've opened the door to allow
> users to specify specific cmd_timeout_ms in struct mmc_ioc_cmd{},
> please consider my change.
The patch is fine, I'm just saying we should put another patch on
top that defines a RPMB default timeout and set it to something
high, such as a minute.
Yours,
Linus Walleij
next prev parent reply other threads:[~2022-04-25 20:15 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-04-23 22:16 [PATCH v1 0/2] Two changes for eMMC Bean Huo
2022-04-23 22:16 ` [PATCH v1 1/2] mmc: sdhci-omap: Use of_device_get_match_data() helper Bean Huo
2022-04-26 13:55 ` Ulf Hansson
2022-04-23 22:16 ` [PATCH v1 2/2] mmc: core: Allows to override the timeout value for ioctl() path Bean Huo
2022-04-24 11:52 ` Avri Altman
2022-04-24 13:29 ` Linus Walleij
2022-04-25 20:01 ` Bean Huo
2022-04-25 20:15 ` Linus Walleij [this message]
2022-04-26 13:32 ` Ulf Hansson
2022-04-26 13:55 ` Ulf Hansson
2022-04-26 15:35 ` Linus Walleij
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CACRpkdbM_qhwmFhwJNx0J_r2jUHoSsE6B=bKhGwKG=dXtX7uEg@mail.gmail.com' \
--to=linus.walleij@linaro.org \
--cc=adrian.hunter@intel.com \
--cc=beanhuo@micron.com \
--cc=huobean@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mmc@vger.kernel.org \
--cc=stable@vger.kernel.org \
--cc=ulf.hansson@linaro.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.