From: Andreas Kemnade <andreas@kemnade.info>
To: Mark Brown <broonie@kernel.org>
Cc: Liam Girdwood <lgirdwood@gmail.com>, linux-kernel@vger.kernel.org
Subject: Re: [PATCH RFC] regulator: core: fix constraints handling if current state out of range
Date: Wed, 5 Nov 2025 10:08:52 +0100 [thread overview]
Message-ID: <20251105100852.2c01dd9f@kemnade.info> (raw)
In-Reply-To: <aQoFC3YDNlw4imML@finisterre.sirena.org.uk>
On Tue, 4 Nov 2025 13:52:11 +0000
Mark Brown <broonie@kernel.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
next prev parent reply other threads:[~2025-11-05 9:25 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-11-03 19:32 Andreas Kemnade
2025-11-04 13:52 ` Mark Brown
2025-11-05 9:08 ` Andreas Kemnade [this message]
2025-11-05 11:48 ` Mark Brown
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20251105100852.2c01dd9f@kemnade.info \
--to=andreas@kemnade.info \
--cc=broonie@kernel.org \
--cc=lgirdwood@gmail.com \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®