linux-kernel - Re: [PATCH 4/6] regulator: core: Add external-output support

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: <YnJ6Pbmv9G3cy62n@sirena.org.uk>
Date:   Wed, 4 May 2022 14:06:05 +0100
From:   Mark Brown <broonie@...nel.org>
To:     Zev Weiss <zev@...ilderbeest.net>
Cc:     Liam Girdwood <lgirdwood@...il.com>, linux-kernel@...r.kernel.org,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        openbmc@...ts.ozlabs.org
Subject: Re: [PATCH 4/6] regulator: core: Add external-output support

On Tue, May 03, 2022 at 11:52:50PM -0700, Zev Weiss wrote:
> Regulators feeding external outputs (i.e. supplying devices we don't
> control) can be switched on and off by userspace via the 'state' sysfs
> attribute, which is now (conditionally) writable.  They are also not
> automatically disabled in regulator_late_cleanup(), since we have no
> way of knowing that they're not actually in use.

No, this is an abstraction failure.  Enabling and disabling a regulator
is something that should be handled in consumer drivers, just as with
every other use case there's no reason why the regulator should be
offering direct control to userspace.  Putting this directly in the
regulator will cause problems as soon as you for example have multiple
outputs supplied from a single regulator and can't be integrated with
any other control mechanisms.

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