>> > 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.
>
>Why not? Are there other times we need to allocate an urb in this
>manner (where we can't call schedule())?
Then you start coding around a limitation in the API.
As submitting with a spinlock held must work and needs a gfp
parameter to work cleanly, we might as well make a consistent change.
[..]
>No, just change the api (adding "int gfp" to usb_submit_urb()) and fix
>everything up. I don't want to add more functions. Hey, _I_ just
>offered to fix up all of the drivers, please take me up on this :)
As you like it. :-)
>This is one of the joys of Linux development, we don't have to keep old
>interfaces around, and be forced to create new ones. We can fix the old
>one correctly, like this would do:
> int usb_submit_urb (struct urb *urb, int gfp);
>
>> int usb_revoke_urb_sync(struct urb *urb);
>> int usb_revoke_urb_async(struct urb *urb);
>
>Are you trying to split up the current usb_unlink_urb() case? Do you
>think this is really necessary?
Much better. The networking drivers have a need to unlink
the same urb both asynchronously and synchronously.
Furthermore it allows functionality to be shifted from the HCDs
to usbcore.
>> void usb_wait_completion(struct urb *urb);
>
>I like this. It would probably clean up a lot of driver code, right?
Make it free of races. As recent discussions have showed there's
a fundamental disagreement on how usb_unlink_urb() should
work with respect to running completion handlers.
As a completion handler may be running even after a synchronous
unlink has returned, almost all drivers have a race on disconnect.
Regards
Oliver
_______________________________________________
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
