diff options
author | David Brownell <david-b@pacbell.net> | 2008-02-08 18:08:44 -0500 |
---|---|---|
committer | Greg Kroah-Hartman <gregkh@suse.de> | 2008-04-25 00:16:35 -0400 |
commit | caa9ef672a045ba0b19184cd3f872b583f066771 (patch) | |
tree | f55bc5f1e2597c947b00d813d9c7568a2d0af02b /drivers/usb/host/ehci-q.c | |
parent | e01e7fe3886715f083313da409c5850472455d06 (diff) |
USB: ehci tolerates some buggy devices
This teaches EHCI how to to work around bugs in certain high speed
devices, by accomodating "bulk" packets that exceed the 512 byte
constant value required by the USB 2.0 specification. (Have a
look at section 5.8.3, paragraphs 1 and 3.)
It also makes the descriptor parsing code warn when it encounters
such bugs. (We've had reports of maybe two or three such devices,
all pretty recent.)
Such devices are nonconformant. The proper fix is have the vendors
of those devices do the simple, obvious, and correct thing ... which
will let them be used with USB hosts that don't have workarounds for
this particular vendor bug. But unless/until they do, we can at least
have one of the high speed HCDs work with such buggy devices.
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Diffstat (limited to 'drivers/usb/host/ehci-q.c')
-rw-r--r-- | drivers/usb/host/ehci-q.c | 16 |
1 files changed, 15 insertions, 1 deletions
diff --git a/drivers/usb/host/ehci-q.c b/drivers/usb/host/ehci-q.c index 2e49de820b14..c0e752cffc68 100644 --- a/drivers/usb/host/ehci-q.c +++ b/drivers/usb/host/ehci-q.c | |||
@@ -657,6 +657,14 @@ qh_make ( | |||
657 | type = usb_pipetype (urb->pipe); | 657 | type = usb_pipetype (urb->pipe); |
658 | maxp = usb_maxpacket (urb->dev, urb->pipe, !is_input); | 658 | maxp = usb_maxpacket (urb->dev, urb->pipe, !is_input); |
659 | 659 | ||
660 | /* 1024 byte maxpacket is a hardware ceiling. High bandwidth | ||
661 | * acts like up to 3KB, but is built from smaller packets. | ||
662 | */ | ||
663 | if (max_packet(maxp) > 1024) { | ||
664 | ehci_dbg(ehci, "bogus qh maxpacket %d\n", max_packet(maxp)); | ||
665 | goto done; | ||
666 | } | ||
667 | |||
660 | /* Compute interrupt scheduling parameters just once, and save. | 668 | /* Compute interrupt scheduling parameters just once, and save. |
661 | * - allowing for high bandwidth, how many nsec/uframe are used? | 669 | * - allowing for high bandwidth, how many nsec/uframe are used? |
662 | * - split transactions need a second CSPLIT uframe; same question | 670 | * - split transactions need a second CSPLIT uframe; same question |
@@ -757,7 +765,13 @@ qh_make ( | |||
757 | info2 |= (EHCI_TUNE_MULT_HS << 30); | 765 | info2 |= (EHCI_TUNE_MULT_HS << 30); |
758 | } else if (type == PIPE_BULK) { | 766 | } else if (type == PIPE_BULK) { |
759 | info1 |= (EHCI_TUNE_RL_HS << 28); | 767 | info1 |= (EHCI_TUNE_RL_HS << 28); |
760 | info1 |= 512 << 16; /* usb2 fixed maxpacket */ | 768 | /* The USB spec says that high speed bulk endpoints |
769 | * always use 512 byte maxpacket. But some device | ||
770 | * vendors decided to ignore that, and MSFT is happy | ||
771 | * to help them do so. So now people expect to use | ||
772 | * such nonconformant devices with Linux too; sigh. | ||
773 | */ | ||
774 | info1 |= max_packet(maxp) << 16; | ||
761 | info2 |= (EHCI_TUNE_MULT_HS << 30); | 775 | info2 |= (EHCI_TUNE_MULT_HS << 30); |
762 | } else { /* PIPE_INTERRUPT */ | 776 | } else { /* PIPE_INTERRUPT */ |
763 | info1 |= max_packet (maxp) << 16; | 777 | info1 |= max_packet (maxp) << 16; |