On Tue, 12 Jan 2021 at 15:18, Fengnan Chang <fengnanchang@xxxxxxxxx> wrote:
>
> when analyse tuples failed, may enter an endless loop，so limit the number of retries.
>
> Signed-off-by: Fengnan Chang <fengnanchang@xxxxxxxxx>
> ---
> drivers/mmc/core/sdio_cis.c | 4 ++++
> 1 file changed, 4 insertions(+)
>
> diff --git a/drivers/mmc/core/sdio_cis.c b/drivers/mmc/core/sdio_cis.c
> index dcb3dee59fa5..a3f0c3cc0c2c 100644
> --- a/drivers/mmc/core/sdio_cis.c
> +++ b/drivers/mmc/core/sdio_cis.c
> @@ -266,6 +266,7 @@ static int sdio_read_cis(struct mmc_card *card, struct sdio_func *func)
>
> do {
> unsigned char tpl_code, tpl_link;
> + int tries = 100;
>
>From a general point of view I agree, we should set a limit to avoid
looping forever. Although, I am wondering why exactly is 100 a good
value for retries?
Did you encounter this problem and tried to limit the loop to 100 to
fix the problem - or is the fix done based on pure code analysis?
An option to limit the loop with retries is to bail out when a timer
elapses. Perhaps that is better suited for this case or what do you
think?
> ret = mmc_io_rw_direct(card, 0, 0, ptr++, 0, &tpl_code);
> if (ret)
> @@ -318,6 +319,9 @@ static int sdio_read_cis(struct mmc_card *card, struct sdio_func *func)
> prev = &this->next;
>
> if (ret == -ENOENT) {
> + tries--;
> + if (!tries)
> + break;
> /* warn about unknown tuples */
> pr_warn_ratelimited("%s: queuing unknown"
> " CIS tuple 0x%02x (%u bytes)\n",
> --
> 2.25.1
>
Kind regards
Uffe
