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: <eyfec4jzcw3japf77jzj3p6w7gytbmogr2ff3g2677nn6qivpe@57huhelwllhd>
Date: Fri, 22 Dec 2023 11:27:23 +0100
From: Uwe Kleine-König <u.kleine-koenig@...gutronix.de>
To: Martin Blumenstingl <martin.blumenstingl@...glemail.com>
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

On Fri, Dec 22, 2023 at 11:12:30AM +0100, Martin Blumenstingl wrote:
> 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.

That can go in together with the

	if (pstate.enabled)
		return -ENOTRECOVERABLE;

Otherwise +1 to not mix that with the machine specfic stuff.

Best regards
Uwe

-- 
Pengutronix e.K.                           | Uwe Kleine-König            |
Industrial Linux Solutions                 | https://www.pengutronix.de/ |

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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ