Re: Non-enumerable devices on USB and other enumerable buses

[Mark Brown]

On Mon, Aug 12, 2013 at 01:50:07PM -0700, Greg Kroah-Hartman wrote:
> On Mon, Aug 12, 2013 at 12:23:44PM +0100, Mark Brown wrote:

> > I don't think they're bus specific - the main issue with a lot of this
> > is that they're outside the infrastructure that the bus standardises so
> > we should have a general way of understanding this.  There will be bits
> > where the bus needs to get involved but the overall pattern is generic.

> The "pattern" is generic, yes, we've been dealing with that for well
> over a decade now (pci hotplug controllers are "out of line" and control
> when/if a PCI is device is added/removed.)

> I'd argue that each bus needs special logic to handle this, just like
> PCI hotplug did it with their hotplug controller logic.  Due to the
> nature of this type of thing, it's all out-of-line hardware that is
> custom to each device type / bus.

I agree that the bus will need some logic to handle this and I also
think Stephen is right that there are going to be some common patterns
for some device classes.  However I do think that this is a common
problem for pretty much all buses so we should be factoring out as much
as possible from the buses so they only have to deal with their bit of
things.  Most of the stuff that's worrying me is not anything the bus
should have any idea about beyond tunnelling the data to the device.

> > This doesn't work in general.  These things aren't really platform
> > specific at all, they're features of the devices that apply to any
> > system using them and while for some use cases (like WiFi and BT power)
> > an external thing that just manually applies power will be enough in
> > other cases we want to know about the device even while it's off and the
> > driver might be able to do extra things at runtime if it knows about for
> > example having some control over signals to the device.

> No, the device isn't platform specific, but the logic needed to turn
> on/off is platform specific, otherwise the device would "just work"
> properly as the bus is self-discoverable.

> Much like rfkill is, as you point out.  Those are all platform specific.

This is not just about power control - that's one of the simpler
applications but you're talking about essentially anything that might be
handled by platform data (or by the configuration SEPROMs on a
freestanding device for that matter, why would you put down an extra
part to configure the device when you can just load things from the AP).

> > For example in the Slimbus case we're normally talking about audio
> > CODECs.  In order to preserve the userspace API the device has to appear
> > to be present at all times, the driver will remember the settings the
> > user is making to be applied when it actually powers up and indeed the
> > powering up should be kicked off as a result of userspac acting on the
> > apparently present device.

> That's some horrible hardware, who thought of that?

It's actually pretty nice hardware in many regards; the bus is a bit
underspecified for maximum bandwidth in modern systems but it gives you
standardised multi-drop data streaming over two wires muxed with control
which helps with the pin counts and with simplifying the system hardware
design.

The disappearing from the bus thing is because you're aiming to hit low
power idle (but still functioning) states consuming very small numbers
of microamps, even having a clock running is measurable.

> > > Perhaps a semi-generic "platform" driver could be created, that knows
> > > how to handle these settings in the DT, but odds are, that might be
> > > difficult to make generic enough to cover a wide range of boards, but
> > > without specifics, it's hard to tell.

> > There's things like the rfkill stuff already, and the reset controller
> > on the way, but again this only covers a fairly small subset of the
> > issues.

> "small subset"?  How common is this type of thing?

Well, for Slimbus it's absolutely the norm, I've never seen a Slimbus
device that didn't have a need for platform data.  The small subset
there is of the problems rather than the devices - you'll cover a large
set of devices with a common helper like rfkill but trying to handle
everything with that pattern doesn't seem like it'll work.

Attachment: signature.asc
Description: Digital signature