linux/drivers/usb/host, branch v3.0

usb: r8a66597-hcd: fix cannot detect low/full speed device

2011-06-27T20:46:44Z

This controller can control "Transaction Translators", but the hcd->has_tt is not set. Since the commit d199c96d41d80a567493e12b8e96ea056a1350c1 ("USB: prevent buggy from crashing the USB stack") has checked it, the driver could not work the low/full speed device. Signed-off-by: Yoshihiro Shimoda Signed-off-by: Greg Kroah-Hartman

USB: ehci-ath79: fix a NULL pointer dereference

2011-06-27T20:46:44Z

Loading the ehci-hcd module on the ath79 platform causes a NULL pointer dereference: CPU 0 Unable to handle kernel paging request at virtual address 00000000, epc == c0252928, ra == c00de968 Oops[#1]: Cpu 0 $ 0 : 00000000 00000070 00000001 00000000 $ 4 : 802cf870 0000117e ffffffff 8019c7bc $ 8 : 0000000a 00000002 00000001 fffffffb $12 : 8026ef20 0000000f ffffff80 802dad3c $16 : 8077a2d4 8077a200 c00f3484 8019ed84 $20 : c00f0000 00000003 000000a0 80262c2c $24 : 00000002 80079da0 $28 : 80788000 80789c80 80262b14 c00de968 Hi : 00000000 Lo : b61f0000 epc : c0252928 __mod_vermagic5+0xc260/0xc7e8 [ehci_hcd] Not tainted ra : c00de968 usb_add_hcd+0x2a4/0x858 [usbcore] Status: 1000c003 KERNEL EXL IE Cause : 00800008 BadVA : 00000000 PrId : 00019374 (MIPS 24Kc) Modules linked in: ehci_hcd(+) pppoe pppox ipt_REJECT xt_TCPMSS ipt_LOG xt_comment xt_multiport xt_mac xt_limit iptable_mangle iptable_filte r ip_tables xt_tcpudp x_tables ppp_async ppp_generic slhc ath mac80211 usbcore nls_base input_polldev crc_ccitt cfg80211 compat input_core a rc4 aes_generic crypto_algapi Process insmod (pid: 379, threadinfo=80788000, task=80ca2180, tls=77fe52d0) Stack : c0253184 80c57d80 80789cac 8077a200 00000001 8019edc0 807fa800 8077a200 8077a290 c00f3484 8019ed84 c00f0000 00000003 000000a0 80262c2c c00de968 802d0000 800878cc c0253228 c02528e4 c0253184 80c57d80 80bf6800 80ca2180 8007b75c 00000000 8077a200 802cf830 802d0000 00000003 fffffff4 00000015 00000348 00000124 800b189c c024bb4c c0255000 801a27e8 c0253228 c02528e4 ... Call Trace: [] __mod_vermagic5+0xc260/0xc7e8 [ehci_hcd] It is caused by: commit c430131a02d677aa708f56342c1565edfdacb3c0 Author: Jan Andersson Date: Tue May 3 20:11:57 2011 +0200 USB: EHCI: Support controllers with big endian capability regs The two first HC capability registers (CAPLENGTH and HCIVERSION) are defined as one 8-bit and one 16-bit register. Most HC implementations have selected to treat these registers as part of a 32-bit register, giving the same layout for both big and small endian systems. This patch adds a new quirk, big_endian_capbase, to support controllers with big endian register interfaces that treat HCIVERSION and CAPLENGTH as individual registers. Signed-off-by: Jan Andersson Acked-by: Alan Stern Signed-off-by: Greg Kroah-Hartman The reading of the HC capability register has been moved by that commit to a place where the ehci->caps field is not initialized yet. This patch moves the reading of the register back to the original place. Acked-by: Jan Andersson Cc: Alan Stern Signed-off-by: Gabor Juhos Signed-off-by: Greg Kroah-Hartman

usb/isp1760: Fix bug preventing the unlinking of control urbs

2011-06-27T20:46:43Z

Both control and bulk transfers use isp1760 slots of type ATL, but the driver unlink code for ATL slots only acts on urbs describing a bulk transfer, letting the code for INT slots take care of the unlink instead, which often ended up removing the interrupt transfer for root hub events instead. That's not good, and gets fixed by this patch. Signed-off-by: Arvid Brodin Cc: Sebastian Andrzej Siewior Signed-off-by: Greg Kroah-Hartman

Merge branch 'for-usb-linus' of git+ssh://master.kernel.org/pub/scm/linux/kernel/git/sarah/xhci into usb-linus

2011-06-27T20:36:47Z

* 'for-usb-linus' of git+ssh://master.kernel.org/pub/scm/linux/kernel/git/sarah/xhci: USB: Fix up URB error codes to reflect implementation. xhci: Always set urb->status to zero for isoc endpoints. xhci: Add reset on resume quirk for asrock p67 host xHCI 1.0: Incompatible Device Error xHCI 1.0: Force Stopped Event(FSE) xhci: Don't warn about zeroed bMaxBurst descriptor field. USB: Free bandwidth when usb_disable_device is called. xhci: Reject double add of active endpoints.

xhci: Always set urb->status to zero for isoc endpoints.

2011-06-17T18:28:20Z

When the xHCI driver encounters a Missed Service Interval event for an isochronous endpoint ring, it means the host controller skipped over one or more isochronous TDs. For TD that is skipped, skip_isoc_td() is called. This sets the frame descriptor status to -EXDEV, and also sets the value stored in the int pointed to by status to -EXDEV. If the isochronous TD happens to be the last TD in an URB, handle_tx_event() will use the status variable to give back the URB to the USB core. That means drivers will see urb->status as -EXDEV. It turns out that EHCI, UHCI, and OHCI always set urb->status to zero for an isochronous urb, regardless of what the frame status is. See itd_complete() in ehci-sched.c: } else { /* URB was too late */ desc->status = -EXDEV; } } /* handle completion now? */ if (likely ((urb_index + 1) != urb->number_of_packets)) goto done; /* ASSERT: it's really the last itd for this urb list_for_each_entry (itd, &stream->td_list, itd_list) BUG_ON (itd->urb == urb); */ /* give urb back to the driver; completion often (re)submits */ dev = urb->dev; ehci_urb_done(ehci, urb, 0); ehci_urb_done() completes the URB with the status of the third argument, which is always zero in this case. It turns out that many USB webcam drivers, such as uvcvideo, cannot handle urb->status set to a non-zero value. They will not resubmit their isochronous URBs in that case, and userspace will see a frozen video. Change the xHCI driver to be consistent with the EHCI and UHCI driver, and always set urb->status to 0 for isochronous URBs. This patch should be backported to kernels as old as 2.6.36 Signed-off-by: Sarah Sharp Cc: "Xu, Andiry" Cc: stable@kernel.org

xhci: Add reset on resume quirk for asrock p67 host

2011-06-17T18:28:19Z

The asrock p67 xhci controller completely dies on resume, add a quirk for this, to bring the host back online after a suspend. This should be backported to stable kernels as old as 2.6.37. Signed-off-by: Maarten Lankhorst Signed-off-by: Sarah Sharp Cc: stable@kernel.org

xHCI 1.0: Incompatible Device Error

2011-06-17T18:28:08Z

It is one new TRB Completion Code for the xHCI spec v1.0. Asserted if the xHC detects a problem with a device that does not allow it to be successfully accessed, e.g. due to a device compliance or compatibility problem. This error may be returned by any command or transfer, and is fatal as far as the Slot is concerned. Return -EPROTO by urb->status or frame->status of ISOC for transfer case. And return -ENODEV for configure endpoint command, evaluate context command and address device command if there is an incompatible Device Error. The error codes will be sent back to the USB core to decide how to do. It's unnecessary for other commands because after the three commands run successfully means that the device has been accepted. Signed-off-by: Alex He Signed-off-by: Sarah Sharp

USB: change maintainership of ohci-hcd and ehci-hcd

2011-06-16T00:44:56Z

Following the loss of David Brownell, I volunteer to maintain the ohci-hcd and ehci-hcd drivers. This patch (as1472) makes it official. Signed-off-by: Alan Stern Signed-off-by: Greg Kroah-Hartman

xHCI 1.0: Force Stopped Event(FSE)

2011-06-15T21:37:14Z

FSE shall occur on the TD natural boundary. The software ep_ring dequeue pointer exceed the hardware ep_ring dequeue pointer in these cases of Table-3. As a result, the event_trb(pointed by hardware dequeue pointer) of the FSE can't be found in the current TD(pointed by software dequeue pointer). What should we do is to figured out the FSE case and skip over it. Signed-off-by: Alex He Signed-off-by: Sarah Sharp

xhci: Don't warn about zeroed bMaxBurst descriptor field.

2011-06-15T21:10:30Z

The USB 3.0 specification says that the bMaxBurst field in the SuperSpeed Endpoint Companion descriptor is supposed to indicate how many packets a SS device can handle before it needs to wait for an explicit handshake from the host controller. A zero value means the device can only handle one packet before it needs a handshake. Remove a warning in the xHCI driver that implies this is an invalid value. Signed-off-by: Sarah Sharp