On Wed, Aug 06, 2025 at 09:51:43AM GMT, Alim Akhtar wrote:

[...]

quoted

quoted

quoted

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.

quoted

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

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