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 for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <e3fa13724a08bfaa764d57a3d223d201cd4d30c0.camel@mediatek.com>
Date: Mon, 20 Oct 2025 06:53:06 +0000
From: Peter Wang (王信友) <peter.wang@...iatek.com>
To: "palash.kambar@....qualcomm.com" <palash.kambar@....qualcomm.com>,
	"bvanassche@....org" <bvanassche@....org>
CC: "quic_nitirawa@...cinc.com" <quic_nitirawa@...cinc.com>,
	"James.Bottomley@...senpartnership.com"
	<James.Bottomley@...senpartnership.com>, "linux-arm-msm@...r.kernel.org"
	<linux-arm-msm@...r.kernel.org>, "adrian.hunter@...el.com"
	<adrian.hunter@...el.com>, "linux-scsi@...r.kernel.org"
	<linux-scsi@...r.kernel.org>, "linux-kernel@...r.kernel.org"
	<linux-kernel@...r.kernel.org>, "ebiggers@...nel.org" <ebiggers@...nel.org>,
	"peter.griffin@...aro.org" <peter.griffin@...aro.org>, "beanhuo@...ron.com"
	<beanhuo@...ron.com>, "alim.akhtar@...sung.com" <alim.akhtar@...sung.com>,
	"krzk@...nel.org" <krzk@...nel.org>, "quic_nguyenb@...cinc.com"
	<quic_nguyenb@...cinc.com>, "mani@...nel.org" <mani@...nel.org>,
	"neil.armstrong@...aro.org" <neil.armstrong@...aro.org>,
	"avri.altman@....com" <avri.altman@....com>, "martin.petersen@...cle.com"
	<martin.petersen@...cle.com>, "quic_cang@...cinc.com" <quic_cang@...cinc.com>
Subject: Re: [PATCH V1 2/2] ufs: ufs-qcom: Disable AHIT before SQ tail update
 to prevent race in MCQ mode

On Sat, 2025-10-18 at 12:14 +0530, Palash Kambar wrote:
> Thanks for the feedback, Bart. However, I believe setting the runtime
> suspend delay to 5ms
>  might be overly aggressive for the system and may have below side
> effects:
> 
> 1. Short autosuspend timeouts can cause the UFS device to enter low-
> power states even
> during brief idle periods. This results in resume latency,
> introducing delays when the
> device needs to wake up for subsequent operations.
> 2. Frequent suspend and resume cycles may disrupt data flow,
> particularly in workloads
> with bursty or intermittent I/O, leading to performance degradation.
> 3. When the autosuspend timer is overly aggressive, the UFS device
> may repeatedly
> transition between active and low-power states. These transitions
> themselves consume power,
> and if they occur too often, they can offset or even negate the
> intended power savings.
> 
> Please let me know your thoughts on this.
> 
> Regards,
> 
> 
> Palash K
> 

Hi Palash,

Maybe disabling AH8 and enabling both UFSHCD_CAP_CLK_SCALING
and UFSHCD_CAP_HIBERN8_WITH_CLK_GATING is sufficient?

Thanks
Peter

> 

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ