Am Freitag, 4. Mai 2007 06:47 schrieb Greg KH:
> On Thu, May 03, 2007 at 11:05:54AM -0400, Alan Stern wrote:
> > On Thu, 3 May 2007, Oliver Neukum wrote:
> >
> > > Am Donnerstag, 3. Mai 2007 16:03 schrieb Alan Stern:
> > > > On Thu, 3 May 2007, Oliver Neukum wrote:
> > > >
> > > > > > > How about exporting usb_disable_interface() and
> > > > > > > usb_enable_interface()?
> > > > > > > It doesn't solve the problem for endpoint 0, but this case is
> > > > > > > rare.
> > > > > >
> > > > > > We could; it would save drivers the trouble of keeping track of
> > > > > > their own
> > > > > > URBs. Do you have a particular driver in mind for this?
> > > > >
> > > > > Everything derived from newer versions of the skeleton driver.
> > > >
> > > > Would we be better off modifying the skeleton driver to keep track of
> > > > its
> > > > own URBs?
> > >
> > > I am unsure. The "fire-and-forget" technique is certainly simple for
> > > driver writers. Perhaps we should make it easier to keep track of URBs.
> > > A list_head in the URB?
> >
> > People have discussed adding one in the past. Greg might have some
> > opinions.
>
> My opinion is that we need to ensure that we can still do the
> "fire-and-forget" type driver :)
Did you intentionally not mention them needing to be easy to use as
well as possible?
Well, forgetting your URBs has the obvious problem that you have no
legitimate reference to call usb_kill_urb() with. So keeping them in a list
the driver keeps up to date is not an option. But they have to be on a list.
The URBs should be killed when
- the device suspends
- the device is reset
- the interface is logically disconnected
The case of suspend is the hardest because its requirements are
the toughest. Not only need the URBs to be killed, but it needs to
be done in a specific order, reverse from the order of submission
or IO would be reordered.
This makes a solution with disabling endpoints very unattractive, as
it would open a race if URBs for more than one endpoint are queued
in a specific order, unless we code up a method for atomically disabling
a group of endpoints. Even then endpoint 0 is still a problem.
So I propose:
- an optional list membership in each URB
- usb_associate_urb_to_anchor(struct urb *u, struct anchor *a)
- upon completion usbcore reverses usb_associate_urb_to_anchor()
- usb_kill_associated_urbs(struct anchor *old, struct anchor *new)
which in a loop takes the last element from the list, gets a reference,
kills it and transfers it to the new anchor
- usb_submit_anchored_urbs(struct anchor *a, gfp_t mem_flags)
walks the list and submits all urbs
Any objections?
Regards
Oliver
-------------------------------------------------------------------------
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
