Non-enumerable devices on USB and other enumerable buses

From: Mark Brown
Date: Sun Aug 11 2013 - 15:08:53 EST


Looking at the enumerable buses in the kernel I don't see any which have
real support for any kind of registration of devices prior to their
enumeration. Similarly currently all the DT bindings in the kernel I've
been able to notice cover only non-enumerable buses. This generally
makes sense where enumerable buses are used in standard fashions since
the binding would be at best redundant and at worst inaccurate. However
there are often corner cases in embedded systems where hardware has been
hooked up outside of the normal enumeration mechanisms, for example with
software power control or extra signals wired.

One example that's bugging me right now is that on the Insignal Arndale
platform there's a USB hub connected to one of the USB ports on the SoC
(not as a PHY, it seems we also need the internal PHY running to talk to
the device). The hub needs to be "plugged" into the SoC after the SoC
USB controller has started with some GPIOs so we need to tell the system
that the hub exists and needs to be synchronised with the USB controller.

Another case that's going to be problematic once it's in mainline is
Slimbus - this is a bus used in some embedded audio subsystems which is
enumerable in a similar manner to USB but where the devices on the bus
are normally powered up only on demand (causing them to hotplug when
used and unplug when idle) and have at least interrupt lines wired to
the SoC using a normal interrupt outside the enumerable bus.

I know there's been some discussion of this topic but do we have any
general consensus on how to handle such things both from a Linux driver
model point of view and from a DT/ACPI point of view?

Attachment: signature.asc
Description: Digital signature