linux-kernel - Re: [PATCH RFC] regulator: core: fix constraints handling if current state out of range

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: <20251105100852.2c01dd9f@kemnade.info>
Date: Wed, 5 Nov 2025 10:08:52 +0100
From: Andreas Kemnade <andreas@...nade.info>
To: Mark Brown <broonie@...nel.org>
Cc: Liam Girdwood <lgirdwood@...il.com>, linux-kernel@...r.kernel.org
Subject: Re: [PATCH RFC] regulator: core: fix constraints handling if
 current state out of range

On Tue, 4 Nov 2025 13:52:11 +0000
Mark Brown <broonie@...nel.org> wrote:

> On Mon, Nov 03, 2025 at 08:32:41PM +0100, Andreas Kemnade wrote:
> 
> > -		if (current_uV < rdev->constraints->min_uV) {
> > +		if ((current_uV < rdev->constraints->min_uV) ||
> > +		    (current_uV > rdev->constraints->max_uV)) {
> >  			target_min = rdev->constraints->min_uV;
> > -			target_max = rdev->constraints->min_uV;
> > -		}
> > -
> > -		if (current_uV > rdev->constraints->max_uV) {
> > -			target_min = rdev->constraints->max_uV;
> >  			target_max = rdev->constraints->max_uV;
> >  		}  
> 
> There's a valid issue here if we can't represent the exact constraint
> (the hope was that people wouldn't specify constraints that their
> hardware wasn't capable of representing but we can't exactly stop
> them...) however this change is risky in the case where the voltage is
> too high since if we specify a range from minimum to maximum we'll try
> to select a voltage as close as possible to the minimum.  That could
> result in a large change if the range is wide, and potentially go under
> the voltage the hardware needs for it's current configuration.  We were
> trying to set the highest voltage in the range to minimise the risk
> there.  This isn't a concern in the case where we're raising the
> voltage.

So basically you do not trust the constrains too much (which is
understandable) and think that
a voltage near the boot default is the safest one.
As a hw engineer I would first try to wire things to regulators having
useable defaults (in that case a too wide range does not harm, because
voltage is ok). As a second choice I would use a regulator being off per
default which needs to be configured to a safe voltage. Then of course
ranges matter, but IHMO there is no indication which voltage in the range
is the safest one.
But again, this change is dangerous. maybe another tag like
regulator-prefer-low/high might be interesting.

Having to specify odd values with more than 1 ppm precision for
a regulator with maybe 1 percent precision is also ugly.
So the only improvement possible is to find the nearest possible
voltage via list_voltages() still matching the constraints.

Regards,
Andreas