On Wed, 22 Feb 2012, Sarah Sharp wrote: > > New drivers are bound in usb_probe_interface. There's also > > usb_driver_claim_interface, but with the exception of usbfs, it gets > > called only by drivers that are already bound to another interface on > > the same device. > > So usb_probe_device is called when a new device is connected? And then > it will call the driver probe function, which happens to be > usb_probe_interface? I think I'll have to go look more closely at this > code. Is there any documentation about the USB device probe flow? I think I'm the only documentation. :-) First, you have to realize the probing and binding can happen in response to several different events. Registering a new interface (which usb_set_configuration does) will do it. So will the driver core when userspace writes to the "bind" file in /sys/bus/usb/drivers/.../. usbcore itself initiates probing following a device reset or resume, if one of the interface drivers didn't include the appopriate methods and thus had to be unbound. And drivers can request binding on their own by calling usb_claim_interface. (This list may not be complete. The point is that binding happens in lots of different ways.) Furthermore, although binding usually involves calling a driver's probe routine, it doesn't have to. If dev->driver is set when dev is registered with the driver core, the binding will be created automatically without any probing. In the USB subsystem this can happen when a driver calls usb_claim_interface for an interface that hasn't been registered yet. To understand the usual control flow, keep in mind the distinction between USB devices (described as "functions" in the USB-2.0 spec although not in the USB-3.0 spec) and USB interfaces. Confusingly, we tend to refer to them both as "devices". As you know, when a new USB device is detected, khubd enumerates and registers it. Registration causes the usb_generic driver to be probed. generic_probe, among other things, chooses a default configuration and calls usb_set_configuration. (Note: The pathway involves usb_probe_device, but this is pretty much just a formality. usb_generic is the _only_ driver in the kernel for USB devices.) This in turn causes the config's interfaces to be registered, which causes the various drivers for those interfaces to be loaded and probed. Interface probing always passes through usb_probe_interface. Just like binding, unbinding can happen in several different ways. It's a little simpler because unbinding a driver from an interface always involves usb_unbind_interface, even if the interface hasn't been registered yet -- that's the only place where the driver's disconnect method gets called. > > But of course, now you face the problem of what to do when > > usb_set_configuration changes a whole bunch of bindings at once. The > > easiest answer is to disable/enable the timeouts around each new > > binding. Then you wouldn't need to touch usb_set_configuration. > > I think I have to disable the timeouts around unbindings as well, > correct? If I unbind a driver that's no longer using an isochronous > endpoint, then the timeout might change as well. > > The probe functions look like a good place to put this. However, I'm > going to have to take the bandwidth_mutex in order to change some xHCI > parameters, and I'm a bit concerned about deadlocking with the > usb_set_configuration, usb_reset_configuration, and usb_set_interface. Indeed, it looks like you may need nested enables and disables, which implies some sort of counting mechanism. Does it make sense always to update the link-state stuff along with the bandwidth calculations? > I think I'll be ok, since the bandwidth_mutex is dropped before the > driver bind takes place. I think that's necessary since some drivers > set alternate interfaces in their probe functions? Yes, they do. > I think even if I set the timeouts around the driver bind/unbind, I > still need to handle the case where a driver changes the alternate > interface setting, and periodic endpoints get added or removed. So I > think the timeouts need to be recalculated in usb_set_interface as > well. And usb_reset_device needs to disable the timeouts before the > device is reset. How careful are you about keeping separate track of the parent hub's U1/U2 port-timeout settings and the device's settings? From what you've written so far, it isn't clear. 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
