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-next>] [day] [month] [year] [list]
Date:   Fri, 21 Apr 2023 11:13:05 +0200
From:   Benjamin Bara <bbara93@...il.com>
To:     Liam Girdwood <lgirdwood@...il.com>,
        Mark Brown <broonie@...nel.org>, support.opensource@...semi.com
Cc:     DLG-Adam.Ward.opensource@...renesas.com,
        linux-kernel@...r.kernel.org,
        Matti Vaittinen <mazziesaccount@...il.com>,
        Benjamin Bara <benjamin.bara@...data.com>
Subject: [PATCH RFC v2 0/2] regulator: dynamic voltage monitoring support

Hi!

This series targets the "automatic" state handling of voltage monitors
when the state of the monitored regulator is changed. This is e.g.
necessary for the da9063, which reaches an invalid state (!PWR_OK) if
the voltage monitor is not disabled before the regulator is disabled.
The problem could also be tackled inside of the driver's "state change
ops" (.enable(), .disable(), ...) but I thought it might be a good idea
to have a "common framework" independent of the driver's implementation.

For now, 1/2 adds "disable monitor properties" to the regulator's desc,
which indicate on which actions the monitors should be disabled.
2/2 depends on [1], which implements (static) voltage monitoring for the
da9063. It disables the monitors while the regulator is disabled.

The monitors are only enabled after the ramp-delay, to ensure that the
regulator is already in a valid state.

Possible next step:
"regulators-{uv,ov}-{warn,error,protection}-enable" dt property on chip
level, with either 1 or 0, to en-/disable the dynamic voltage monitoring
for every regulator of the chip. This would require the regulator's
set_{over,under}_voltage_protection() to work with limit = 1.

I added some TODOs (basically about error handling) and still have to do
some testing, but I wanted to share the "direction" of this series,
therefore the v2. Thank you, Mark and Matti, for the input!

Thanks & best regards,
Benjamin

[1] https://lore.kernel.org/all/20230403-da9063-disable-unused-v3-0-cc4dc698864c@skidata.com/

---
Changes in v2:
1/2:
- move from board-specific (machine.h) to driver-specific (driver.h)
- move from own struct to fields/properties in regulator_desc
- handle modes as one "unsupported modes" field
- factor out new monitors_set_state() to handle all (activated) monitors
- move re-enabling of monitor after ramp-delay
- add TODOs for error handling when the action fails (return error from
  actual action instead, return state of monitoring to pre-action).
- reword commit message
2/2:
- adapting change to the properties approach

Link to v1: https://lore.kernel.org/r/20230419-dynamic-vmon-v1-0-f48b7438e891@skidata.com

---
Benjamin Bara (2):
      regulator: add properties to disable monitoring on actions
      regulator: da9063: disable monitoring while regulator is off

 drivers/regulator/core.c             | 64 ++++++++++++++++++++++++++++++++----
 drivers/regulator/da9063-regulator.c |  2 ++
 include/linux/regulator/driver.h     | 10 ++++++
 3 files changed, 70 insertions(+), 6 deletions(-)
---
base-commit: 6a8f57ae2eb07ab39a6f0ccad60c760743051026
change-id: 20230419-dynamic-vmon-e08daa0ac7ad

Best regards,
-- 
Benjamin Bara <benjamin.bara@...data.com>

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ