On Tue, 29 Oct 2013 09:18:16 -0700 Mark Brown <broo...@kernel.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
signature.asc
Description: PGP signature
