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

[NeilBrown <neilb@suse.de>]

[-- Attachment #1: Type: text/plain, Size: 5244 bytes --]

On Mon, 5 Dec 2011 12:06:08 +0000 Mark Brown
<broonie@opensource.wolfsonmicro.com> wrote:

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

Ahh..
So to try to restate the requirements:

 A "cable-port" can detect when a "cable" in inserted (or removed) and can
 determine the "cable-type" which comprises:
   - a "cable-name" which is an arbitrary label interpreted in the context of
     the particular port
   - 1 or more "cable-function" flags which indicate what functions the 
     cable support.  A given port has a fixed set of "cable-functions" and 
     for any given cable it will report true/false (present/absent, on/off)
     for each cable-function.

 This full "cable-type" needs to be presented to user-space, and individual
 cable-functions may need to be communicated to specific drivers to trigger a
 'probe' function.

Questions:
  1/ Do we need to communicate anything to drivers apart from "cable-detect"?
     i.e. are they quite cable of probing and identifying, or do they need to
     be told what to look for?
  2/ Does it hurt to simply wake up all drivers that might be listening on
     the cable or do we need individual wake-ups (notifiers) for each
     cable-function?
  3/ Does anything in the kernel care about the cable-name, or is that only
     interesting to user-space?

I think that the "cable-functions" might still be best represented by virtual
GPIOs, but the cable-name is certainly more than that.

To me this does sound like it might want a 'cable-port' device and it should
generate 'change' uevents when a new cable appears.  The change from no-cable
to cable-X does seem quite a significant change affecting possible multiple
subsystems so a uevent seems to me to be justified.


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

Brilliant!  That might solve another related problem I've been having.  Time
to learn even more about regulators.

Thanks,
NeilBrown

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 828 bytes --]