Wow...I see how the urb->complete() could free the urb (and spinlock), but it's
not necessarily always freeing it, right?
Wouldn't it be better to not allow freeing inside the completion? Let a driver
do it in a BH?
Or am I still off the mark? ;-)
On Fri, 18 May 2001, Pete Zaitcev wrote:
>Dan, the little gem that you quote belongs to David-B.
>I was shocked what I saw it too. However, I let it pass
>unchallenged upon David's authority, just ranted loud
>about idiotic API of USB (w.r.t. freeing inside a callback).
>
>Here is the thread:
> http://marc.theaimsgroup.com/?t=98581009700001&w=2&r=1
> http://marc.theaimsgroup.com/?l=linux-usb-devel&m=98580988401128&w=2
>
>-- Pete
>
>> From: Dan Streetman <[EMAIL PROTECTED]>
>> To: Linux-USB development mailing list <[EMAIL PROTECTED]>,
>> Johannes Erdfelt <[EMAIL PROTECTED]>, Georg Acher <[EMAIL PROTECTED]>
>> Date: Thu, 17 May 2001 23:19:52 -0400 (EDT)
>>
>> I think that holding the urb's spinlock is bad if that urb
>> will ever be used again; although maybe I'm missing something...
>> I'm also not clear on why urb is being NULLed...
>>
>> --- 2.4.4-clean/drivers/usb/usb-uhci.c Fri Apr 27 18:13:07 2001
>> +++ linux/drivers/usb/usb-uhci.c Thu May 17 23:16:19 2001
>> @@ -2639,14 +2639,12 @@
>> if (is_ring && !was_unlinked && !contains_killed) {
>> urb->dev=usb_dev;
>> uhci_submit_urb (urb);
>> - } else
>> - urb = 0;
>> + }
>> spin_lock(&s->urb_list_lock);
>> }
>>
>> usb_dec_dev_use (usb_dev);
>> - if (urb)
>> - spin_unlock(&urb->lock);
>> + spin_unlock(&urb->lock);
>> }
>> }
>>
>
>_______________________________________________
>[EMAIL PROTECTED]
>To unsubscribe, use the last form field at:
>http://lists.sourceforge.net/lists/listinfo/linux-usb-devel
>
>
--
Dan Streetman
[EMAIL PROTECTED]
_______________________________________________
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
http://lists.sourceforge.net/lists/listinfo/linux-usb-devel
