First for reference: By inspection this seems to apply to 2.2.19 and 2.4.3
although I've only actually run on 2.4.1
When using usbdevfs I've seen in the past the recommendation to poll interrupt
pipes with bulk transfers as a workaround for not having interrupt
transfer support in usbdevfs.
Unfortunately, this does not work with lowspeed devices and uhci.c, because
uhci.c throws out bulk transfers on lowspeed pipes (uhci_submit_bulk()).
So for example when trying to control a USB Mouse with but one lonely interrupt
endpoint, bulk submissions to that endpoint are harshly (see below) rejected.
The merits of this check can probably be debated, and FWIW usb-uhci.c doesn't
have this check and the submitting bulk packets to interrupt pipe hack works fine
(I also believe usb-ohci.c doesn't check, but I only skimmed the code).
In looking over the list archives it seems there was a discussion long ago (9/2000)
about a patch which added interrupt transfers to usbdevfs. Perhaps this is a
reason to relook at that (or perhaps it is a reason to remove the restriction
from uhci.c)
Anyhow, I'm interested in opinions either way.
On a seperate note, there is a REAL bug in uhci.c that I ran into when failing
this check.
If uhci_submit_bulk() returns -EINVAL due to this check (or any other check for
that matter) uhci_submit_urb() calls uhci_unlink_generic(urb) followed by
usb_dec_dev_use(urb->dev).
Casual inspection reveals that the last think uhci_unlink_generic() does is set
urb->dev to NULL, and that the following call to usb_dec_dev_use() immediately
dereferences urb->dev. This is of course a BadThing(TM). In practice for me
though, it doesn't even make it that far before oops'ing. It actually oops'es
in uhci_remove_urb_list while performing list_del(&urb->urb_list) so it's probably
a good time to revisit the handling of errors there.
Matt Eccleston
VMware Inc.
_______________________________________________
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
http://lists.sourceforge.net/lists/listinfo/linux-usb-devel
