[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <DM6PR04MB657545C0B7FC82F68CB87D5AFC789@DM6PR04MB6575.namprd04.prod.outlook.com>
Date: Mon, 15 May 2023 15:02:58 +0000
From: Avri Altman <Avri.Altman@....com>
To: Ulf Hansson <ulf.hansson@...aro.org>,
Christian Löhle <CLoehle@...erstone.com>
CC: Adrian Hunter <adrian.hunter@...el.com>,
"linux-mmc@...r.kernel.org" <linux-mmc@...r.kernel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: RE: [PATCH 3/3] mmc: block: ioctl: Add error aggregation flag
> > + */
> > + else if (idata->ic.write_flag & MMC_AGGREGATE_PROG_ERRORS) {
> > + unsigned long timeout = jiffies +
> > + msecs_to_jiffies(busy_timeout_ms);
> > + bool done = false;
> > + unsigned long delay_ms = 1;
> > + u32 status;
> > +
> > + do {
> > + done = time_after(jiffies, timeout);
> > + msleep(delay_ms++);
> > + err = __mmc_send_status(card, &status, 1);
> > + if (err)
> > + return err;
> > + idata->ic.response[1] |= status;
> > + } while (R1_CURRENT_STATE(status) != R1_STATE_TRAN &&
> !done);
> > + if (done)
> > + return -ETIMEDOUT;
> > + }
>
> We have moved away from open-coding polling loops. Let's not introduce a
> new one. In fact, it looks a bit like we could re-use the
> mmc_blk_busy_cb() for this, as it seems to be collecting the error codes too.
>
> In any case, let's at least make use of __mmc_poll_for_busy() to avoid the
> open-coding.
Or maybe use read_poll_timeout()?
Thanks,
Avri
Powered by blists - more mailing lists