> > I'd not attempt such tricks outside the completion handler, though.
> > And it shouldn't really be necessary, either. ISO will have the same
> > issue; in both cases, a fix seems like it'd need to formally introduce
>
> Why? An ISO URB is in progress or done when its completion is called.
> Interrupts are the only exception.
I guess I'm wondering why that's the API model, given that the USB
spec says both ISO and INTR are periodic ... is Linux treating ISO
this way (scheduled like funky bulk) for any more reasons than history?
It doesn't seem like handling EHCI ISO that way will be a good fit.
> > the "URB on loan to driver" state. (I wonder how the UHCIs deal
> > with that?)
>
> usb-uhci: If it's an interrupt, try to kill it regardless of the state.
Presumably there's some mechanism in place to deal with the fact
that up to three contexts could be trying to do that concurrently:
- completion handler, from HC interrrupt handler
- driver thread (let's assume just one :)
- hcd disconnect processing (rmmod)
Only one of them should succeed at a time ... that's what a state
like "urb on lone" would help guarantee.
Call me paranoid, but such potential problems turn into real ones
often enough that I've learned it's worth worrying about them!
- Dave
_______________________________________________
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
http://lists.sourceforge.net/lists/listinfo/linux-usb-devel
