On Fri, Mar 15, 2002, David Brownell <[EMAIL PROTECTED]> wrote: > > > > 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.
Obviously, broken drivers can cause reference counting problems, but you can't work around all of them, nor should we. There's just too many different failure scenarios that trying to workaround them is just wasted effort. I'd much rather see something fail and then fix the appropriate driver. If it fails in a crash/oops, that's even more of a reason to fix the problem :) JE _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
