[PATCH AUTOSEL 6.19-6.18] scsi: ufs: core: Reset urgent_bkops_lvl to allow runtime PM power mode

[Sasha Levin <sashal@kernel.org>]

From: Won Jung <wone.jung@samsung.com>

[ Upstream commit 5b313760059c9df7d60aba7832279bcb81b4aec0 ]

Ensures that UFS Runtime PM can achieve power saving after System PM
suspend by resetting hba->urgent_bkops_lvl. Also modify the
ufshcd_bkops_exception_event_handler to avoid setting urgent_bkops_lvl when
status is 0, which helps maintain optimal power management.

On UFS devices supporting UFSHCD_CAP_AUTO_BKOPS_SUSPEND, a BKOPS exception
event can lead to a situation where UFS Runtime PM can't enter low-power
mode states even after the BKOPS exception has been resolved.

BKOPS exception with bkops status 0 occurs, the driver logs:

 "ufshcd_bkops_exception_event_handler: device raised urgent BKOPS exception for bkops status 0"

When a BKOPS exception occurs, ufshcd_bkops_exception_event_handler() reads
the BKOPS status and sets hba->urgent_bkops_lvl to BKOPS_STATUS_NO_OP(0).
This allows the device to perform Runtime PM without changing the UFS power
mode.  (__ufshcd_wl_suspend(hba, UFS_RUNTIME_PM))

During system PM suspend, ufshcd_disable_auto_bkops() is called, disabling
auto bkops. After UFS System PM Resume, when runtime PM attempts to suspend
again, ufshcd_urgent_bkops() is invoked. Since hba->urgent_bkops_lvl
remains at BKOPS_STATUS_NO_OP(0), ufshcd_enable_auto_bkops() is triggered.

However, in ufshcd_bkops_ctrl(), the driver compares the current BKOPS
status with hba->urgent_bkops_lvl, and only enables auto bkops if
curr_status >= hba->urgent_bkops_lvl.  Since both values are 0, the
condition is met

As a result, __ufshcd_wl_suspend(hba, UFS_RUNTIME_PM) skips power mode
transitions and remains in an active state, preventing power saving even
though no urgent BKOPS condition exists.

Signed-off-by: Won Jung <wone.jung@samsung.com>
Reviewed-by: Peter Wang <peter.wang@mediatek.com>
Link: https://patch.msgid.link/1891546521.01770806581968.JavaMail.epsvc@epcpadp2new
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

The bug exists in v5.15 and v6.1 — both LTS kernels. The vulnerable code
pattern (`if (curr_status < BKOPS_STATUS_PERF_IMPACT)` setting
`urgent_bkops_lvl = curr_status` where curr_status could be 0) has been
present since the exception handler was first written.

## Analysis

### What the commit fixes

This commit fixes a power management regression on UFS storage devices
that support `UFSHCD_CAP_AUTO_BKOPS_SUSPEND`. The bug scenario:

1. A device raises a spurious urgent BKOPS exception with status 0
   (`BKOPS_STATUS_NO_OP`)
2. `ufshcd_bkops_exception_event_handler()` sets `hba->urgent_bkops_lvl
   = 0`
3. During system suspend, `ufshcd_disable_auto_bkops()` resets
   `is_urgent_bkops_lvl_checked = false` but does NOT reset
   `urgent_bkops_lvl`
4. After resume, Runtime PM tries to suspend via `__ufshcd_wl_suspend()`
   → `ufshcd_bkops_ctrl()`
5. In `ufshcd_bkops_ctrl()`, `curr_status(0) >= urgent_bkops_lvl(0)`
   evaluates true, so auto BKOPS gets enabled
6. With auto BKOPS enabled, the runtime suspend path skips power mode
   transition, keeping the device in active state permanently

This causes **persistent excessive power consumption** on
mobile/embedded devices — a serious user-visible issue.

### Two-part fix

1. **`ufshcd_disable_auto_bkops()`**: Resets `urgent_bkops_lvl` to
   `BKOPS_STATUS_PERF_IMPACT` (the default/safe value) when auto BKOPS
   is disabled during system suspend. This mirrors what
   `ufshcd_force_reset_auto_bkops()` already does at line 5987.

2. **`ufshcd_bkops_exception_event_handler()`**: Adds `curr_status >
   BKOPS_STATUS_NO_OP` check to prevent setting `urgent_bkops_lvl` to 0
   when a device raises a spurious exception with status 0.

### Stable kernel criteria assessment

- **Fixes a real bug**: Yes — prevents UFS Runtime PM from entering low-
  power modes, causing power drain
- **Obviously correct**: Yes — both changes are small, logical, and
  align with existing patterns (the reset matches
  `ufshcd_force_reset_auto_bkops`, and the status 0 filter is clearly
  the right semantic)
- **Small and contained**: Yes — 2 lines changed in a single file, no
  API/ABI changes
- **No new features**: Correct — purely a bug fix
- **Reviewed**: Yes — `Reviewed-by: Peter Wang` (MediaTek UFS
  maintainer)
- **Tested**: From Samsung, who manufactured the UFS device exhibiting
  this bug
- **Historical precedent**: Commit `be32acff43800` fixed the same class
  of bug in 2020 and was stable material (had `Fixes:` tag)
- **Wide applicability**: Affects all stable trees from v5.15+ (the
  vulnerable code exists in all of them)
- **Low risk**: The changes are minimal and defensive — they only affect
  an edge case (status 0 exception) and reset to the safe default value

### Risk assessment

**Risk: Very Low**
- The fix adds a safe default reset and tightens a condition to exclude
  an invalid state
- The `BKOPS_STATUS_PERF_IMPACT` reset value is the same value used in
  initialization and in `ufshcd_force_reset_auto_bkops()`
- No functional change for the normal case where status > 0
- May need minor context adjustment for older stable trees (trace
  function signature change) but the actual fix applies cleanly

### Verification

- **Verified** `ufshcd_disable_auto_bkops()` current code at line 5933:
  does NOT reset `urgent_bkops_lvl` (confirmed via Read tool)
- **Verified** `ufshcd_bkops_exception_event_handler()` at line 6065:
  uses `if (curr_status < BKOPS_STATUS_PERF_IMPACT)` which accepts
  status 0 (confirmed via Read tool)
- **Verified** `ufshcd_bkops_ctrl()` at line 6030: `curr_status >=
  status` where status comes from `hba->urgent_bkops_lvl` — so status 0
  causes `0 >= 0` = true, enabling auto BKOPS (confirmed via Read tool)
- **Verified** `ufshcd_force_reset_auto_bkops()` at line 5987: already
  resets `urgent_bkops_lvl = BKOPS_STATUS_PERF_IMPACT`, confirming this
  is the expected default (confirmed via Read tool)
- **Verified** prior fix `be32acff43800` (2020): addressed same class of
  bug where `urgent_bkops_lvl` got set to 0 via `ufshcd_bkops_ctrl`, had
  `Fixes:` tag (confirmed via git show)
- **Verified** prerequisite `0a5167e21126c` (refactor removing
  `ufshcd_urgent_bkops()`): landed in v6.12. The fix itself does NOT
  depend on this refactor — the two functions being changed exist in all
  stable trees (confirmed by checking v6.11, v6.1, v5.15 code via git
  show)
- **Verified** `__ufshcd_wl_suspend()` calls
  `ufshcd_disable_auto_bkops()` during system PM (not runtime PM) at
  line 10059, confirming the suspend path described in the commit
  message (confirmed via Grep)
- **Verified** bug affects stable trees v5.15.y and v6.1.y by checking
  the exception handler code is identical (confirmed via git show)
- **Verified** BKOPS_STATUS_NO_OP = 0x0 and BKOPS_STATUS_PERF_IMPACT =
  0x2 in include/ufs/ufs.h (confirmed via agent research)

**YES**

 drivers/ufs/core/ufshcd.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/ufs/core/ufshcd.c b/drivers/ufs/core/ufshcd.c
index 09f0d77d57f02..c71a449850573 100644
--- a/drivers/ufs/core/ufshcd.c
+++ b/drivers/ufs/core/ufshcd.c
@@ -5959,6 +5959,7 @@ static int ufshcd_disable_auto_bkops(struct ufs_hba *hba)
 
 	hba->auto_bkops_enabled = false;
 	trace_ufshcd_auto_bkops_state(hba, "Disabled");
+	hba->urgent_bkops_lvl = BKOPS_STATUS_PERF_IMPACT;
 	hba->is_urgent_bkops_lvl_checked = false;
 out:
 	return err;
@@ -6062,7 +6063,7 @@ static void ufshcd_bkops_exception_event_handler(struct ufs_hba *hba)
 	 * impacted or critical. Handle these device by determining their urgent
 	 * bkops status at runtime.
 	 */
-	if (curr_status < BKOPS_STATUS_PERF_IMPACT) {
+	if ((curr_status > BKOPS_STATUS_NO_OP) && (curr_status < BKOPS_STATUS_PERF_IMPACT)) {
 		dev_err(hba->dev, "%s: device raised urgent BKOPS exception for bkops status %d\n",
 				__func__, curr_status);
 		/* update the current status as the urgent bkops level */
-- 
2.51.0