[PATCH AUTOSEL 6.17] scsi: ufs: ufs-qcom: Fix UFS OCP issue during UFS power down (PC=3)

[Sasha Levin <sashal@kernel.org>]

From: Nitin Rawat <nitin.rawat@oss.qualcomm.com>

[ Upstream commit 5127be409c6c3815c4a7d8f6d88043e44f9b9543 ]

According to UFS specifications, the power-off sequence for a UFS device
includes:

 - Sending an SSU command with Power_Condition=3 and await a response.

 - Asserting RST_N low.

 - Turning off REF_CLK.

 - Turning off VCC.

 - Turning off VCCQ/VCCQ2.

As part of ufs shutdown, after the SSU command completion, asserting
hardware reset (HWRST) triggers the device firmware to wake up and
execute its reset routine. This routine initializes hardware blocks and
takes a few milliseconds to complete. During this time, the ICCQ draws a
large current.

This large ICCQ current may cause issues for the regulator which is
supplying power to UFS, because the turn off request from UFS driver to
the regulator framework will be immediately followed by low power
mode(LPM) request by regulator framework. This is done by framework
because UFS which is the only client is requesting for disable. So if
the rail is still in the process of shutting down while ICCQ exceeds LPM
current thresholds, and LPM mode is activated in hardware during this
state, it may trigger an overcurrent protection (OCP) fault in the
regulator.

To prevent this, a 10ms delay is added after asserting HWRST. This
allows the reset operation to complete while power rails remain active
and in high-power mode.

Currently there is no way for Host to query whether the reset is
completed or not and hence this the delay is based on experiments with
Qualcomm UFS controllers across multiple UFS vendors.

Signed-off-by: Nitin Rawat <nitin.rawat@oss.qualcomm.com>
Reviewed-by: Manivannan Sadhasivam <mani@kernel.org>
Link: https://patch.msgid.link/20251012173828.9880-1-nitin.rawat@oss.qualcomm.com
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:

Based on my comprehensive analysis using semantic code analysis tools
and repository examination, here is my assessment:

## BACKPORT RECOMMENDATION: YES

## Analysis Summary

### Semantic Analysis Tools Used:

1. **mcp__semcode__find_function** - Located the `ufs_qcom_suspend` and
   `ufs_qcom_device_reset_ctrl` functions
2. **mcp__semcode__find_callers** - Found that
   `ufs_qcom_device_reset_ctrl` is called by only 2 functions, making
   impact analysis straightforward
3. **mcp__semcode__find_callchain** - Traced the call path showing this
   is invoked through variant ops during system suspend
4. **mcp__semcode__diff_functions** - Confirmed this is a minimal
   semantic change (just adding a delay)
5. **git log/blame analysis** - Traced the historical context

### Key Findings:

#### 1. **Impact & Scope Analysis**
- **Function location**: `drivers/ufs/host/ufs-qcom.c:731` in
  `ufs_qcom_suspend()`
- **Call graph**: The function is registered as a suspend callback in
  `ufs_hba_variant_ops` and gets invoked during system suspend
  operations
- **Affected devices**: All Qualcomm UFS controllers (MSM8994, MSM8996,
  SDM845, SM8150, SM8250, SM8350, SM8450, SM8550, SM8650, SM8750, and
  many more)
- **User exposure**: HIGH - triggered during normal suspend/resume
  cycles

#### 2. **Code Change Analysis**
The change is extremely minimal and low-risk:
```c
if (ufs_qcom_is_link_off(hba) && host->device_reset) {
    ufs_qcom_device_reset_ctrl(hba, true);
+   usleep_range(10000, 11000);  // Only change: 10ms delay
}
```

#### 3. **Historical Context**
- The device reset during suspend was introduced in **v5.12-rc1**
  (commit b61d041413685, Jan 2021)
- This OCP issue has existed for **~4 years**
- Not a recent regression - this is a long-standing hardware timing
  issue

#### 4. **Problem Severity**
According to the commit message and code analysis:
- **Issue**: After asserting hardware reset, the UFS device firmware
  wakes up and draws large ICCQ current
- **Consequence**: Can trigger overcurrent protection (OCP) faults in
  the regulator hardware
- **Impact**: Potential hardware protection faults during power down
  sequence
- **Root cause**: Race between device reset completion and regulator
  entering low-power mode

#### 5. **Risk Assessment**
- **Regression risk**: VERY LOW - only adds a 10ms sleep
- **Side effects**: None beyond slightly longer suspend time (10ms is
  negligible)
- **Dependencies**: No new dependencies introduced
- **Architectural changes**: None

### Reasoning for YES:

1. **Fixes important hardware issue**: Prevents OCP faults that could
   affect regulator hardware integrity
2. **Wide device impact**: Affects entire Qualcomm UFS ecosystem (very
   popular in Android devices)
3. **Long-standing bug**: Has existed since v5.12 (2021), not a new
   feature
4. **Minimal and safe**: Single-line change with no complex logic
5. **Follows stable rules**:
   - ✓ It fixes a bug
   - ✓ Obviously correct
   - ✓ Small and contained
   - ✓ Doesn't add new features
   - ✓ Low regression risk

### Notable Observations:

- **No explicit stable tag**: The commit does NOT include "Cc:
  stable@vger.kernel.org", which typically indicates maintainers didn't
  prioritize it for backport
- **Cautious language**: Commit uses "may cause" rather than "causes" -
  suggesting this is a potential issue rather than frequently reported
  problem
- **No user reports mentioned**: No indication of widespread user-
  visible failures

### Recommendation:

**YES - Backport to stable kernels 5.12+**

Despite the lack of explicit stable tag, this commit should be
backported because:
- It prevents potential hardware protection faults
- The fix is trivial and risk-free
- It affects a critical subsystem (storage) on widely-used platforms
- The issue has existed for years across all Qualcomm UFS devices

Priority: **MEDIUM** - This is a valid fix for a hardware timing issue,
but the lack of stable tag and cautious commit language suggests it's
not causing widespread failures. However, preventing OCP faults is
important for hardware longevity.

 drivers/ufs/host/ufs-qcom.c | 15 ++++++++++++++-
 1 file changed, 14 insertions(+), 1 deletion(-)

diff --git a/drivers/ufs/host/ufs-qcom.c b/drivers/ufs/host/ufs-qcom.c
index 9574fdc2bb0fd..8fe4405ec0ec7 100644
--- a/drivers/ufs/host/ufs-qcom.c
+++ b/drivers/ufs/host/ufs-qcom.c
@@ -741,8 +741,21 @@ static int ufs_qcom_suspend(struct ufs_hba *hba, enum ufs_pm_op pm_op,
 
 
 	/* reset the connected UFS device during power down */
-	if (ufs_qcom_is_link_off(hba) && host->device_reset)
+	if (ufs_qcom_is_link_off(hba) && host->device_reset) {
 		ufs_qcom_device_reset_ctrl(hba, true);
+		/*
+		 * After sending the SSU command, asserting the rst_n
+		 * line causes the device firmware to wake up and
+		 * execute its reset routine.
+		 *
+		 * During this process, the device may draw current
+		 * beyond the permissible limit for low-power mode (LPM).
+		 * A 10ms delay, based on experimental observations,
+		 * allows the UFS device to complete its hardware reset
+		 * before transitioning the power rail to LPM.
+		 */
+		usleep_range(10000, 11000);
+	}
 
 	return ufs_qcom_ice_suspend(host);
 }
-- 
2.51.0