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

Message-ID: <20131031155946.1890db5a@notabene.brown>
Date:	Thu, 31 Oct 2013 15:59:46 +1100
From:	NeilBrown <neilb@...e.de>
To:	Mark Brown <broonie@...nel.org>
Cc:	Alex Courbot <acourbot@...dia.com>,
	"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 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.

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?

NeilBrown

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