linux-kernel - Re: (subset) [PATCH v2 0/7] Devm helpers for regulator get and enable

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <Yvp1Qkuh7xfeb/B2@sirena.org.uk>
Date:   Mon, 15 Aug 2022 17:33:06 +0100
From:   Mark Brown <broonie@...nel.org>
To:     Laurent Pinchart <laurent.pinchart@...asonboard.com>
Cc:     Matti Vaittinen <mazziesaccount@...il.com>,
        Matti Vaittinen <matti.vaittinen@...rohmeurope.com>,
        dri-devel@...ts.freedesktop.org,
        Johan Hovold <johan+linaro@...nel.org>,
        Neil Armstrong <narmstrong@...libre.com>,
        Lars-Peter Clausen <lars@...afoo.de>,
        Kevin Hilman <khilman@...libre.com>,
        linux-kernel@...r.kernel.org, Daniel Vetter <daniel@...ll.ch>,
        linux-amlogic@...ts.infradead.org,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        linux-doc@...r.kernel.org, Jonathan Cameron <jic23@...nel.org>,
        Andy Shevchenko <andriy.shevchenko@...ux.intel.com>,
        Liam Girdwood <lgirdwood@...il.com>,
        Michael Hennerich <Michael.Hennerich@...log.com>,
        Miaoqian Lin <linmq006@...il.com>,
        linux-arm-kernel@...ts.infradead.org,
        Alexandru Tachici <alexandru.tachici@...log.com>,
        Jerome Brunet <jbrunet@...libre.com>,
        Andrzej Hajda <andrzej.hajda@...el.com>,
        Jonathan Corbet <corbet@....net>,
        Guenter Roeck <linux@...ck-us.net>,
        Jonas Karlman <jonas@...boo.se>,
        Stephen Boyd <sboyd@...nel.org>,
        Lorenzo Bianconi <lorenzo@...nel.org>,
        Michael Turquette <mturquette@...libre.com>,
        Jernej Skrabec <jernej.skrabec@...il.com>,
        Martin Blumenstingl <martin.blumenstingl@...glemail.com>,
        Jean Delvare <jdelvare@...e.com>,
        Alexandru Ardelean <aardelean@...iqon.com>,
        linux-hwmon@...r.kernel.org, linux-clk@...r.kernel.org,
        Nuno Sá <nuno.sa@...log.com>,
        Robert Foss <robert.foss@...aro.org>,
        Aswath Govindraju <a-govindraju@...com>,
        David Airlie <airlied@...ux.ie>, linux-iio@...r.kernel.org
Subject: Re: (subset) [PATCH v2 0/7] Devm helpers for regulator get and enable

On Mon, Aug 15, 2022 at 06:54:45PM +0300, Laurent Pinchart wrote:

> - With devres, you don't have full control over the order in which
>   resources will be released, which means that you can't control the
>   power off sequence, in particular if it needs to be sequenced with
>   GPIOs and clocks. That's not a concern for all drivers, but this API
>   will creep in in places where it shouldn't be used, driver authours
>   should really pay attention to power management and not live with the
>   false impression that everything will be handled automatically for
>   them. In the worst cases, an incorrect power off sequence could lead
>   to hardware damage.

I basically agree with these concerns which is why I was only happy with
this API when Matti suggested doing it in a way that meant that the
callers are unable to access the regulator at runtime, this means that
if anyone wants to do any kind of management of the power state outside
of probe and remove they are forced to convert to the full fat APIs.
The general ordering concern with devm is that the free happens too late
but for the most part this isn't such a concern with regulators, they
might have delayed power off anyway due to sharing - it's no worse than
memory allocation AFAICT.  Given all the other APIs using devm it's
probably going to end up fixing some bugs.

For sequencing I'm not convinced it's much worse than the bulk API is
anyway, and practically speaking I expect most devices that have
problems here will also need more control over power anyway - it's
certainly the common case that hardware has pretty basic requirements
and is fairly tolerant.

> - Powering regulators on at probe time and leaving them on is a very bad
>   practice from a power management point of view, and should really be
>   discouraged. Adding convenience helpers to make this easy is the wrong
>   message, we should instead push driver authors to implement proper
>   runtime PM.

The stick simply isn't working here as far as I can see.

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