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: <90c4c45b-daae-4f38-a60c-6bb8d33c025d@sirena.org.uk>
Date:   Thu, 20 Apr 2023 15:37:38 +0100
From:   Mark Brown <broonie@...nel.org>
To:     Benjamin Bara <bbara93@...il.com>
Cc:     DLG-Adam.Ward.opensource@...renesas.com, benjamin.bara@...data.com,
        lgirdwood@...il.com, linux-kernel@...r.kernel.org,
        mazziesaccount@...il.com, support.opensource@...semi.com
Subject: Re: [PATCH RFC 1/2] regulator: introduce regulator monitoring
 constraints

On Thu, Apr 20, 2023 at 04:30:45PM +0200, Benjamin Bara wrote:
> On Thu, 20 Apr 2023 at 14:17, Mark Brown <broonie@...nel.org> wrote:

> > 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.

> These are actually properties of the regulator device. However, the
> properties are only "active" if the voltage monitoring is wanted, which
> is currently a per-board decision. Not sure if there might be reasons to
> not activate it.

Right, but in any case where the monitoring is enabled then these
properties would also be needed so there's no point in separately
configuring it.

> > 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.

> I think this would be feasible if the driver decides whether monitoring
> is on or off (which might be a way to go). I think if the decision is
> done per-board, it might simplify things to have the whole "should I
> turn the monitor off now?" overhead not duplicated in every driver that
> supports monitoring. What do you think?

The driver can supply flags to tell the core to do things like it
already does for a whole range of other things, there's no need to force
things to be configured per system in order to factor things out.  It's
just a question of where the core gets information from.

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