commit ae68a83bdc1971cb02fefc7a686ba6d077065e71 upstream. This patch (as1405) fixes a small bug in ehci-hcd's isochronous scheduler. Not all EHCI controllers are PCI, and the code shouldn't assume that they are. Instead, introduce a special flag for controllers which need to delay iso scheduling for full-speed devices beyond the scheduling threshold. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> CC: Sarah Sharp <sarah.a.sharp@linux.intel.com> CC: David Brownell <david-b@pacbell.net> Acked-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
* git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb-2.6: USB: musb: tusb6010: fix compile error with n8x0_defconfig USB: FTDI: Add support for the RT System VX-7 radio programming cable USB: add quirk for Broadcom BT dongle USB: usb-storage: fix initializations of urb fields USB: xhci: Set Mult field in endpoint context correctly. USB: sisusbvga: Fix for USB 3.0 USB: adds Artisman USB dongle to list of quirky devices USB: xhci: Set EP0 dequeue ptr after reset of configured device. USB: Fix USB3.0 Port Speed Downgrade after port reset USB: xHCI: Fix another bug in link TRB activation change. USB: option: Add support for AMOI Skypephone S2 USB: New PIDs for Qualcomm gobi 2000 (qcserial) USB: ftdi_sio: support for Signalyzer tools based on FTDI chips USB: s3c2410_udc: be aware of connected gadget driver USB: Expose vendor-specific ACM channel on Nokia 5230 USB: Add PID for Sierra 250U to drivers/usb/serial/sierra.c USB: option: add support for 1da5:4518
The bmAttributes field of the SuperSpeed Endpoint Companion Descriptor has different meanings, depending on the endpoint type. If the endpoint is isochronous, the bmAttributes field is the maximum number of packets within a service interval that this endpoint supports. If the endpoint is bulk, it's the number of stream IDs this endpoint supports. Only set the Mult field of the xHCI endpoint context using the bmAttributes field if the endpoint is isochronous, and the device is a SuperSpeed device. Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Cc: stable <stable@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
When a configured device is reset, the control endpoint's ring is reused. If control transfers to the device were issued before the device is reset, the dequeue pointer will be somewhere in the middle of the ring. If the device is then issued an address with the set address command, the xHCI driver must provide a valid input context for control endpoint zero. The original code would give the hardware the original input context, which had a dequeue pointer set to the top of the ring. This would cause the host to re-execute any control transfers until it reached the ring's enqueue pointer. When issuing a set address command for a device that has just been configured and then reset, use the control endpoint's enqueue pointer as the hardware's dequeue pointer. Assumption: All control transfers will be completed or cancelled before the set address command is issued to the device. If there are any outstanding control transfers, this code will not work. Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Commit 6c12db90f19727c76990e7f4801c67a148b30111 also seems to have introduced a bug that is triggered when the command ring is about to wrap. The inc_enq() function will not have moved the enqueue pointer past the link TRB. It is supposed to be moved past the link TRB in prepare_ring(), which should be called before a TD is enqueued. However, the queue_command() function never calls the prepare_ring() function because prepare_ring() is only supposed to be used for endpoint rings. That means the enqueue pointer will not be moved past the link TRB, and will get overwritten. The fix is to make queue_command() call prepare_ring() with a fake endpoint status (set to running). Then the enqueue pointer will get moved past the link TRB. Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Reported-by: Christian Dietrich <qy03fugy@stud.informatik.uni-erlangen.de> Signed-off-by: Eric Miao <eric.y.miao@gmail.com>
Stanse found that isp1362_sw_reset tries to take a isp1362_hcd->lock, but it is already held in isp1362_hc_stop. Avoid that by introducing __isp1362_sw_reset which doesn't take the lock and call it from isp1362_hc_stop. isp1362_sw_reset is then as simple as lock -- __isp1362_sw_reset -- unlock. Signed-off-by: Jiri Slaby <jslaby@suse.cz> Cc: Lothar Wassmann <LW@KARO-electronics.de> Cc: Michael Hennerich <michael.hennerich@analog.com> Cc: Bryan Wu <cooloney@kernel.org> Cc: Mike Frysinger <vapier@gentoo.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
The old code registered the hcd even if there were no transceivers detected, leading to oopses like this if we try to probe a non-existant ULPI: [ 2.730000] mxc-ehci mxc-ehci.0: unable to init transceiver [ 2.740000] timeout polling for ULPI device [ 2.740000] timeout polling for ULPI device [ 2.750000] mxc-ehci mxc-ehci.0: unable to enable vbus on transceiver [ 2.750000] mxc-ehci mxc-ehci.0: Freescale On-Chip EHCI Host Controller [ 2.760000] mxc-ehci mxc-ehci.0: new USB bus registered, assigned bus number 2 [ 2.770000] Unhandled fault: external abort on non-linefetch (0x808) at 0xc4876184 [ 2.770000] Internal error: : 808 [#1] PREEMPT [ 2.770000] last sysfs file: [ 2.770000] Modules linked in: [ 2.770000] CPU: 0 Not tainted (2.6.33.5 #5) [ 2.770000] PC is at ehci_hub_control+0x4d4/0x8f8 [ 2.770000] LR is at ehci_mxc_setup+0xbc/0xdc [ 2.770000] pc : [<c0196dfc>] lr : [<c019bc8c>] psr: 00000093 [ 2.770000] sp : c3815e40 ip : 00000001 fp : 60000013 [ 2.770000] r10: c4876184 r9 : 00000000 r8 : c3814000 [ 2.770000] r7 : c391d2cc r6 : 00000001 r5 : 00000001 r4 : 00000000 [ 2.770000] r3 : 80000000 r2 : 00000007 r1 : 80000000 r0 : c4876184 [ 2.770000] Flags: nzcv IRQs off FIQs on Mode SVC_32 ISA ARM Segment kernel [ 2.770000] Control: 0005317f Table: a0004000 DAC: 00000017 [ 2.770000] Process swapper (pid: 1, stack limit = 0xc3814270) ... Signed-off-by: Wolfram Sang <w.sang@pengutronix.de> Cc: Sascha Hauer <s.hauer@pengutronix.de> Cc: stable <stable@kernel.org> Acked-by: Daniel Mack <daniel@caiaq.de> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
In the change by 749da5f82fe33ff68dd4aa1a5e35cd9aa6246dab, The change in the status when the USB device is connected is wrong. Therefore, the device is not recognized. Acked-by: Alan Stern <stern@rowland.harvard.edu> CC: Yoshihiro Shimoda <shimoda.yoshihiro@renesas.com> CC: Paul Mundt" <lethal@linux-sh.org> Signed-off-by: Nobuhiro Iwamatsu <nobuhiro.iwamatsu.yj@renesas.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Commit 6c12db90f19727c76990e7f4801c67a148b30111 introduced a bug for control transfers. The patch was supposed to change when the link TRBs at the end of each ring segment were given to the hardware. If a transfer descriptor (TD) ended just before the link TRB, the code wouldn't give back the link TRB to the hardware; instead it would be given back in prepare_ring() just before the next TD was enqueued at the top of the ring. Unfortunately, the code relied on checking the chain bit of the TRB to determine whether the TD ended just before the link TRB. It assumed that the ring enqueuing code would call prepare_ring() before enqueuing the next TD. However, control transfers are made of multiple TDs, and prepare_ring() is only called once before enqueuing two or three TDs. If the first or second TD of the control transfer ended just before the link TRB, then the code in inc_enq() would not move the enqueue pointer past the link TRB, and the link TRB would get overwritten. This would cause the xHCI driver to start writing to memory past the ring segment, and eventually the system would crash or hang. The fix is to add a flag to inc_enq() that says whether the caller will enqueue more TDs before calling prepare_ring(). If the chain bit is cleared (meaning this is the last TRB in a TD), and the caller will not enqueue more TDs, then we defer giving back the link TRB. Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Cc: stable <stable@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>