On Fri, 21 Aug 2020 at 10:17, Wolfram Sang <wsa+renesas@xxxxxxxxxxxxxxxxxxxx> wrote: > > When a command response times out, the TMIO driver has been resetting > the controller ever since. However, this means some initialization like > bus width or tuning settings will be forgotten. To ensure proper working > in all code paths, we will enforce a reset of the remote device, too. > Many thanks to the Renesas BSP team for the detailed description of the > problem. > > Reported-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@xxxxxxxxxxx> > Signed-off-by: Wolfram Sang <wsa+renesas@xxxxxxxxxxxxxxxxxxxx> > --- > > This patch depends on the TMIO reset refactorization: > > [RFT 0/6] mmc: refactor reset callbacks > > Looking also for tests here. Thanks! > > drivers/mmc/host/tmio_mmc_core.c | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/drivers/mmc/host/tmio_mmc_core.c b/drivers/mmc/host/tmio_mmc_core.c > index ab910043808f..0d64308c619f 100644 > --- a/drivers/mmc/host/tmio_mmc_core.c > +++ b/drivers/mmc/host/tmio_mmc_core.c > @@ -220,6 +220,7 @@ static void tmio_mmc_reset_work(struct work_struct *work) > spin_unlock_irqrestore(&host->lock, flags); > > tmio_mmc_reset(host); > + mmc_hw_reset(host->mmc); This isn't how mmc_hw_reset() is intended to be used. Instead, the idea is that it should be called by upper layer code, when some error path is triggered for an I/O request. However, let me think a bit about this. > > /* Ready for new calls */ > host->mrq = NULL; > -- > 2.20.1 > Kind regards Uffe
