On Mon, 25 Aug 2014, vichy wrote: > hi Alan: > >> After usb_reset_device, the whole enumeration will run again, > > > > No, only part of the enumeration. The kernel does read the device and > > config descriptors again. But if the reset succeeded, the kernel > > doesn't carry out any of the other parts of enumeration. > here the kernel you mean above is usb HCD driver, right? I mean usbcore. > "the other parts of enumeration" you mean is class driver, right? If the reset succeeds, usbcore does not call usb_choose_configuration or usb_set_configuration. It also does not create any uevents or send any notifications. > >> why this > >> patch say the previous solution will be fail to claim additional > >> interface? > > > > Suppose a driver claims interfaces 0 and 1, and then they have to be > > unbound and rebound. The old code would unbind interface 0, then > > rebind it, then unbind interface 1, and then rebind it. > > > > Suppose the driver's probe routine for interface 0 tries to claim > > interface 1? The probe routine runs when interface 0 is rebound. At > Is there any class driver will try to claim both interface 0 and 1? Yes. You can find them easily by searching for calls to usb_driver_claim_interface. > As I remember correctly, the usb class driver is passively called with > different interface class ID matched. Not always. 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
