On 21/11/19 4:21 AM, Y.b. Lu wrote:
> 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?
I don't think the auto-cmd12 error handling was ever done properly, so it
will take we a while to review it.
