linux-kernel - Re: [PATCH 0/1] pwm-regulator with voltage table problem

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: <Zmd2a0Etz3elXFID@finisterre.sirena.org.uk>
Date: Mon, 10 Jun 2024 22:55:55 +0100
From: Mark Brown <broonie@...nel.org>
To: George Stark <gnstark@...utedevices.com>
Cc: lgirdwood@...il.com, linux-arm-kernel@...ts.infradead.org,
	linux-kernel@...r.kernel.org, kernel@...utedevices.com
Subject: Re: [PATCH 0/1] pwm-regulator with voltage table problem

On Tue, Jun 11, 2024 at 12:33:42AM +0300, George Stark wrote:

> Actually we did a similar thing - we modified voltage table adding
> duty-cycle that was set by bootloader with fractional voltage value that is
> not used in opp table - just to make pwm-regulator happy.
> But this issue was very hard to find. Due to deviations of hardware
> component's characteristics some devices managed to keep working with
> minimal voltage till cpu opp driver got probed and appropriate voltage is
> restored. Other devices got stuck at different places with random errors.

I think the diagnostics you are looking for here are in the PWM
regulator driver.  The core does announce that it's bringing the voltage
into range when it does it so there's a hint that the voltage got
changed there.

> Of course such a behavior should be configurable. At the other hand it may
> be too much changes for a corner case that's why I proposed only a
> warning patch just to simplify detecting the problem.

> Actually we already have a hint that says voltage is reset:
> rdev_info(rdev, "Setting %d-%duV\n",
> 				  rdev->constraints->min_uV,
> 				  rdev->constraints->max_uV);
> but there's no indication this is due to regulator device  error.

The issue is that it may not be an error, it may be normal operation -
there are some regulators (those for some of the Qualcomm firmware
controlled devices for example) which are purely write only so we've got
no way to tell what the current configuration is and always need to
write out what we want during startup.

> Should I consider adding my warning only for "system-critical-regulator"
> regulators (cpu power regulator is critical indeed)? Although this property
> is never used in mainline bindings.

To the extent that it's an issue it's going to depend on the specific
regulator, the driver for a given regulator is best placed to know if
being able to read back from the hardware is expected and if it should
complain about not being able to.

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