linux-kernel - Re: [REPOST RFC PATCH 0/3] New "gpio-poweroff" driver to turn off platform devices with GPIOs

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: <B187B965-8671-485E-9CAB-7CF3468D2ED6@boeing.com>
Date:	Mon, 19 Dec 2011 19:53:06 -0600
From:	"Moffett, Kyle D" <Kyle.D.Moffett@...ing.com>
To:	Mark Brown <broonie@...nsource.wolfsonmicro.com>
CC:	Rob Herring <robherring2@...il.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"devicetree-discuss@...ts.ozlabs.org" 
	<devicetree-discuss@...ts.ozlabs.org>, Liam Girdwood <lrg@...com>,
	Grant Likely <grant.likely@...retlab.ca>
Subject: Re: [REPOST RFC PATCH 0/3] New "gpio-poweroff" driver to turn off
 platform devices with GPIOs

On Dec 19, 2011, at 20:38, Mark Brown wrote:
> On Mon, Dec 19, 2011 at 10:56:41AM -0600, Moffett, Kyle D wrote:
>> I still don't understand how the regulator API is supposed to help in my
>> particular case (whole-system poweroff).
> 
> Well, it depends what you need to do.  In the ST-Ericsson case what they
> needed to do was collapse the core supplies for the CPU.  But previously
> you were talking about power domains, not whole system poweroff.
> Usually a power domain is a subset of the full system power.

Well, I have control of 3 separate power domains in the sense that
there are 6 physically separate computers sharing a single supply,
with 2 in each domain (and only 1 of the 6 controlling the shared
supply).

Obviously when the 'control computer' goes off the GPIOs will
fluctuate wildly, so the power supply only responds to the GPIOs as
a signal to cut power, not to re-enable it.  The system is designed
to require user intervention to resupply power after it has shut
itself down.

So I do have separate power domains, but in this particular
hardware build I simply want to shut them all down in a fixed order
(due to the specific arrangement of power supply connections).

Previously I had about 200 lines of code in my machine_poweroff
hook to walk a list of GPIOs in the device tree and turn them all
off in a fixed order.  After looking at that a while I decided it
would be better off as a pseudo-generic driver that could be used
by any DT platform with a GPIO used to shut down system power.

I ended up with the "gpio-poweroff" driver which also makes the
time delays configurable.

Since I noticed that platform_drv also has a device-specific
poweroff hook, I added a boolean DT value to switch between
powering down at machine_poweroff() time and powering down during
the device->poweroff() walk.

I realize that this driver is basically incapable of any kind of
runtime power management but it could be used on X86 platforms
that convert to device-tree.  In particular ones with embedded
controllers and BMC devices would otherwise be using ACPI device
methods to poke a few GPIOs in basically the same fashion.

The benefit is that instead of ACPI AML (bytecode poking magic
IO registers at some undocumented address) you have a standard
GPIO driver and a piece of pseudo-self-documenting device-tree
that basically says "the HW engineers set it up so you set these
GPIOs in that order and it turns off".

Make sense?

Cheers,
Kyle Moffett

--
Curious about my work on the Debian powerpcspe port?
I'm keeping a blog here: http://pureperl.blogspot.com/

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/