> For this case, I'd argue that a driver shouldn't be allocating a urb
> within an interrupt at all :)
In this case that can be done. But it's not an answer to all such problems.
[..]
> Now the comments about the HCD drivers needing to know about this, and
> their API being changed, I understand. I'd be glad to accept such a
> patch (I am even willing to fix up all of the drivers in the tree, if
> someone wants to just patch the HCD drivers, and a single device driver
> to test things with.)
>
> And no, I don't mind breaking API compatibility between 2.4 and 2.5 trees
> to fix such a real problem. After 2.5 is changed, and problems are
> shaken out, we can always backport to 2.4, if necessary.
If you want this shouldn't we make a clean break and change names ?
How about:
struct urb *usb_get_urb(int num_iso, int gfp);
void usb_put_urb(struct urb *urb);
int usb_execute_urb(struct urb *urb, int gfp);
int usb_revoke_urb_sync(struct urb *urb);
int usb_revoke_urb_async(struct urb *urb);
void usb_wait_completion(struct urb *urb);
If the first five are not clear by name, you can forget this proposal.
The last one could be used to wait for a completion handler to
finish, which would simplify coding disconnect a lot.
Regards
Oliver
_______________________________________________
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
