[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAPDyKFr6bfcG+_3f+8ZYFFsuTA9reJ4Ykntxt=yh16-Z_6vxAg@mail.gmail.com>
Date: Fri, 18 Jun 2021 12:47:24 +0200
From: Ulf Hansson <ulf.hansson@...aro.org>
To: Christian Löhle <CLoehle@...erstone.com>
Cc: Avri Altman <Avri.Altman@....com>,
"linux-mmc@...r.kernel.org" <linux-mmc@...r.kernel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
Adrian Hunter <adrian.hunter@...el.com>,
"shawn.lin@...k-chips.com" <shawn.lin@...k-chips.com>
Subject: Re: [PATCH] mmc: block: ioctl: Poll for TRAN if possible
On Fri, 18 Jun 2021 at 12:00, Christian Löhle <CLoehle@...erstone.com> wrote:
>
> >Poll for TRAN state if the ioctl command will eventually return to TRAN
> >
> >The ioctl submitted command should not be considered completed until
> >the card has returned back to TRAN state. Waiting just for the card
> >to no longer signal busy is not enough as they might remain in a
> >non-busy PROG state for a while after the command.
> >Further commands requiring TRAN will fail then.
> >It should not be the responsibility of the user to check if their command
> >has completed until sending the next via ioctl,
> >instead the check should be made here.
> >So now, in doubt, wait for TRAN except for the few commands that will
> >never return to TRAN state.
>
> So apart from the fact that I missed a couple of non-TRAN returning MMC
> commands, which I will add in v2, are there any other thoughts about this
> patch? It would change the behavior of the ioctl interface, but I think it is
> the only way to prevent race conditions here.
I need some more time to review, but feel free to post a v2, I can
look at that instead.
Kind regards
Uffe
>
> Best Regards,
> Christian
>
> Hyperstone GmbH | Line-Eid-Strasse 3 | 78467 Konstanz
> Managing Directors: Dr. Jan Peter Berns.
> Commercial register of local courts: Freiburg HRB381782
>
Powered by blists - more mailing lists