[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <CAPDyKFpEuMnfrwCZ74P_zW-Bh3ZB3175aDbVAY1nL=SxWSud-w@mail.gmail.com>
Date: Fri, 27 Jan 2023 11:57:00 +0100
From: Ulf Hansson <ulf.hansson@...aro.org>
To: Ludovic.Desroches@...rochip.com, t.schramm@...jaro.org
Cc: Nicolas.Ferre@...rochip.com, alexandre.belloni@...tlin.com,
Claudiu.Beznea@...rochip.com, linux-mmc@...r.kernel.org,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH 1/1] mmc: atmel-mci: fix race between stop command and
start of next command
On Thu, 26 Jan 2023 at 15:44, <Ludovic.Desroches@...rochip.com> wrote:
>
> On 30/12/2022 20:43, Tobias Schramm wrote:
> > EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe
> >
> > This commit fixes a race between completion of stop command and start of a
> > new command.
> > Previously the command ready interrupt was enabled before stop command
> > was written to the command register. This caused the command ready
> > interrupt to fire immediately since the CMDRDY flag is asserted constantly
> > while there is no command in progress.
> > Consequently the command state machine will immediately advance to the
> > next state when the tasklet function is executed again, no matter
> > actual completion state of the stop command.
> > Thus a new command can then be dispatched immediately, interrupting and
> > corrupting the stop command on the CMD line.
> > Fix that by dropping the command ready interrupt enable before calling
> > atmci_send_stop_cmd. atmci_send_stop_cmd does already enable the
> > command ready interrupt, no further writes to ATMCI_IER are necessary.
> >
> > Signed-off-by: Tobias Schramm <t.schramm@...jaro.org>
>
> Hi,
>
> In theory this changes make sense. I'm always afraid when something is
> changed in this driver which handles many version of the IP...
>
> As we never encountered this issue until now, I can't really test this
> fix. I checked on an old board at91sam9m10g45-ek that mmc is still
> working and it's okay.
>
> So
> Acked-by: Ludovic Desroches <ludovic.desroches@...rochip.com>
>
> Regards,
> Ludovic
Thanks for your ack and thoughts!
It's not clear to me whether the problem is hypothetical or in fact a
real problem. Tobias can you help to fill in here?
Nevertheless I have applied this for next, to allow more testing to be
done. In the meantime, we can discuss whether we should add a stable
tag or leave that to later as manual backports.
[...]
Kind regards
Uffe
Powered by blists - more mailing lists