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); }