于 2012年12月17日 23:27, Alan Stern 写道:
> On Mon, 17 Dec 2012, Chen Gang wrote:
>
>> 于 2012年12月17日 11:08, Alan Stern 写道:
>>> It is pretty much as I explained in my previous email.
>>>
>>> finish_urb calls usb_free_priv while holding the lock. Then while
>>> still holding the lock, it calls usb_hcd_unlink_urb_from_ep.
>>>
>>> In addition, ohci_urb_dequeue calls usb_hcd_check_unlink_urb while
>>> holding the lock, and does nothing if the return value is nonzero.
>>>
>>> So all you need to do is verify that after usb_hcd_unlink_urb_from_ep
>>> runs, usb_hcd_check_unlink_urb will always return a nonzero value. In
>>> fact, it will return -EIDRM -- until the next time the URB is submitted
>>> and usb_hcd_link_urb_to_ep is called.
>>
>> it is true for ohci_urb_dequeue.
>> how about finish_unlinks and takeback_td in drives/usb/host/ohci-q.c ?
>> (they also can call finish_urb).
>
> Those routines, like almost all the rest of the driver, look at TDs
> that haven't been processed yet and URBs that haven't been completed
> yet. Once a TD is processed, it is freed. Since finish_urb isn't
> called until all the TDs in an URB have been processed, urb->hcpriv
> will be a valid pointer for any URB encountered.
>
> The only places where this isn't true is while an URB is being
> submitted. The submission routines are careful to free all the private
> data structures if the URB is not accepted.
>
> Alan Stern
>
thank you for your reply in details.
:-)
next:
I will write the 2 patches
one for current suggestion.
the other for sprintf suggestion.
time region:
tomorrow, I begin constructing relative environments.
I should try to finish 2 patches within this week (before Mon Dec 24
2012)
excuse me:
I can not give a full test, but I need provide enough unit test, at
least.
after finish 2 patches, I will turn back for the details of your
reply, again.
welcome any additional suggestions
thanks.
--
Chen Gang
Asianux Corporation
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
