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] [day] [month] [year] [list]

Message-ID: <aQs5oL_VZkorH8Zh@finisterre.sirena.org.uk>
Date: Wed, 5 Nov 2025 11:48:48 +0000
From: Mark Brown <broonie@...nel.org>
To: Andreas Kemnade <andreas@...nade.info>
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 Wed, Nov 05, 2025 at 10:08:52AM +0100, Andreas Kemnade wrote:
> Mark Brown <broonie@...nel.org> wrote:

> > 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

> 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.

Well, the problem is that the constraints need to be combined with the
current operating state for the hardware and at the point where we're
applying configuration from the constraints for the first time drivers
haven't had a chance to start so we don't really know what state the
hardware is in - we might be running at a high operating point, or have
some device that needs the upper end of the voltage range powered up and
doing something we need.  Ideally the hardware would come to us in a
state matching the constraints so we just don't need to do anything.

> 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.

Yes, I think that's the only safe thing to do.  For the lower voltage
that's just a normal voltage set, but for the upper it'd be new.

Download attachment "signature.asc" of type "application/pgp-signature" (489 bytes)