Re: [RFC PATCH 0/3] introduce: Multistate Switch Class

[Mark Brown]

On Mon, Dec 05, 2011 at 02:04:13PM +1100, NeilBrown wrote:
> On Thu, 1 Dec 2011 11:34:50 +0000 Mark Brown

> > We really want something a bit more involved in the USB frameworks for
> > the specific example of USB stuff (which is being worked on) - ideally
> > we should be communicating information about how much current the host
> > allows to be drawn throughout the system.

> Sounds like a job for the 'regulator' framework - but that is a guess based
> on not looking very deeply, so I'm probably wrong :-)

The regulator framework might be used to implement the current limits
but it understands nothing about the sematics of what it's doing, it
just understands things at the level of setting values.  Something would
need to sit above it to plug into USB.

> > I think we do want something which lets us say "this is a cable of
> > type X" so that we can report the difference between otherwise identical
> > cables as in the car/desktop dock example I mentioned above.

> I think you are saying that you might have two "cables" which connect up the
> same sets of signals but are "different" somehow.  One connects to a car,
> the other to a desk-top dock.
> How is that difference detected by the hardware?  Presumably some switch?
> So this is just one more binary switch to export to who-ever needs to know
> (presumably user-space) ???

Implementations vary - it may involve something like reading an ID chip
over some bus, for example.  It's definitely not a binary switch, it
needs to have more values than that.

> My GTA04 has a wifi chip connected to an mmc port.  The wifi chip has a
> separate regulator that can be powered up/down independently of everything
> else.
> So when I apply power I need a way to tell the mmc driver to scan the bus.
> It expects this information to come via a GPIO which has an associated IRQ.
> But I don't have a physical gpio to give it.

> So this is a case where one driver (the rfkill driver) needs to signal
> another driver (the mmc driver) to tell it that a new device has become
> available.  It hasn't been plugged in via a cable, it has be turned-on via a
> regulator, but it is conceptually very similar.

This is a very common situation.  The solution we've mostly been going
for for soldered down components is actually rather different, though -
in general it's much nicer for userspace if the device is presented as
always there rather than doing the hotplug thing and we just power it up
as needed.

Due to the existing rfkill implementations I guess the network stack is
already happy with the probe/remove model but that's not universally
true.  Even with userspace understanding things this would for example
also mean that we'd be able to keep the WiFi powered down when we just
happen not to be using it without having to use the rfkill switch.

> I wrote a virtual gpio chip which I call gpio-inout because it provides pairs
> of gpios, an output paired with an input.  When the output is changed it
> triggers an interrupt associated with the input, and the output is always
> readable by the input.

For the implementation I suggest above (which the core can't really cope
with yet but anyway) I'd be using a regulator.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/