linux-kernel - Re: [PATCH V1] ufs: ufs-qcom: Fix UFS OCP issue during UFS power down(PC=3)

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <ugyg2k4typuw6btpcxtbxs4bv5oisuor37m6efu5mnsvirqyvo@yqzwm2t6bm7i>
Date: Thu, 23 Oct 2025 10:38:53 +0530
From: Manivannan Sadhasivam <mani@...nel.org>
To: Nitin Rawat <nitin.rawat@....qualcomm.com>
Cc: James.Bottomley@...senpartnership.com, martin.petersen@...cle.com, 
	bvanassche@....org, konrad.dybcio@....qualcomm.com, linux-arm-msm@...r.kernel.org, 
	linux-kernel@...r.kernel.org, linux-scsi@...r.kernel.org
Subject: Re: [PATCH V1] ufs: ufs-qcom: Fix UFS OCP issue during UFS power
 down(PC=3)

On Sun, Oct 12, 2025 at 11:08:28PM +0530, Nitin Rawat wrote:
> 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@....qualcomm.com>

Reviewed-by: Manivannan Sadhasivam <mani@...nel.org>

- Mani

> ---
>  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 89a3328a7a75..cb54628be466 100644
> --- a/drivers/ufs/host/ufs-qcom.c
> +++ b/drivers/ufs/host/ufs-qcom.c
> @@ -744,8 +744,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.50.1
> 

-- 
மணிவண்ணன் சதாசிவம்