On 25 May 2018 at 10:59, Shawn Lin <shawn.lin@xxxxxxxxxxxxxx> wrote: > On 2018/5/25 16:42, Ulf Hansson wrote: >> >> On 25 May 2018 at 08:17, Shawn Lin <shawn.lin@xxxxxxxxxxxxxx> wrote: >>> >>> In preparation for reusing mmc_poll_for_busy() to avoid duplication >>> of code for polling busy. >>> >>> No functional change intended. >>> >>> Signed-off-by: Shawn Lin <shawn.lin@xxxxxxxxxxxxxx> >>> --- >>> >>> drivers/mmc/core/mmc_ops.c | 7 ++++--- >>> 1 file changed, 4 insertions(+), 3 deletions(-) >>> >>> diff --git a/drivers/mmc/core/mmc_ops.c b/drivers/mmc/core/mmc_ops.c >>> index 88f34fd..4d73db4 100644 >>> --- a/drivers/mmc/core/mmc_ops.c >>> +++ b/drivers/mmc/core/mmc_ops.c >>> @@ -447,7 +447,8 @@ int mmc_switch_status(struct mmc_card *card) >>> } >>> >>> static int mmc_poll_for_busy(struct mmc_card *card, unsigned int >>> timeout_ms, >>> - bool send_status, bool retry_crc_err, bool >>> use_r1b_resp) >>> + bool send_status, bool retry_crc_err, bool >>> use_r1b_resp, >>> + unsigned int retries) >> >> >> What are the use-case for actually being able to use different amount >> of retries for polling? > > > ioctl_rpmb_card_status_poll() retry 5 times but mmc_do_erase() wants > zero. The comment seems to imply it wants the first send_status get back > the device status related to the last command prior to it. I am guessing you refer to "Do not retry else we can't see errors". Actually, the same thing applies to switch commands. Only the first CMD13 will give the switch status, anyway we are trying 5 times... My point is, I think we shall use the kind of policy, unless there are good reasons not to. [...] Kind regards Uffe -- To unsubscribe from this list: send the line "unsubscribe linux-mmc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
