Re: some question about unbind and rebind usb interfaces
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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: some question about unbind and rebind usb interfaces
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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
some question about unbind and rebind usb interfaces
hi all: below patch introduce unbind and rebind interfaces during usb reset https://lists.ubuntu.com/archives/kernel-team/2014-April/042177.html If a driver claims additional interfaces, the claim may fail because the old binding instance may still own the additional interface when the new instance tries to claim it. After usb_reset_device, the whole enumeration will run again, why this patch say the previous solution will be fail to claim additional interface? thanks for your help in advance, -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: some question about unbind and rebind usb interfaces
On Sun, 24 Aug 2014, vichy wrote: hi all: below patch introduce unbind and rebind interfaces during usb reset https://lists.ubuntu.com/archives/kernel-team/2014-April/042177.html If a driver claims additional interfaces, the claim may fail because the old binding instance may still own the additional interface when the new instance tries to claim it. 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. 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 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. Alan Stern -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
