[PATCH v1] mmc: sdhci: Handle auto-command errors

[PATCH v1] mmc: sdhci: Handle auto-command errors

[Kaiyen Chang]

    Existing data command CRC error handling on kernel 4.20 stable branch
    is non-standard and does not work with some Intel host controllers.
    Specifically, the assumption that the host controller will continue
    operating normally after the error interrupt, is not valid. So we
    suggest cherry-pick the 3 patches listed below to kernel 4.20 stable
    branch, which can change the driver to handle the error in the same
    manner as a data CRC error.

    4bf7809: mmc: sdhci: Fix data command CRC error handling
    869f8a6: mmc: sdhci: Rename SDHCI_ACMD12_ERR and SDHCI_INT_ACMD12ERR
    af849c8: mmc: sdhci: Handle auto-command errors

    All of the patches above have landed on kernel 5.0 stable branch.

Re: [PATCH v1] mmc: sdhci: Handle auto-command errors

[Greg KH]

On Tue, Apr 23, 2019 at 04:50:58PM +0800, Kaiyen Chang wrote:
>     Existing data command CRC error handling on kernel 4.20 stable branch
>     is non-standard and does not work with some Intel host controllers.
>     Specifically, the assumption that the host controller will continue
>     operating normally after the error interrupt, is not valid. So we
>     suggest cherry-pick the 3 patches listed below to kernel 4.20 stable
>     branch, which can change the driver to handle the error in the same
>     manner as a data CRC error.
> 
>     4bf7809: mmc: sdhci: Fix data command CRC error handling
>     869f8a6: mmc: sdhci: Rename SDHCI_ACMD12_ERR and SDHCI_INT_ACMD12ERR
>     af849c8: mmc: sdhci: Handle auto-command errors
> 
>     All of the patches above have landed on kernel 5.0 stable branch.

The 4.20.y stable branch is long end-of-life, so there is nothing to be
able to apply any patch to, sorry.

Remember to always check the front page of kernel.org for what trees are
still active.

greg k-h

RE: [PATCH v1] mmc: sdhci: Handle auto-command errors

[Chang, Kaiyen]

Hi Greg,

Actually our goal is to merge the 3 patches to 4.19.y and 4.14.y stable branch, however, I mistakenly believed that the patches should be present in 4.20.y first and did not notice that 4.20.y has been EOL. Sorry for that.

Thanks,
Kaiyen

-----Original Message-----
From: Greg KH [mailto:gregkh@linuxfoundation.org] 
Sent: Tuesday, April 23, 2019 8:34 PM
To: Chang, Kaiyen <kaiyen.chang@intel.com>
Cc: stable@vger.kernel.org; Hunter, Adrian <adrian.hunter@intel.com>; ulf.hansson@linaro.org
Subject: Re: [PATCH v1] mmc: sdhci: Handle auto-command errors

On Tue, Apr 23, 2019 at 04:50:58PM +0800, Kaiyen Chang wrote:
>     Existing data command CRC error handling on kernel 4.20 stable branch
>     is non-standard and does not work with some Intel host controllers.
>     Specifically, the assumption that the host controller will continue
>     operating normally after the error interrupt, is not valid. So we
>     suggest cherry-pick the 3 patches listed below to kernel 4.20 stable
>     branch, which can change the driver to handle the error in the same
>     manner as a data CRC error.
> 
>     4bf7809: mmc: sdhci: Fix data command CRC error handling
>     869f8a6: mmc: sdhci: Rename SDHCI_ACMD12_ERR and SDHCI_INT_ACMD12ERR
>     af849c8: mmc: sdhci: Handle auto-command errors
> 
>     All of the patches above have landed on kernel 5.0 stable branch.

The 4.20.y stable branch is long end-of-life, so there is nothing to be able to apply any patch to, sorry.

Remember to always check the front page of kernel.org for what trees are still active.

greg k-h

Re: [PATCH v1] mmc: sdhci: Handle auto-command errors

[Sasha Levin]

On Tue, Apr 23, 2019 at 04:50:58PM +0800, Kaiyen Chang wrote:
>    Existing data command CRC error handling on kernel 4.20 stable branch
>    is non-standard and does not work with some Intel host controllers.
>    Specifically, the assumption that the host controller will continue
>    operating normally after the error interrupt, is not valid. So we
>    suggest cherry-pick the 3 patches listed below to kernel 4.20 stable
>    branch, which can change the driver to handle the error in the same
>    manner as a data CRC error.
>
>    4bf7809: mmc: sdhci: Fix data command CRC error handling
>    869f8a6: mmc: sdhci: Rename SDHCI_ACMD12_ERR and SDHCI_INT_ACMD12ERR
>    af849c8: mmc: sdhci: Handle auto-command errors
>
>    All of the patches above have landed on kernel 5.0 stable branch.

4.20 went EoL quite a while ago, you should be using 5.0 at this point.

I've queued these to older stable kernels, thanks.

--
Thanks,
Sasha

RE: [PATCH v1] mmc: sdhci: Handle auto-command errors

[Chang, Kaiyen]

> -----Original Message-----
> From: Sasha Levin [mailto:sashal@kernel.org]
> Sent: Tuesday, April 23, 2019 9:43 PM
> To: Chang, Kaiyen <kaiyen.chang@intel.com>
> Cc: stable@vger.kernel.org; Hunter, Adrian <adrian.hunter@intel.com>;
> ulf.hansson@linaro.org
> Subject: Re: [PATCH v1] mmc: sdhci: Handle auto-command errors
> 
> On Tue, Apr 23, 2019 at 04:50:58PM +0800, Kaiyen Chang wrote:
> >    Existing data command CRC error handling on kernel 4.20 stable branch
> >    is non-standard and does not work with some Intel host controllers.
> >    Specifically, the assumption that the host controller will continue
> >    operating normally after the error interrupt, is not valid. So we
> >    suggest cherry-pick the 3 patches listed below to kernel 4.20 stable
> >    branch, which can change the driver to handle the error in the same
> >    manner as a data CRC error.
> >
> >    4bf7809: mmc: sdhci: Fix data command CRC error handling
> >    869f8a6: mmc: sdhci: Rename SDHCI_ACMD12_ERR and
> SDHCI_INT_ACMD12ERR
> >    af849c8: mmc: sdhci: Handle auto-command errors
> >
> >    All of the patches above have landed on kernel 5.0 stable branch.
> 
> 4.20 went EoL quite a while ago, you should be using 5.0 at this point.
> 
> I've queued these to older stable kernels, thanks.
> 
> --
> Thanks,
> Sasha

Hi Sasha,

Actually our goal is to merge the 3 patches to 4.19.y and 4.14.y stable branch, however, I mistakenly believed that the patches should be present in 4.20.y first and did not notice that 4.20.y has been EOL. Sorry for that. Should I create another thread to issue the request for merging the 3 patches to 4.19.y and 4.14.y?

Thanks,
Kaiyen

Re: [PATCH v1] mmc: sdhci: Handle auto-command errors

[Sasha Levin]

On Wed, Apr 24, 2019 at 02:55:31AM +0000, Chang, Kaiyen wrote:
>> -----Original Message-----
>> From: Sasha Levin [mailto:sashal@kernel.org]
>> Sent: Tuesday, April 23, 2019 9:43 PM
>> To: Chang, Kaiyen <kaiyen.chang@intel.com>
>> Cc: stable@vger.kernel.org; Hunter, Adrian <adrian.hunter@intel.com>;
>> ulf.hansson@linaro.org
>> Subject: Re: [PATCH v1] mmc: sdhci: Handle auto-command errors
>>
>> On Tue, Apr 23, 2019 at 04:50:58PM +0800, Kaiyen Chang wrote:
>> >    Existing data command CRC error handling on kernel 4.20 stable branch
>> >    is non-standard and does not work with some Intel host controllers.
>> >    Specifically, the assumption that the host controller will continue
>> >    operating normally after the error interrupt, is not valid. So we
>> >    suggest cherry-pick the 3 patches listed below to kernel 4.20 stable
>> >    branch, which can change the driver to handle the error in the same
>> >    manner as a data CRC error.
>> >
>> >    4bf7809: mmc: sdhci: Fix data command CRC error handling
>> >    869f8a6: mmc: sdhci: Rename SDHCI_ACMD12_ERR and
>> SDHCI_INT_ACMD12ERR
>> >    af849c8: mmc: sdhci: Handle auto-command errors
>> >
>> >    All of the patches above have landed on kernel 5.0 stable branch.
>>
>> 4.20 went EoL quite a while ago, you should be using 5.0 at this point.
>>
>> I've queued these to older stable kernels, thanks.
>>
>> --
>> Thanks,
>> Sasha
>
>Hi Sasha,
>
>Actually our goal is to merge the 3 patches to 4.19.y and 4.14.y stable branch, however, I mistakenly believed that the patches should be present in 4.20.y first and did not notice that 4.20.y has been EOL. Sorry for that. Should I create another thread to issue the request for merging the 3 patches to 4.19.y and 4.14.y?

I've already queued it for 4.19 and 4.14, nothing else to do here.

--
Thanks,
Sasha