On Tue, 5 May 2009, Oliver Neukum wrote: > This is not quite so simple. If you hand over a port, you cause problems. > That doesn't mean you shouldn't do it, but you have to solve the problems. > Immediately I can think of: > > - overcurrent events > - the power budget > - how to reset a hub > - how to suspend/resume a hub > - how to react to the hub whose port you've claimed being unplugged > > Note that these problems (except for the power budget) must be handled > in kernel space or we can deadlock due to the storage driver. > Thus you must write a real "device level" usb driver and implement > the necessary methods. Or possibly even several "device level" > drivers. These aren't issues, at least no more than they are now. The hub driver will continue to control the port as usual. The only difference is that the generic driver won't automatically configure a new device plugged into the port, no other process will be allowed to access the usbfs device file, write access to the bConfigurationValue attribute will be denied, and all interfaces in the device will automatically be bound to usbfs. 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
