On Thu, 13 Oct 2005, Franck wrote:

> > If every HCD is careful not to use URBs that aren't marked (i.e., for
> > which urb->hcpriv is NULL), then a single endpoint queue would be okay.
> > And it wouldn't be necessary to move the usb_get_urb and atomic_inc
> > statements either (or the DMA stuff).
> >
> 
> Actually it won't work for me ! I use urb->hcpriv _only_ when this urb
> is about to be sent by hw...

I don't see why that should be a problem.  You can continue using
urb->hcpriv when the URB is about to be sent by the hardware and also use
it at other times too.  Or you could store a special non-NULL sentinel
value in urb->hcpriv at times when the URB isn't being sent by the
hardware.

> > We will still have the problem that the HCDs don't have access to the
> > spinlock that protects the queue pointers.  I suppose the spinlock could
> > be EXPORTed.
> >
> 
> obviously endpoint queues are usbcore's data but used by hcd. hcd
> seems to know when an urb  is active. Therefore we could export a new
> usbcore's function which would be called by hcd to make an urb active:
> 
> void usb_make_active(struct usb_hos_endpoint *ep, struct *urb)
> {
>         spin_lock(&hcd_data_lock);
>         usb_get_urb(urb);
>         atomic_inc(&urb->use_count);
>         list_add_tail (&urb->urb_list, &ep->urb_list);
>         spin_unlock(&hcd_data_lock);
> }

This wouldn't work with your HCD, would it?  How would your HCD know what 
URB to make active next, if the URB wasn't already linked into the list?

Also remember that URBs can be given back out of order if they are 
unlinked.  Then you have a race: URB is being given back because it was 
unlinked, and at the same time your HCD is making it active.

I prefer the idea of moving the spinlock into the hcd data structure.

Alan Stern



-------------------------------------------------------
This SF.Net email is sponsored by:
Power Architecture Resource Center: Free content, downloads, discussions,
and more. http://solutions.newsforge.com/ibmarch.tmpl
_______________________________________________
linux-usb-devel@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel

Reply via email to