linux-kernel - Re: [PATCH 2/3] arm64: dts: qcom: sa8155: Add gear and rate limit properties to UFS

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: <2nm7xurqgzrnffustrsmswy2rbug6geadaho42qlb7tr2jirlr@uw5gaery445y>
Date: Fri, 1 Aug 2025 17:49:13 +0530
From: Manivannan Sadhasivam <mani@...nel.org>
To: Krzysztof Kozlowski <krzk@...nel.org>
Cc: Ram Kumar Dwivedi <quic_rdwivedi@...cinc.com>, alim.akhtar@...sung.com, 
	avri.altman@....com, bvanassche@....org, robh@...nel.org, krzk+dt@...nel.org, 
	conor+dt@...nel.org, andersson@...nel.org, konradybcio@...nel.org, 
	James.Bottomley@...senpartnership.com, martin.petersen@...cle.com, agross@...nel.org, 
	linux-arm-msm@...r.kernel.org, linux-scsi@...r.kernel.org, devicetree@...r.kernel.org, 
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH 2/3] arm64: dts: qcom: sa8155: Add gear and rate limit
 properties to UFS

On Fri, Aug 01, 2025 at 11:12:42AM GMT, Krzysztof Kozlowski wrote:
> On 01/08/2025 11:10, Ram Kumar Dwivedi wrote:
> > 
> > 
> > On 01-Aug-25 1:58 PM, Manivannan Sadhasivam wrote:
> >> On Thu, Jul 24, 2025 at 09:48:53AM GMT, Krzysztof Kozlowski wrote:
> >>> On 22/07/2025 18:11, Ram Kumar Dwivedi wrote:
> >>>> Add optional limit-hs-gear and limit-rate properties to the UFS node to
> >>>> support automotive use cases that require limiting the maximum Tx/Rx HS
> >>>> gear and rate due to hardware constraints.
> >>>
> >>> What hardware constraints? This needs to be clearly documented.
> >>>
> >>
> >> Ram, both Krzysztof and I asked this question, but you never bothered to reply,
> >> but keep on responding to other comments. This won't help you to get this series
> >> merged in any form.
> >>
> >> Please address *all* review comments before posting next iteration.
> > 
> > Hi Mani,
> > 
> > Apologies for the delay in responding. 
> > I had planned to explain the hardware constraints in the next patchset’s commit message, which is why I didn’t reply earlier. 
> > 
> > To clarify: the limitations are due to customer board designs, not our SoC. Some boards can't support higher gear operation, hence the need for optional limit-hs-gear and limit-rate properties.
> > 
> 
> That's vague and does not justify the property. You need to document
> instead hardware capabilities or characteristic. Or explain why they
> cannot. With such form I will object to your next patch.
> 

I had an offline chat with Ram and got clarified on what these properties are.
The problem here is not with the SoC, but with the board design. On some Qcom
customer designs, both the UFS controller in the SoC and the UFS device are
capable of operating at higher gears (say G5). But due to board constraints like
poor thermal dissipation, routing loss, the board cannot efficiently operate at
the higher speeds.

So the customers wanted a way to limit the gear speed (say G3) and rate
(say Mode-A) on the specific board DTS.

But this series ended up adding these properties in the SoC dtsi, which was
wrong in the first place. And the patch description also lacked the above
reasoning.

I hope Ram will fix these two things in the next version.

FWIW: The customer is using a DT overlay to add these properties to the base
DTS. So there would be no DTS change posted in the next version.

- Mani

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