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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <YvrDp32/TknqV05t@sirena.org.uk>
Date:   Mon, 15 Aug 2022 23:07:35 +0100
From:   Mark Brown <broonie@...nel.org>
To:     Stephen Boyd <sboyd@...nel.org>
Cc:     Laurent Pinchart <laurent.pinchart@...asonboard.com>,
        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>,
        Lorenzo Bianconi <lorenzo@...nel.org>,
        Michael Turq uette <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 01:58:55PM -0700, Stephen Boyd wrote:
> Quoting Laurent Pinchart (2022-08-15 11:52:36)
> > On Mon, Aug 15, 2022 at 05:33:06PM +0100, Mark Brown wrote:
> > > 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 think the main issue is that platform drivers are being asked to do
> too much. We've put the burden on platform driver authors to intimately
> understand how their devices are integrated, and as we all know they're

This is for the regulator API, it's mainly for off SoC devices so it's
not a question of understanding the integration of a device into a piece
of silicon, it's a question of understanding the integration of a chip
into a board which seems reasonably in scope for a chip driver and is
certainly the sort of thing that you'd be talking to your customers
about as a silicon vendor.

> The basic idea is that drivers should be focused on what they're
> driving, not navigating the (sometimes) complex integration that's
> taking place around them. When a device driver probe function is called
> the device should already be powered on. When the driver is
> removed/unbound, the power should be removed after the driver's remove
> function is called. We're only going to be able to solve the power
> sequencing and ordering problem by taking away power control and
> sequencing from drivers.

That is a sensible approach for most on SoC things but for something
shipped as a separate driver there's little point in separating the
power and clocking domain driver from the device since there's typically
a 1:1 mapping.  Usually either it's extremely simple (eg, turn
everything on and remove reset) but some devices really need to manage
things.  There's obviously some edge cases in SoC integration as well
(eg, the need to manage card supplies for SD controllers, or knowing
exact clock rates for things like audio controllers) so you need some
flex.

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