Hi David,
I certainly don't argue for the sake of arguing. I see a real problem here.
> > Not from a driver standpoint. If a driver unlinks an urb, it needs
> > to be dead,
>
> As it will be -- after a delay to make sure the hardware finished.
>
> THINK!! It is NOT immediate. For synchronous unlinks, the
> calling thread must wait till the hardware is clearly done ... now,
> does that suggest why a completion handler (no thread) can't
> use a synchronous unlink?
Yes, it is clear that a completion handler cannot unlink synchronously.
I am refering to an unlink from process context while a completion
handler is running on _another_ cpu.
> > even if the completion handler resubmits it.
>
> If it submits an URB that is still owned by usbcore/HCD, say
> because the unlink hasn't completed, that's a driver bug.
> One car, two drivers -- crash!
The problem is basically that the usbcore in case of an unlink has
to wait while the hardware might be dealing with an urb and the
completion handler is running.
But how do you wait for a data structure that may be freed ?
cpu 1: submit - something - - unlink - wait on urb
cpu 2: interrupt - free
Regards
Oliver
_______________________________________________
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
