linux-kernel - Re: [PATCH RFC 1/2] regulator: introduce regulator monitoring constraints

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: <3eb854e2-8631-4f4e-aa00-d06236967f54@sirena.org.uk>
Date:   Thu, 20 Apr 2023 13:17:09 +0100
From:   Mark Brown <broonie@...nel.org>
To:     Benjamin Bara <bbara93@...il.com>
Cc:     Liam Girdwood <lgirdwood@...il.com>,
        support.opensource@...semi.com,
        DLG-Adam.Ward.opensource@...renesas.com,
        linux-kernel@...r.kernel.org,
        Matti Vaittinen <mazziesaccount@...il.com>,
        Benjamin Bara <benjamin.bara@...data.com>
Subject: Re: [PATCH RFC 1/2] regulator: introduce regulator monitoring
 constraints

On Thu, Apr 20, 2023 at 12:29:20PM +0200, Benjamin Bara wrote:

> Add constraints for regulator monitoring. These are useful when the
> state of the regulator might change during runtime, but the monitor
> state (in hardware) is not implicitly changed with the change of the
> regulator state or mode (in hardware).

> When used, the core takes care of handling the monitor state. This could
> ensure that a monitor does not stay active when its regulator is
> disabled.

Are these constraints (ie, board specific limits) or are these more just
properties of the regulator device?  It does feel useful to factor out
this stuff, but it's not clear to me that these are things that should
be configured on a per board basis. 

> + * @mon_disable_during_reg_set: Monitor should be disabled before and enabled after the regulators'
> + *                              value is changed
> + * @mon_disable_during_reg_off: Monitor should be disabled before a regulator disable and enabled
> + *                              after a regulator enable

> + * @mon_disable_pre_reg_idle: Monitor should be disabled before a switch to MODE_IDLE
> + * @mon_disable_pre_reg_standby: Monitor should be disabled before a switch to MODE_STANDBY
> + * @mon_enable_post_reg_normal: Monitor should be enabled after a switch to MODE_NORMAL
> + * @mon_enable_post_reg_fast: Monitor should be enabled after a switch to MODE_FAST

These all sound like things where the regulator device is simply not
going to support having monitoring enabled when doing the relevant
actions no matter what situation we're in.  If that's the case we should
just have the regulator driver set things up.

For the modes might it be clearer to mark a set of modes as not
supporting monitoring?  I think that's the intended effect here.

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