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? "the other parts of enumeration" you mean is class driver, right? > >> 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? As I remember correctly, the usb class driver is passively called with different interface class ID matched. > that time interface 1 hasn't been unbound yet. Since interface 1 is > still owned, the driver will not be able to claim it. > > On the other hand, the new code will unbind interface 0, then unbind > interface 1, then rebind interface 0, and then rebind interface 1. Now > if the driver's probe routine for interface 0 tries to claim interface > 1, the claim will succeed because interface has already been unbound. appreciate your kind help, -- 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
