linux-kernel - Re: [PATCH 0/7] Implement generic regulator constraints parsing for ACPI and OF

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: <20170125220558.GB36291@dtor-ws>
Date:   Wed, 25 Jan 2017 14:05:58 -0800
From:   Dmitry Torokhov <dmitry.torokhov@...il.com>
To:     Mark Brown <broonie@...nel.org>
Cc:     Mark Rutland <mark.rutland@....com>,
        Furquan Shaikh <furquan@...omium.org>,
        "Rafael J. Wysocki" <rafael@...nel.org>,
        "Rafael J . Wysocki" <rjw@...ysocki.net>,
        Liam Girdwood <lgirdwood@...il.com>,
        Tony Lindgren <tony@...mide.com>, Len Brown <lenb@...nel.org>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Lorenzo Pieralisi <lorenzo.pieralisi@....com>,
        Hanjun Guo <hanjun.guo@...aro.org>,
        Will Deacon <will.deacon@....com>,
        Rob Herring <robh@...nel.org>,
        Sathyanarayana Nujella <sathyanarayana.nujella@...el.com>,
        Heikki Krogerus <heikki.krogerus@...ux.intel.com>,
        Adam Thomson <Adam.Thomson.Opensource@...semi.com>,
        Linus Walleij <linus.walleij@...aro.org>,
        Alexandre Courbot <gnurou@...il.com>,
        linux-gpio@...r.kernel.org,
        ACPI Devel Maling List <linux-acpi@...r.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Linux OMAP Mailing List <linux-omap@...r.kernel.org>,
        Aaron Durbin <adurbin@...omium.org>, dlaurie@...omium.org
Subject: Re: [PATCH 0/7] Implement generic regulator constraints parsing for
 ACPI and OF

On Wed, Jan 25, 2017 at 09:30:40PM +0000, Mark Brown wrote:
> On Wed, Jan 25, 2017 at 01:17:14PM -0800, Dmitry Torokhov wrote:
> > On Wed, Jan 25, 2017 at 08:39:07PM +0000, Mark Brown wrote:
> 
> > > That's *not* a sensible thing for drivers to assume regardless of the
> > > presence or absence of explicitly controlled regulators, that just seems
> > > like a plain old driver bug.  Even if there are regulators that doesn't
> > > mean there isn't a suspend mode configuration that disables those
> > > regulators.
> 
> > That means your platform description is incomplete, AKA a plain old
> > device tree bug.
> 
> What makes you say that?  Like I say even with an explicitly described
> regulator we might power it off during suspend (perhaps even through
> explicit device tree configuration).
> 
> > > That's not an ACPI thing, unless the device thinks it's actively
> > > providing a wakeup source then if the system suspends the driver should
> > > not be surprised to have power pulled - that's pretty normal.  If the
> > > driver is a wakeup source then it's a bit different.
> 
> > From the practical standpoint many drivers make this assumption because
> > this shortens resume time for device. I.e. it makes difference whether
> > we go through full controller reset, possibly reloading firmware, and
> > applying desired configuration, versus taking the chip out of deep sleep
> > mode.
> 
> Really?  They've been used on a limited set of systems and if they're
> attempting to use the presence of a regulator to figure out if this is
> going to happen they are just completely broken in this regard and need
> to be fixed before anyone copies that code.  Even ignoring the suspend
> mode configuration dummy regulators mean such a check would return true
> in essentially all systems.

I think many of them do not use regulators and just expect the power not
be cut off. Or use regulator + reset gpio combo to make the decision.
For example, we actually keying the need of doing power sequence in Elan
touchscreen driver off presence of GPIO because having GPIO is essential
in implementing required sequence.

> 
> > So if we indeed saying that drivers should expect handling power loss
> > even when devices are not on a hot-pluggable buses then we need a
> > generic API for querying whether device lost it's state or not.
> 
> Yes.  Querying the suspend mode configuration would be one way to do it
> already.

Suspend mode of what though? Regulator? I would not mind cleaning up at
least some of the drivers if we had a generic API for doing such
query... Would it be something like:

	bool device_has_lost_state(struct device *dev,
				   struct regulator *supplies)

with DT systems going strictly off regulator data and ACPI throwing
its internal state in the mix?

Or you meant something else?

-- 
Dmitry