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: <20131029161816.GE16686@sirena.org.uk>
Date:	Tue, 29 Oct 2013 09:18:16 -0700
From:	Mark Brown <broonie@...nel.org>
To:	NeilBrown <neilb@...e.de>
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, 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.

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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ