[PATCH v3 1/1] scsi: ufs: core: Flush exception handling work when RPM level is zero

[PATCH v3 1/1] scsi: ufs: core: Flush exception handling work when RPM level is zero

[Thomas Yen]

Ensure that the exception event handling work is explicitly flushed
during suspend when the runtime power management level is set to
UFS_PM_LVL_0.

When the RPM level is zero, the device power mode and link state both
remain active. Previously, the UFS core driver bypassed flushing
exception event handling jobs in this configuration. This created a race
condition where the driver could attempt to access the host controller
to handle an exception after the system had already entered a deep
power-down state, resulting in a system crash.

Explicitly flush this work and disable auto BKOPs before the suspend
callback proceeds. This guarantees that pending exception tasks complete
and prevents illegal hardware access during the power-down sequence.

Signed-off-by: Thomas Yen <thomasyen@google.com>
Cc: Stable Tree <stable@vger.kernel.org>
---
v3:
 - Add logic to disable BKOPs.
v2:
 - Add Cc: stable tag.
 - Reformat commit message text for better line wrapping.
---
 drivers/ufs/core/ufshcd.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/ufs/core/ufshcd.c b/drivers/ufs/core/ufshcd.c
index 0369043ca010..8c88dd5c2cca 100644
--- a/drivers/ufs/core/ufshcd.c
+++ b/drivers/ufs/core/ufshcd.c
@@ -9997,6 +9997,8 @@ static int __ufshcd_wl_suspend(struct ufs_hba *hba, enum ufs_pm_op pm_op)
 
 	if (req_dev_pwr_mode == UFS_ACTIVE_PWR_MODE &&
 			req_link_state == UIC_LINK_ACTIVE_STATE) {
+		ufshcd_disable_auto_bkops(hba);
+		flush_work(&hba->eeh_work);
 		goto vops_suspend;
 	}
 

base-commit: a48ca06cf343423faa01c573aeafba9fa5f92577
-- 
2.53.0.rc1.225.gd81095ad13-goog

Re: [PATCH v3 1/1] scsi: ufs: core: Flush exception handling work when RPM level is zero

[Peter Wang (王信友)]

On Thu, 2026-01-29 at 15:06 +0800, Thomas Yen wrote:
> Ensure that the exception event handling work is explicitly flushed
> during suspend when the runtime power management level is set to
> UFS_PM_LVL_0.
> 
> When the RPM level is zero, the device power mode and link state both
> remain active. Previously, the UFS core driver bypassed flushing
> exception event handling jobs in this configuration. This created a
> race
> condition where the driver could attempt to access the host
> controller
> to handle an exception after the system had already entered a deep
> power-down state, resulting in a system crash.
> 
> Explicitly flush this work and disable auto BKOPs before the suspend
> callback proceeds. This guarantees that pending exception tasks
> complete
> and prevents illegal hardware access during the power-down sequence.
> 
> Signed-off-by: Thomas Yen <thomasyen@google.com>
> Cc: Stable Tree <stable@vger.kernel.org>
> ---


Reviewed-by: Peter Wang <peter.wang@mediatek.com>

Re: [PATCH v3] scsi: ufs: core: Flush exception handling work when RPM level is zero

[Markus Elfring]

You should probably specify message recipients not only in the header field “Cc”.
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/process/submitting-patches.rst?h=v6.19-rc7#n231

…
> ---
> v3:
…
> v2:
>  - Add Cc: stable tag.
…

Will the tag “Fixes” become also helpful accordingly?
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/process/submitting-patches.rst?h=v6.19-rc7#n145

Regards,
Markus

Re: [PATCH v3 1/1] scsi: ufs: core: Flush exception handling work when RPM level is zero

[Bart Van Assche]

On 1/28/26 11:06 PM, Thomas Yen wrote:
> Ensure that the exception event handling work is explicitly flushed
> during suspend when the runtime power management level is set to
> UFS_PM_LVL_0.
> 
> When the RPM level is zero, the device power mode and link state both
> remain active. Previously, the UFS core driver bypassed flushing
> exception event handling jobs in this configuration. This created a race
> condition where the driver could attempt to access the host controller
> to handle an exception after the system had already entered a deep
> power-down state, resulting in a system crash.
> 
> Explicitly flush this work and disable auto BKOPs before the suspend
> callback proceeds. This guarantees that pending exception tasks complete
> and prevents illegal hardware access during the power-down sequence.
> 
> Signed-off-by: Thomas Yen <thomasyen@google.com>
> Cc: Stable Tree <stable@vger.kernel.org>
For future patch submissions, please place the Cc: tag above the
Signed-off-by tag. I think that is a widely used convention in the Linux
kernel community. Anyway:

Reviewed-by: Bart Van Assche <bvanassche@acm.org>

Re: [PATCH v3 1/1] scsi: ufs: core: Flush exception handling work when RPM level is zero

[Thomas Yen]

Hi Bart,

Thanks for the tip regarding the tag ordering. I will ensure the Cc
tag is placed above the Signed-off-by tag in future submissions.

I had just sent v4 (to add the missing Fixes tag) before seeing this
message. Since the code logic in v4 is identical to v3, I hope that is
acceptable. Thanks.

Thomas


On Fri, Jan 30, 2026 at 1:04 AM Bart Van Assche <bvanassche@acm.org> wrote:
>
> On 1/28/26 11:06 PM, Thomas Yen wrote:
> > Ensure that the exception event handling work is explicitly flushed
> > during suspend when the runtime power management level is set to
> > UFS_PM_LVL_0.
> >
> > When the RPM level is zero, the device power mode and link state both
> > remain active. Previously, the UFS core driver bypassed flushing
> > exception event handling jobs in this configuration. This created a race
> > condition where the driver could attempt to access the host controller
> > to handle an exception after the system had already entered a deep
> > power-down state, resulting in a system crash.
> >
> > Explicitly flush this work and disable auto BKOPs before the suspend
> > callback proceeds. This guarantees that pending exception tasks complete
> > and prevents illegal hardware access during the power-down sequence.
> >
> > Signed-off-by: Thomas Yen <thomasyen@google.com>
> > Cc: Stable Tree <stable@vger.kernel.org>
> For future patch submissions, please place the Cc: tag above the
> Signed-off-by tag. I think that is a widely used convention in the Linux
> kernel community. Anyway:
>
> Reviewed-by: Bart Van Assche <bvanassche@acm.org>
>

Re: [PATCH v3 1/1] scsi: ufs: core: Flush exception handling work when RPM level is zero

[Bart Van Assche]

On 1/29/26 9:19 AM, Thomas Yen wrote:
> I had just sent v4 (to add the missing Fixes tag) before seeing this
> message. Since the code logic in v4 is identical to v3, I hope that is
> acceptable.
It seems like our emails crossed each other. This is something that can
happen.

When reposting a patch, Reviewed-by tags should be included. I don't see
any Reviewed-by tags in v4 of this patch although Peter Wang had posted
a Reviewed-by?

Thanks,

Bart.

Re: [PATCH v3 1/1] scsi: ufs: core: Flush exception handling work when RPM level is zero

[Thomas Yen]

Hi Bart,

My apologies. I missed that Peter had already replied with his
Reviewed-by tag on this v3 thread before I sent v4.

Since v4 is currently bare of tags but the code is identical, would
you prefer I send a v5 to consolidate all the tags and fix the Cc-tag
ordering? Or should I wait for you and Peter to reply to the v4
thread?

Thanks,
Thomas

On Fri, Jan 30, 2026 at 1:23 AM Bart Van Assche <bvanassche@acm.org> wrote:
>
> On 1/29/26 9:19 AM, Thomas Yen wrote:
> > I had just sent v4 (to add the missing Fixes tag) before seeing this
> > message. Since the code logic in v4 is identical to v3, I hope that is
> > acceptable.
> It seems like our emails crossed each other. This is something that can
> happen.
>
> When reposting a patch, Reviewed-by tags should be included. I don't see
> any Reviewed-by tags in v4 of this patch although Peter Wang had posted
> a Reviewed-by?
>
> Thanks,
>
> Bart.

Re: [PATCH v3 1/1] scsi: ufs: core: Flush exception handling work when RPM level is zero

[Bart Van Assche]

On 1/29/26 9:39 AM, Thomas Yen wrote:
> My apologies. I missed that Peter had already replied with his
> Reviewed-by tag on this v3 thread before I sent v4.

In the future, please leave more time between posting different versions
of a patch. Posting four versions of the same patch in five days is too
frequent because it doesn't give reviewers enough time to react.

Thanks,

Bart.