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]
Date: Fri, 22 Dec 2023 11:12:30 +0100
From: Martin Blumenstingl <martin.blumenstingl@...glemail.com>
To: Uwe Kleine-König <u.kleine-koenig@...gutronix.de>
Cc: lgirdwood@...il.com, broonie@...nel.org, linux-pwm@...r.kernel.org, 
	linux-amlogic@...ts.infradead.org, linux-kernel@...r.kernel.org, 
	Thierry Reding <thierry.reding@...il.com>, Heiner Kallweit <hkallweit1@...il.com>, 
	Dmitry Rokosov <ddrokosov@...rdevices.ru>
Subject: Re: [RFC PATCH v1] regulator: pwm-regulator: Fix continuous
 get_voltage for disabled PWM

Hello Uwe,

On Fri, Dec 22, 2023 at 8:10 AM Uwe Kleine-König
<u.kleine-koenig@...gutronix.de> wrote:
[...]
> Also the calculation is wrong: If a relative duty-cyle in the interval
> [91%; 0%] maps lineary to [860 mV; 1140 mV] you get 1100 mV at
>
>              1100 mV - 860 mV
>         91 + ---------------- * (0 - 91) = 13
>              1140 mV - 860 mV
>
> (If the calculations in the driver used signed multiplication and
> division, all the checks for max_uV_duty < min_uV_duty could just go
> away.)
>
> So you want
>
> +               pwm-dutycycle-range = <13 0>;
Thank you!

> (if this restriction is really necessary).
I could not find a way around this.
Without this change pwm_regulator_set_voltage() is called with req_min
860mV and req_max 1140mV.
pwm_regulator_set_voltage() will then pick the lowest possible
voltage, which then results in 860mV (exactly what I get without any
patches).

To be able to keep the original minimum voltage in .dts would be to
work on what Mark suggested where he said:
"I'd expect a change in the init_state() function, possibly one that
programs the PWM to reflect the actual hardware state"

[...]
> > -     if (pstate.enabled)
> > -             voltage = pwm_get_relative_duty_cycle(&pstate, duty_unit);
> > -     else if (max_uV_duty < min_uV_duty)
> > -             voltage = max_uV_duty;
> > -     else
> > -             voltage = min_uV_duty;
> > +     voltage = pwm_get_relative_duty_cycle(&pstate, duty_unit);
>
> I'd add here:
>
>         if (voltage < min(max_uV_duty, min_uV_duty) ||
>             voltage > max(max_uV_duty, min_uV_duty))
>                 return -ENOTRECOVERABLE;
I can do that - although I think it should be a separate change.


Best regards,
Martin

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ