Entering the recovery system itself indicates a transmission error.
In this situation, we intend to execute the mmc_blk_reset function
to clear any anomalies that may be caused by errors. We have previously
discussed with several MMC device manufacturers, and they expressed
their desire for us to reset the device when errors occur to ensure
stable operation. We aim to make this code compatible with all devices
and ensure its stable performance, so we would like to add this patch
Signed-off-by: Michael Wu <[email protected]>
---
drivers/mmc/core/block.c | 2 +-
include/linux/mmc/host.h | 1 +
2 files changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/mmc/core/block.c b/drivers/mmc/core/block.c
index b5b414a71e0b..29fbe0ddeadb 100644
--- a/drivers/mmc/core/block.c
+++ b/drivers/mmc/core/block.c
@@ -1503,7 +1503,7 @@ void mmc_blk_cqe_recovery(struct mmc_queue *mq)
pr_debug("%s: CQE recovery start\n", mmc_hostname(host));
err = mmc_cqe_recovery(host);
- if (err)
+ if (err || host->cqe_recovery_reset_always)
mmc_blk_reset(mq->blkdata, host, MMC_BLK_CQE_RECOVERY);
mmc_blk_reset_success(mq->blkdata, MMC_BLK_CQE_RECOVERY);
diff --git a/include/linux/mmc/host.h b/include/linux/mmc/host.h
index 62a6847a3b6f..f578541a06b5 100644
--- a/include/linux/mmc/host.h
+++ b/include/linux/mmc/host.h
@@ -518,6 +518,7 @@ struct mmc_host {
int cqe_qdepth;
bool cqe_enabled;
bool cqe_on;
+ bool cqe_recovery_reset_always;
/* Inline encryption support */
#ifdef CONFIG_MMC_CRYPTO
--
2.29.0
On Thu, 14 Sept 2023 at 08:04, Michael Wu <[email protected]> wrote:
>
> Entering the recovery system itself indicates a transmission error.
> In this situation, we intend to execute the mmc_blk_reset function
> to clear any anomalies that may be caused by errors. We have previously
> discussed with several MMC device manufacturers, and they expressed
> their desire for us to reset the device when errors occur to ensure
> stable operation. We aim to make this code compatible with all devices
> and ensure its stable performance, so we would like to add this patch
>
> Signed-off-by: Michael Wu <[email protected]>
like: https://lore.kernel.org/linux-mmc/[email protected]/
You should enable it in the vendor host.
> ---
> drivers/mmc/core/block.c | 2 +-
> include/linux/mmc/host.h | 1 +
> 2 files changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/mmc/core/block.c b/drivers/mmc/core/block.c
> index b5b414a71e0b..29fbe0ddeadb 100644
> --- a/drivers/mmc/core/block.c
> +++ b/drivers/mmc/core/block.c
> @@ -1503,7 +1503,7 @@ void mmc_blk_cqe_recovery(struct mmc_queue *mq)
> pr_debug("%s: CQE recovery start\n", mmc_hostname(host));
>
> err = mmc_cqe_recovery(host);
> - if (err)
> + if (err || host->cqe_recovery_reset_always)
> mmc_blk_reset(mq->blkdata, host, MMC_BLK_CQE_RECOVERY);
> mmc_blk_reset_success(mq->blkdata, MMC_BLK_CQE_RECOVERY);
>
> diff --git a/include/linux/mmc/host.h b/include/linux/mmc/host.h
> index 62a6847a3b6f..f578541a06b5 100644
> --- a/include/linux/mmc/host.h
> +++ b/include/linux/mmc/host.h
> @@ -518,6 +518,7 @@ struct mmc_host {
> int cqe_qdepth;
> bool cqe_enabled;
> bool cqe_on;
> + bool cqe_recovery_reset_always;
>
> /* Inline encryption support */
> #ifdef CONFIG_MMC_CRYPTO
> --
> 2.29.0
>
- trimmed cc-list, + Sartak Garg
On Thu, 14 Sept 2023 at 10:00, Wenchao Chen <[email protected]> wrote:
>
> On Thu, 14 Sept 2023 at 08:04, Michael Wu <[email protected]> wrote:
> >
> > Entering the recovery system itself indicates a transmission error.
> > In this situation, we intend to execute the mmc_blk_reset function
> > to clear any anomalies that may be caused by errors. We have previously
> > discussed with several MMC device manufacturers, and they expressed
> > their desire for us to reset the device when errors occur to ensure
> > stable operation. We aim to make this code compatible with all devices
> > and ensure its stable performance, so we would like to add this patch
> >
> > Signed-off-by: Michael Wu <[email protected]>
>
> like: https://lore.kernel.org/linux-mmc/[email protected]/
Looks like this series didn't make it. I was awaiting a rebase from
Sartak to apply it, but apparently something got in his way for a new
submission.
>
> You should enable it in the vendor host.
Yes! We don't want unused code in the core. We need a user of it too.
May I suggest that you pick up Sartak's patch for the core and thus
add another patch for the host driver you care about and then
re-submit it as a small series.
Kind regards
Uffe
>
> > ---
> > drivers/mmc/core/block.c | 2 +-
> > include/linux/mmc/host.h | 1 +
> > 2 files changed, 2 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/mmc/core/block.c b/drivers/mmc/core/block.c
> > index b5b414a71e0b..29fbe0ddeadb 100644
> > --- a/drivers/mmc/core/block.c
> > +++ b/drivers/mmc/core/block.c
> > @@ -1503,7 +1503,7 @@ void mmc_blk_cqe_recovery(struct mmc_queue *mq)
> > pr_debug("%s: CQE recovery start\n", mmc_hostname(host));
> >
> > err = mmc_cqe_recovery(host);
> > - if (err)
> > + if (err || host->cqe_recovery_reset_always)
> > mmc_blk_reset(mq->blkdata, host, MMC_BLK_CQE_RECOVERY);
> > mmc_blk_reset_success(mq->blkdata, MMC_BLK_CQE_RECOVERY);
> >
> > diff --git a/include/linux/mmc/host.h b/include/linux/mmc/host.h
> > index 62a6847a3b6f..f578541a06b5 100644
> > --- a/include/linux/mmc/host.h
> > +++ b/include/linux/mmc/host.h
> > @@ -518,6 +518,7 @@ struct mmc_host {
> > int cqe_qdepth;
> > bool cqe_enabled;
> > bool cqe_on;
> > + bool cqe_recovery_reset_always;
> >
> > /* Inline encryption support */
> > #ifdef CONFIG_MMC_CRYPTO
> > --
> > 2.29.0
> >
On 9/25/2023 9:59 PM, Ulf Hansson wrote:
> - trimmed cc-list, + Sartak Garg
>
> On Thu, 14 Sept 2023 at 10:00, Wenchao Chen <[email protected]> wrote:
>>
>> On Thu, 14 Sept 2023 at 08:04, Michael Wu <[email protected]> wrote:
>>>
>>> Entering the recovery system itself indicates a transmission error.
>>> In this situation, we intend to execute the mmc_blk_reset function
>>> to clear any anomalies that may be caused by errors. We have previously
>>> discussed with several MMC device manufacturers, and they expressed
>>> their desire for us to reset the device when errors occur to ensure
>>> stable operation. We aim to make this code compatible with all devices
>>> and ensure its stable performance, so we would like to add this patch
>>>
>>> Signed-off-by: Michael Wu <[email protected]>
>>
>> like: https://lore.kernel.org/linux-mmc/[email protected]/
>
> Looks like this series didn't make it. I was awaiting a rebase from
> Sartak to apply it, but apparently something got in his way for a new
> submission.
>
>>
>> You should enable it in the vendor host.
>
> Yes! We don't want unused code in the core. We need a user of it too.
>
> May I suggest that you pick up Sartak's patch for the core and thus
> add another patch for the host driver you care about and then
> re-submit it as a small series.
>
> Kind regards
> Uffe
>
>>
>>> ---
>>> drivers/mmc/core/block.c | 2 +-
>>> include/linux/mmc/host.h | 1 +
>>> 2 files changed, 2 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/drivers/mmc/core/block.c b/drivers/mmc/core/block.c
>>> index b5b414a71e0b..29fbe0ddeadb 100644
>>> --- a/drivers/mmc/core/block.c
>>> +++ b/drivers/mmc/core/block.c
>>> @@ -1503,7 +1503,7 @@ void mmc_blk_cqe_recovery(struct mmc_queue *mq)
>>> pr_debug("%s: CQE recovery start\n", mmc_hostname(host));
>>>
>>> err = mmc_cqe_recovery(host);
>>> - if (err)
>>> + if (err || host->cqe_recovery_reset_always)
>>> mmc_blk_reset(mq->blkdata, host, MMC_BLK_CQE_RECOVERY);
>>> mmc_blk_reset_success(mq->blkdata, MMC_BLK_CQE_RECOVERY);
>>>
>>> diff --git a/include/linux/mmc/host.h b/include/linux/mmc/host.h
>>> index 62a6847a3b6f..f578541a06b5 100644
>>> --- a/include/linux/mmc/host.h
>>> +++ b/include/linux/mmc/host.h
>>> @@ -518,6 +518,7 @@ struct mmc_host {
>>> int cqe_qdepth;
>>> bool cqe_enabled;
>>> bool cqe_on;
>>> + bool cqe_recovery_reset_always;
>>>
>>> /* Inline encryption support */
>>> #ifdef CONFIG_MMC_CRYPTO
>>> --
>>> 2.29.0
>>>
Dear Ulf,
I have tested Sartak's patch and it is also able to resolve the issue we
are currently facing. Therefore, I would like to inquire about the
expected timeline for merging Sartak's patch.
--
Regards,
Michael Wu
On Mon, 6 Nov 2023 at 13:26, Michael Wu <[email protected]> wrote:
>
> On 9/25/2023 9:59 PM, Ulf Hansson wrote:
> > - trimmed cc-list, + Sartak Garg
> >
> > On Thu, 14 Sept 2023 at 10:00, Wenchao Chen <[email protected]> wrote:
> >>
> >> On Thu, 14 Sept 2023 at 08:04, Michael Wu <[email protected]> wrote:
> >>>
> >>> Entering the recovery system itself indicates a transmission error.
> >>> In this situation, we intend to execute the mmc_blk_reset function
> >>> to clear any anomalies that may be caused by errors. We have previously
> >>> discussed with several MMC device manufacturers, and they expressed
> >>> their desire for us to reset the device when errors occur to ensure
> >>> stable operation. We aim to make this code compatible with all devices
> >>> and ensure its stable performance, so we would like to add this patch
> >>>
> >>> Signed-off-by: Michael Wu <[email protected]>
> >>
> >> like: https://lore.kernel.org/linux-mmc/[email protected]/
> >
> > Looks like this series didn't make it. I was awaiting a rebase from
> > Sartak to apply it, but apparently something got in his way for a new
> > submission.
> >
> >>
> >> You should enable it in the vendor host.
> >
> > Yes! We don't want unused code in the core. We need a user of it too.
> >
> > May I suggest that you pick up Sartak's patch for the core and thus
> > add another patch for the host driver you care about and then
> > re-submit it as a small series.
> >
> > Kind regards
> > Uffe
> >
> >>
> >>> ---
> >>> drivers/mmc/core/block.c | 2 +-
> >>> include/linux/mmc/host.h | 1 +
> >>> 2 files changed, 2 insertions(+), 1 deletion(-)
> >>>
> >>> diff --git a/drivers/mmc/core/block.c b/drivers/mmc/core/block.c
> >>> index b5b414a71e0b..29fbe0ddeadb 100644
> >>> --- a/drivers/mmc/core/block.c
> >>> +++ b/drivers/mmc/core/block.c
> >>> @@ -1503,7 +1503,7 @@ void mmc_blk_cqe_recovery(struct mmc_queue *mq)
> >>> pr_debug("%s: CQE recovery start\n", mmc_hostname(host));
> >>>
> >>> err = mmc_cqe_recovery(host);
> >>> - if (err)
> >>> + if (err || host->cqe_recovery_reset_always)
> >>> mmc_blk_reset(mq->blkdata, host, MMC_BLK_CQE_RECOVERY);
> >>> mmc_blk_reset_success(mq->blkdata, MMC_BLK_CQE_RECOVERY);
> >>>
> >>> diff --git a/include/linux/mmc/host.h b/include/linux/mmc/host.h
> >>> index 62a6847a3b6f..f578541a06b5 100644
> >>> --- a/include/linux/mmc/host.h
> >>> +++ b/include/linux/mmc/host.h
> >>> @@ -518,6 +518,7 @@ struct mmc_host {
> >>> int cqe_qdepth;
> >>> bool cqe_enabled;
> >>> bool cqe_on;
> >>> + bool cqe_recovery_reset_always;
> >>>
> >>> /* Inline encryption support */
> >>> #ifdef CONFIG_MMC_CRYPTO
> >>> --
> >>> 2.29.0
> >>>
> Dear Ulf,
> I have tested Sartak's patch and it is also able to resolve the issue we
> are currently facing. Therefore, I would like to inquire about the
> expected timeline for merging Sartak's patch.
Hi Michael,
There is another series [1] that Adrian is working on that is related
to the problem in $subject patch. Perhaps you can take a look and try
it out instead of Sartak's patch, which seems to have gotten stalled.
Kind regards
Uffe
[1]
https://lore.kernel.org/all/[email protected]/
On Mon, 6 Nov 2023 at 22:20, Ulf Hansson <[email protected]> wrote:
>
> On Mon, 6 Nov 2023 at 13:26, Michael Wu <[email protected]> wrote:
> >
> > On 9/25/2023 9:59 PM, Ulf Hansson wrote:
> > > - trimmed cc-list, + Sartak Garg
> > >
> > > On Thu, 14 Sept 2023 at 10:00, Wenchao Chen <[email protected]> wrote:
> > >>
> > >> On Thu, 14 Sept 2023 at 08:04, Michael Wu <[email protected]> wrote:
> > >>>
> > >>> Entering the recovery system itself indicates a transmission error.
> > >>> In this situation, we intend to execute the mmc_blk_reset function
> > >>> to clear any anomalies that may be caused by errors. We have previously
> > >>> discussed with several MMC device manufacturers, and they expressed
> > >>> their desire for us to reset the device when errors occur to ensure
> > >>> stable operation. We aim to make this code compatible with all devices
> > >>> and ensure its stable performance, so we would like to add this patch
> > >>>
> > >>> Signed-off-by: Michael Wu <[email protected]>
> > >>
> > >> like: https://lore.kernel.org/linux-mmc/[email protected]/
> > >
> > > Looks like this series didn't make it. I was awaiting a rebase from
> > > Sartak to apply it, but apparently something got in his way for a new
> > > submission.
> > >
> > >>
> > >> You should enable it in the vendor host.
> > >
> > > Yes! We don't want unused code in the core. We need a user of it too.
> > >
> > > May I suggest that you pick up Sartak's patch for the core and thus
> > > add another patch for the host driver you care about and then
> > > re-submit it as a small series.
> > >
> > > Kind regards
> > > Uffe
> > >
> > >>
> > >>> ---
> > >>> drivers/mmc/core/block.c | 2 +-
> > >>> include/linux/mmc/host.h | 1 +
> > >>> 2 files changed, 2 insertions(+), 1 deletion(-)
> > >>>
> > >>> diff --git a/drivers/mmc/core/block.c b/drivers/mmc/core/block.c
> > >>> index b5b414a71e0b..29fbe0ddeadb 100644
> > >>> --- a/drivers/mmc/core/block.c
> > >>> +++ b/drivers/mmc/core/block.c
> > >>> @@ -1503,7 +1503,7 @@ void mmc_blk_cqe_recovery(struct mmc_queue *mq)
> > >>> pr_debug("%s: CQE recovery start\n", mmc_hostname(host));
> > >>>
> > >>> err = mmc_cqe_recovery(host);
> > >>> - if (err)
> > >>> + if (err || host->cqe_recovery_reset_always)
> > >>> mmc_blk_reset(mq->blkdata, host, MMC_BLK_CQE_RECOVERY);
> > >>> mmc_blk_reset_success(mq->blkdata, MMC_BLK_CQE_RECOVERY);
> > >>>
> > >>> diff --git a/include/linux/mmc/host.h b/include/linux/mmc/host.h
> > >>> index 62a6847a3b6f..f578541a06b5 100644
> > >>> --- a/include/linux/mmc/host.h
> > >>> +++ b/include/linux/mmc/host.h
> > >>> @@ -518,6 +518,7 @@ struct mmc_host {
> > >>> int cqe_qdepth;
> > >>> bool cqe_enabled;
> > >>> bool cqe_on;
> > >>> + bool cqe_recovery_reset_always;
> > >>>
> > >>> /* Inline encryption support */
> > >>> #ifdef CONFIG_MMC_CRYPTO
> > >>> --
> > >>> 2.29.0
> > >>>
> > Dear Ulf,
> > I have tested Sartak's patch and it is also able to resolve the issue we
> > are currently facing. Therefore, I would like to inquire about the
> > expected timeline for merging Sartak's patch.
>
Hi Sartak
Any updates?
> Hi Michael,
>
> There is another series [1] that Adrian is working on that is related
> to the problem in $subject patch. Perhaps you can take a look and try
> it out instead of Sartak's patch, which seems to have gotten stalled.
>
> Kind regards
> Uffe
>
> [1]
> https://lore.kernel.org/all/[email protected]/