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: <0d6801dc07b9$b869adf0$293d09d0$@samsung.com>
Date: Thu, 7 Aug 2025 22:08:32 +0530
From: "Alim Akhtar" <alim.akhtar@...sung.com>
To: "'Manivannan Sadhasivam'" <mani@...nel.org>
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



> -----Original Message-----
> From: 'Manivannan Sadhasivam' <mani@...nel.org>
> Sent: Wednesday, August 6, 2025 4:56 PM
> To: Alim Akhtar <alim.akhtar@...sung.com>
> Cc: 'Konrad Dybcio' <konrad.dybcio@....qualcomm.com>; 'Krzysztof
[...]

> > >
> > > 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.
> > >
> > Possibly someone need to check with designer of the SoC if that is possible
> or not.
> 
> It's not just clock. We need to consider reducing regulator, interconnect
> votes also. But as I said above, limiting the gear/mode will take care of all
> these parameters.
> 
> > Did we already tried _quirk_? If not, why not?
> > If the board is so poorly designed and can't take care of the channel
> > loses or heat dissipation etc, Then I assumed the gear negotiation
> > between host and device should fail for the higher gear and driver can have
> a re-try logic to re-init / re-try "power mode change" at the lower gear. Is
> that not possible / feasible?
> >
> 
> I don't see why we need to add extra logic in the UFS driver if we can extract
> that information from DT.
> 
You didn’t answer my question entirely, I am still not able to visualised how come Linkup is happening in higher gear and then 
Suddenly it is failing and we need to reduce the gear to solve that?
That's why my suggestion is to go for a re-try at lower gear when problem happens.
It is not that since adding DT property is simple to just go that path, that is solving _just_ this case, may be. 



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