linux-kernel - Re: Any news on Runtime Interpreted Power Sequences

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] [day] [month] [year] [list]

Date:	Thu, 31 Oct 2013 14:23:05 +0900
From:	Alex Courbot <acourbot@...dia.com>
To:	NeilBrown <neilb@...e.de>, Mark Brown <broonie@...nel.org>
CC:	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Thierry Reding <thierry.reding@...onic-design.de>,
	"linux-pm@...r.kernel.org" <linux-pm@...r.kernel.org>
Subject: Re: Any news on Runtime Interpreted Power Sequences

On 10/31/2013 01:59 PM, NeilBrown wrote:
> * PGP Signed by an unknown key
>
> On Tue, 29 Oct 2013 09:18:16 -0700 Mark Brown <broonie@...nel.org> wrote:
>
>> On Tue, Oct 29, 2013 at 11:10:37AM +1100, NeilBrown wrote:
>>
>>> Yes, the device is soldered down and has a reset line that needs to be pulsed
>>> low at about the same time that the MMC port enables the regulator.
>>
>>> How do you propose that I describe this?  Which driver should know about the
>>> reset GPIO, how to I tell it about the GPIO, and which function should do the
>>> pulsing?
>>
>> I'd expect the driver for the device to know about this, obviously
>> depending on what this actually does it might want to use this at
>> runtime (for example, putting the device into reset to minimise power
>> while it's idle).  We really need a generic way for devices such as this
>> on enumerable buses to run before the current probe() in order to allow
>> them to manage their power up sequences in embedded systems, this is
>> *far* from a unique situation.
>
> I agree.
> To me, this sounds a lot like saying "We need a way for enumerable buses to
> be given a power-on-sequence to power on the attached device".  That is what
> I hopped RIPS would provide.

There are a few ad-hoc solutions that provide such a mechanism using 
platform data. Take for instance 
include/linux/platform_data/brcmfmac-sdio.h. It allows you to register a 
platform device which sole purpose is to control the power sequence of a 
SDIO network device. When the platform device is registered, it powers 
the network device which can then be probed by the bus. The network 
driver also calls the platform power on/off functions when appropriate.

This works quite well in the case of board files where you can write 
power sequencing code freely, but the question is how to translate it to 
device tree. You need to translate several, board-specific (and not 
device-specific) functions. Here I have to admit this seems like a good 
fit for in-DT power sequences.

> Maybe various devices could allow other devices to register for call-backs
> when the first device activates or deactivates a port  (whether an MMC port or
> USB or Serial or whatever).
> Then a driver that needs to control the power-on sequence would register as a
> platform-device which registers a call-back with the appropriate parent and
> performs the required power-on/off.
>
> Does that sound like the right sort of thing?

I think it does, but you are still left with the problem of how and 
where to define that board-specific power sequence. If things were 
always as simple as turning a regulator on, this would be easy, but 
apparently we also face more complex cases.

Alex.

--
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/