Hi Pete,
> > static void urb_destroy(struct kref *kref)
> > {
> > struct urb *urb = to_urb(kref);
> > +
> > + if (urb->transfer_flags & URB_FREE_BUFFER)
> > + usb_buffer_free(urb->dev, urb->transfer_buffer_length,
> > + urb->transfer_buffer, urb->transfer_dma);
> > +
> > kfree(urb);
> > }
>
> This looks good to me, although it's useless for the vast majority
> of drivers, because they use kmalloc, or should use kmalloc, but
> use usb_buffer_alloc due to confusion. I'm actually wondering now
> if your driver is one of the latter...
the hci_usb driver is totally messed up in case of buffer management. I
was working on a re-write for quite some time, but never found a nice
way to handle submit and forget use cases with URBs and their buffers.
With the reference count and the new USB anchors it is finally possible
to handle this nicely. The new driver is looking good now with the
exception of the incoming URBs.
I simply don't see any good reason for the incoming URBs (that get
re-submitted every time) to add buffer management to the driver. So this
is my idea on how to make it simply for the drivers while still
providing the capability to provide your own buffer. Actually for the
outgoing URBs I am providing skb->data as buffer and that is kinda nice
feature.
The usb_buffer_alloc() and usb_buffer_free() usage was taken from the
skeleton example driver. No idea if that is a good idea or not. I was
under the impression that using the provided helper function that take
care of DMA is a good thing.
Regards
Marcel
-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
linux-usb-devel@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
