> > > HCD and USB core do not unlink URBs on device disconnect because currently > > > it is driver's responsibility. > > > > Not entirely true. OHCI tries to safeguard against broken drivers, > > and in 2.5 anything using the new HCD code in usbcore does the > > same safeguarding. (Such as EHCI ...) The UHCI drivers may do > > things differently. > > They'd have to be particularly broken then.
Yes, but drivers that broken do pop up with some regularity. > The HCD's will only get the > disconnect callback if the reference count is 0, and that only happens > when all of the URB's are unlinked. Not quite -- device disconnect is forced when the hub driver reports that the device went away. It's a physical event, not a logical one (except for the "rmmod the hcd" case). The API rules are there to ensure that when the device goes away, that device refcount also goes to zero. It's _supposed_ to be the case that after all driver disconnect() methods (for each claimed interface) are called, then the device refcount goes down to one (no more refs from active URBs). The usbcore-internal usb_disconnect() routine, AFTER all drivers have disconnected, is the only place that the device refcount may go to zero ... but by observation, some drivers are way buggy there. > > > Is it valid to assume that if disconnect method is running completion > > > handler for bulk transfers will be called > > > _only_ as a result of usb_unlink_urb ? For a more complete answer: no. The hub driver may trigger the interface disconnect logic in one thread, while the HCD notices a completion in a less unusual path. > > As above. Drivers with disconnect() methods that don't kill all their > > outstanding URBs are buggy, in any case. > > Absolutely. > > JE > - Dave _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
