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: <wpfchmssbrfhcxnoe37agonyc5s7e2onark77dxrlt5jrxxzo2@g57mdqrgj7uk>
Date: Wed, 6 Aug 2025 10:35:27 +0530
From: 'Manivannan Sadhasivam' <mani@...nel.org>
To: Alim Akhtar <alim.akhtar@...sung.com>
Cc: 'Konrad Dybcio' <konrad.dybcio@....qualcomm.com>, 
	'Krzysztof Kozlowski' <krzk@...nel.org>, 'Ram Kumar Dwivedi' <quic_rdwivedi@...cinc.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 Wed, Aug 06, 2025 at 09:51:43AM GMT, Alim Akhtar wrote:

[...]

> > >> Introducing generic solutions preemptively for problems that are
> > >> simple in concept and can occur widely is good practice (although
> > >> it's sometimes hard to gauge whether this is a one-off), as if the
> > >> issue spreads a generic solution will appear at some point, but we'll
> > >> have to keep supporting the odd ones as well
> > >>
> > > Ok,
> > > I would prefer if we add a property which sounds like "poor thermal
> > > dissipation" or "routing channel loss" rather than adding limiting UFS gear
> > properties.
> > > Poor thermal design or channel losses are generic enough and can happen
> > on any board.
> > 
> > This is exactly what I'm trying to avoid through my suggestion - one board
> > may have poor thermal dissipation, another may have channel losses, yet
> > another one may feature a special batch of UFS chips that will set the world
> > on fire if instructed to attempt link training at gear 7 - they all are causes, as
> > opposed to describing what needs to happen (i.e. what the hardware must
> > be treated as - gear N incapable despite what can be discovered at runtime),
> > with perhaps a comment on the side
> > 
> But the solution for all possible board problems can't be by limiting Gear speed.

Devicetree properties should precisely reflect how they are relevant to the
hardware. 'limiting-gear-speed' is self-explanatory that the gear speed is
getting limited (for a reason), but the devicetree doesn't need to describe the
*reason* itself.

> So it should be known why one particular board need to limit the gear.

That goes into the description, not in the property name.

> I understand that this is a static configuration, where it is already known that board is broken for higher Gear.
> Can this be achieved by limiting the clock? If not, can we add a board specific _quirk_ and let the _quirk_ to be enabled from vendor specific hooks? 
> 

How can we limit the clock without limiting the gears? When we limit the
gear/mode, both clock and power are implicitly limited.

- Mani

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