On Sun, 11 Aug 2013, Mark Brown wrote: > 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. On the surface, this seems like a particularly simple case. Why wait until the SoC's USB controller has started? Why not "plug in" the hub via the GPIOs right from the beginning? > 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. That is indeed more difficult, because it requires geniune cooperation between the bus and platform subsystems. > 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? The discussion involved some sort of pattern matching based on the device name and the bus, but nothing was ever settled. Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
