| 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
| ||
|
Message-ID: <e9100dbf-524e-4edd-aba3-71e28fbc07d0@nvidia.com>
Date: Tue, 29 Jul 2025 09:28:17 +0100
From: Jon Hunter <jonathanh@...dia.com>
To: Romain Gantois <romain.gantois@...tlin.com>,
Liam Girdwood <lgirdwood@...il.com>, Mark Brown <broonie@...nel.org>
Cc: Thomas Petazzoni <thomas.petazzoni@...tlin.com>,
linux-kernel@...r.kernel.org,
"linux-tegra@...r.kernel.org" <linux-tegra@...r.kernel.org>
Subject: Re: [PATCH v2] regulator: core: repeat voltage setting request for
stepped regulators
Hi Romain,
On 18/07/2025 15:11, Romain Gantois wrote:
> The regulator_set_voltage() function may exhibit unexpected behavior if the
> target regulator has a maximum voltage step constraint. With such a
> constraint, the regulator core may clamp the requested voltage to a lesser
> value, to ensure that the voltage delta stays under the specified limit.
>
> This means that the resulting regulator voltage depends on the current
> voltage, as well as the requested range, which invalidates the assumption
> that a repeated request for a specific voltage range will amount to a noop.
>
> Considering the case of a regulator with a maximum voltage step constraint
> of 1V:
>
> initial voltage: 2.5V
>
> consumer requests 4V
> expected result: 3.5V
> resulting voltage: 3.5V
>
> consumer requests 4V again
> expected result: 4V
> actual result: 3.5V
>
> Correct this by repeating attempts to balance the regulator voltage until
> the result converges.
>
> Signed-off-by: Romain Gantois <romain.gantois@...tlin.com>
> ---
> drivers/regulator/core.c | 43 ++++++++++++++++++++++++++++++++++++++++++-
> 1 file changed, 42 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/regulator/core.c b/drivers/regulator/core.c
> index cbd6d53ebfb5ef21b5dfc8b0f1f1f033772a886c..8ed9b96518cf5186c0db147a6895a92bc59fae4e 100644
> --- a/drivers/regulator/core.c
> +++ b/drivers/regulator/core.c
> @@ -3797,6 +3797,16 @@ static int _regulator_do_set_suspend_voltage(struct regulator_dev *rdev,
> return 0;
> }
>
> +static int regulator_get_voltage_delta(struct regulator_dev *rdev, int uV)
> +{
> + int current_uV = regulator_get_voltage_rdev(rdev);
> +
> + if (current_uV < 0)
> + return current_uV;
> +
> + return abs(current_uV - uV);
> +}
> +
> static int regulator_set_voltage_unlocked(struct regulator *regulator,
> int min_uV, int max_uV,
> suspend_state_t state)
> @@ -3804,8 +3814,8 @@ static int regulator_set_voltage_unlocked(struct regulator *regulator,
> struct regulator_dev *rdev = regulator->rdev;
> struct regulator_voltage *voltage = ®ulator->voltage[state];
> int ret = 0;
> + int current_uV, delta, new_delta;
> int old_min_uV, old_max_uV;
> - int current_uV;
>
> /* If we're setting the same range as last time the change
> * should be a noop (some cpufreq implementations use the same
> @@ -3852,6 +3862,37 @@ static int regulator_set_voltage_unlocked(struct regulator *regulator,
> voltage->max_uV = old_max_uV;
> }
>
> + if (rdev->constraints->max_uV_step > 0) {
> + /* For regulators with a maximum voltage step, reaching the desired
> + * voltage might take a few retries.
> + */
> + ret = regulator_get_voltage_delta(rdev, min_uV);
> + if (ret < 0)
> + goto out;
> +
> + delta = ret;
> +
> + while (delta > 0) {
> + ret = regulator_balance_voltage(rdev, state);
> + if (ret < 0)
> + goto out;
> +
> + ret = regulator_get_voltage_delta(rdev, min_uV);
> + if (ret < 0)
> + goto out;
> +
> + new_delta = ret;
> +
> + /* check that voltage is converging quickly enough */
> + if (new_delta - delta > rdev->constraints->max_uV_step) {
> + ret = -EWOULDBLOCK;
> + goto out;
> + }
> +
> + delta = new_delta;
> + }
> + }
Since this patch was added to -next, I have observed a boot regression
on our Tegra30 cardhu-a04 board. Bisect pointed to this commit and
reverting this does resolve the problem.
Looking at better closer at the issue, I noticed that it is the
'tps62361-vout' regulator that change is causing problem for. On boot
I see regulator_set_voltage_unlocked() called for this regulator and
min/max voltage requested is ...
regulator regulator.5: min_uV 1000000 max_uV 1350000
The min delta is 300000, but in this case the delta never reaches 0
and in fact never converges at all and so remains at 300000.
Looking at the above, if the delta never changes, then we get stuck
in the above loop forever because 'new_delta - delta' is always 0
and this is never greater than 'rdev->constraints->max_uV_step'.
There are two things that is not clear to me in the above change ...
1. Why do we 'new_delta - delta' instead of 'delta - new_delta'?
Assuming that we should converge, then I would expect that
'new_delta' should be getting smaller as we converge.
2. If difference in the delta is greater than then 'max_uV_step'
doesn't this imply that we are converging quickly?
I am wondering if we need something like ...
diff --git a/drivers/regulator/core.c b/drivers/regulator/core.c
index 8ed9b96518cf..554d83c4af0c 100644
--- a/drivers/regulator/core.c
+++ b/drivers/regulator/core.c
@@ -3884,7 +3884,7 @@ static int regulator_set_voltage_unlocked(struct regulator *regulator,
new_delta = ret;
/* check that voltage is converging quickly enough */
- if (new_delta - delta > rdev->constraints->max_uV_step) {
+ if (delta - new_delta < rdev->constraints->max_uV_step) {
ret = -EWOULDBLOCK;
goto out;
}
Jon
--
nvpublic
Powered by blists - more mailing lists