The problem is that physical USB devices aren't data structures -- you
can't deallocate one and then allocate a new copy when you need it! Some form of synchronization is needed if we want to prevent multiple
drivers from talking to the same interface at the same time.
Nothing prevents giving out 'struct usb_endpoint_binding's which URBs could be addressed to. They could have proper reference counting. You could have them on lists which you walk in case of disconnect(), config change, etc ...
That is just what David has proposed for 2.7. We should give some extra
My original thought was to use "struct usb_ep" (from the gadget driver framework), with a slightly different lifecycle. (Activated by usbcore after successful SET_CONFIGURATION or SET_INTERFACE, not by the driver.) That would imply using "struct usb_request" instead of URB, which has both good and bad features.
It'd be easy to prototype that with OHCI. The "urb_priv" data is analagous to a "usb_request", and the "ed" is a "usb_ep". Define ways to get each "usb_ep" associated with a given active interface (including ep0), refcount, and voila!
A more recent thought was to just remove urb->dev, replacing it with the interface -- while still keeping "URB" -- but that'd imply usbcore needs some additional interfaces to let it talk to devices that have no active interfaces. Those could very easily look like "usb_ep"... giving lots of choices about how to write drivers.
thought to the problem of dealing with ep 0, however.
David is right. It seems to me that there's a problem with ep0 only if we do reference counting on some internal representation of the device.
I'm not sure I follow you. I'd expect the refcounting (which FWIW doesn't exist in the gadget framework right now, patches accepted :) to exist, but don't see any reason that should imply ep0 problems.
That would only shift the problem. We should actually allocate a data structure with every binding which can be refcounted and io addressed to.
That is, one for each binding? That'd include ep0.
Alan's patch to dynamically allocate interfaces (as246c and counting!) pretty much makes it be that "per-binding" data structure, yes?
But remember, the issue isn't just binding ... altsettings matter too.
- Dave
Regards Oliver
------------------------------------------------------- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
