Hi,
> -----Original Message-----
> From: Ulf Hansson <ulf.hansson@xxxxxxxxxx>
> Sent: Thursday, November 14, 2019 9:54 PM
> To: Y.b. Lu <yangbo.lu@xxxxxxx>
> Cc: linux-mmc@xxxxxxxxxxxxxxx; Adrian Hunter <adrian.hunter@xxxxxxxxx>
> Subject: Re: [PATCH] mmc: sdhci: fix up CMD12 sending
>
> On Thu, 14 Nov 2019 at 12:18, Yangbo Lu <yangbo.lu@xxxxxxx> wrote:
> >
> > The STOP command is disabled for multiple blocks r/w commands with
> > auto CMD12, when start to send. However, if there is data error,
> > software still needs to send CMD12 according to SD spec.
> > This patch is to allow software CMD12 sending for this case.
> >
> > Signed-off-by: Yangbo Lu <yangbo.lu@xxxxxxx>
> > ---
> > drivers/mmc/host/sdhci.c | 17 +++--------------
> > 1 file changed, 3 insertions(+), 14 deletions(-)
> >
> > diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c index
> > 09cdbe8..3041c39 100644
> > --- a/drivers/mmc/host/sdhci.c
> > +++ b/drivers/mmc/host/sdhci.c
> > @@ -1326,12 +1326,12 @@ static void sdhci_finish_data(struct
> > sdhci_host *host)
> >
> > /*
> > * Need to send CMD12 if -
> > - * a) open-ended multiblock transfer (no CMD23)
> > + * a) open-ended multiblock transfer not using auto CMD12 (no
> > + CMD23)
> > * b) error in multiblock transfer
> > */
> > if (data->stop &&
> > - (data->error ||
> > - !data->mrq->sbc)) {
> > + ((!data->mrq->sbc && !sdhci_auto_cmd12(host, data->mrq)) ||
> > + data->error)) {
>
> Per your other reply to this thread, I don't think there is any harm in always
> sending a CMD12 if there is an error, at least from the card's point of view.
>
> The worst thing that can happen is that there are two CMD12 sent to the card
> and I don't think that is a problem for the error path.
>
> My only concern, is to understand if $subject patch causes other changes in
> behaviours for the SDHCI driver. Let's see what Adrian thinks.
[Y.b. Lu] Yes. The purpose is to avoid no CMD12 sent if get data error. That will makes block driver failed at block r/w recovery when sending CMD13 to get status.
Our platform on some boards at old kernel 4.14 seems to hit this case.
Hi Adrian,
Could you help to review the changes?
Thanks.
>
> > /*
> > * 'cap_cmd_during_tfr' request must not use the
> command line
> > * after mmc_command_done() has been called. It is
> > upper layer's @@ -1825,17 +1825,6 @@ void sdhci_request(struct
> > mmc_host *mmc, struct mmc_request *mrq)
> >
> > sdhci_led_activate(host);
> >
> > - /*
> > - * Ensure we don't send the STOP for non-SET_BLOCK_COUNTED
> > - * requests if Auto-CMD12 is enabled.
> > - */
> > - if (sdhci_auto_cmd12(host, mrq)) {
> > - if (mrq->stop) {
> > - mrq->data->stop = NULL;
> > - mrq->stop = NULL;
> > - }
> > - }
>
> In general, I am not very fond of when host drivers change these structures
> under the hood of the core, which means I like this part.
>
> > -
> > if (!present || host->flags & SDHCI_DEVICE_DEAD) {
> > mrq->cmd->error = -ENOMEDIUM;
> > sdhci_finish_mrq(host, mrq);
> > --
> > 2.7.4
> >
>
> Kind regards
> Uffe
