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: <E30C4693-0D31-4A9A-9E9D-0FC03C5F6B8A@boeing.com>
Date:	Wed, 14 Dec 2011 14:34:37 -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 14, 2011, at 07:02, Mark Brown wrote:
> On Tue, Dec 13, 2011 at 02:44:48PM -0600, Moffett, Kyle D wrote:
>> I looked at it a bit when I was generalizing my code, but it seemed
>> dramatically more complicated than I needed, and I couldn't see any
>> reasonable way to hook it from the machine_poweroff() code.
> 
> Some ST platform had to do odd stuff with regulators to power off, it
> made a platform device representing the odd poweroff code.

This is actually what I did originally, albeit with GPIOs.

In our case we have a chassis with 6 computers in it, and one of the
computers has 3 GPIOs which are wired to the "off" signal for each domain
(one domain per pair of computers).

Due to isolation requirements, that computer can't turn the domains back
on from software, so really all we need to be able to do is trigger each
GPIO in sequence as part of the poweroff.

So basically the "gpio-poweroff" driver was just a slightly-more-generic
way of doing what I was doing before, by looking up the GPIOs in the
device-tree.


>> There's also the fact that I was looking for a pure-device-tree type
>> of driver and the regulator framework does not seem to support the
>> standard OF-platform probe system.
> 
> The regulator API in -next has DT bindings.

Based on the description of our hardware, is there a good way that I
can wire up gpio-regulator driver to our hardware with just the device
tree (and maybe one small board-specific function) to make it shut down
each domain in sequence at poweroff time? Otherwise I will just go back
to my custom board-specific function for GPIO-twiddling.

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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ