> > 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.
Actually I would not call it broken driver. I think it make sense for HCD
or USB core to
cancel all outstanding requests prior to calling 'disconnect'.
Driver has to maintain a list of urbs that it has submitted _only_ because
it has to cancel
them on disconnect. HCD also has to maintain a queue with the submitted
urbs for this device.
So, list in the driver is pretty much a waste. Why can't HCD just cancel
them itself before calling
disconnect ?
Every single driver has to cancel it's urbs because there is no point in
leaving them
after disconnect, right. So, why not do it a centralized way and make
drivers simpler.
So typical USB Ethernet and Bluetooth (and probably other) drivers would be
as simple as:
alloc_urb -> submit_urb -> complete -> free urb
disconnect -> free packet queues
instead of:
alloc_urb -> add urb to list -> submit urb -> complete -> del urb
from list
disconnect -> for each list(unlink_urb) -> free packet queues
(this one is oversimplified, there are some issues involved with
the list)
> > 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 ?
>
>As above. Drivers with disconnect() methods that don't kill all their
>outstanding URBs are buggy, in any case.
So sounds like OHCI and EHCI do cleanup urbs on disconnect.
But I guess they do than after calling dev->disconnect.
If that's true then my assumption is still valid, right ?
Max
_______________________________________________
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
