linux.git/drivers/usb/host, branch v2.6.35-rc4 Clone of https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git USB: isp1362-hcd, fix double lock 2010-06-30T15:16:06+00:00 Jiri Slaby jslaby@suse.cz 2010-06-21T15:02:51+00:00 1c815577823951ff082fe1201fdd5efec5e6e8ea 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> 
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>
USB: ehci-mxc: bail out on transceiver problems 2010-06-30T15:16:06+00:00 Wolfram Sang w.sang@pengutronix.de 2010-06-15T10:34:23+00:00 4c9715de52b9b6256bf1e9510917111a47b0c176 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> 
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>
USB: r8a66597: Fix failure in change of status 2010-06-30T15:16:05+00:00 Nobuhiro Iwamatsu nobuhiro.iwamatsu.yj@renesas.com 2010-06-07T07:55:56+00:00 a5797a686f4c7cbced782959509d735cfa1344b1 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> 
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>
USB: xHCI: Fix bug in link TRB activation change. 2010-06-30T15:16:05+00:00 Sarah Sharp sarah.a.sharp@linux.intel.com 2010-06-10T19:25:28+00:00 6cc30d85a5bf61248ff0e1f0e0f15fe718bae378 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> 
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>
Merge git://git.kernel.org/pub/scm/linux/kernel/git/lethal/sh-2.6 2010-06-04T22:42:09+00:00 Linus Torvalds torvalds@linux-foundation.org 2010-06-04T22:42:09+00:00 999fd1ab344dabd9c985b638bf4c29495b8e4619 * git://git.kernel.org/pub/scm/linux/kernel/git/lethal/sh-2.6: (23 commits) sh: Make intc messages consistent via pr_fmt. sh: make sure static declaration on ms7724se sh: make sure static declaration on mach-migor sh: make sure static declaration on mach-ecovec24 sh: make sure static declaration on mach-ap325rxa clocksource: sh_cmt: compute mult and shift before registration clocksource: sh_tmu: compute mult and shift before registration sh: PIO disabling for x3proto and urquell. sh: mach-sdk7786: conditionally disable PIO support. sh: support for platforms without PIO. usb: r8a66597-hcd pio to mmio accessor conversion. usb: gadget: r8a66597-udc pio to mmio accessor conversion. usb: gadget: m66592-udc pio to mmio accessor conversion. sh: add romImage MMCIF boot for sh7724 and Ecovec V2 sh: add boot code to MMCIF driver header sh: prepare MMCIF driver header file sh: allow romImage data between head.S and the zero page sh: Add support MMCIF for ecovec sh: remove duplicated #include input: serio: disable i8042 for non-cayman sh platforms. ... 
* git://git.kernel.org/pub/scm/linux/kernel/git/lethal/sh-2.6: (23 commits)
  sh: Make intc messages consistent via pr_fmt.
  sh: make sure static declaration on ms7724se
  sh: make sure static declaration on mach-migor
  sh: make sure static declaration on mach-ecovec24
  sh: make sure static declaration on mach-ap325rxa
  clocksource: sh_cmt: compute mult and shift before registration
  clocksource: sh_tmu: compute mult and shift before registration
  sh: PIO disabling for x3proto and urquell.
  sh: mach-sdk7786: conditionally disable PIO support.
  sh: support for platforms without PIO.
  usb: r8a66597-hcd pio to mmio accessor conversion.
  usb: gadget: r8a66597-udc pio to mmio accessor conversion.
  usb: gadget: m66592-udc pio to mmio accessor conversion.
  sh: add romImage MMCIF boot for sh7724 and Ecovec V2
  sh: add boot code to MMCIF driver header
  sh: prepare MMCIF driver header file
  sh: allow romImage data between head.S and the zero page
  sh: Add support MMCIF for ecovec
  sh: remove duplicated #include
  input: serio: disable i8042 for non-cayman sh platforms.
  ...
usb: fix ehci_hcd build failure when both generic-OF and xilinx is selected 2010-06-04T20:16:19+00:00 Grant Likely grant.likely@secretlab.ca 2010-06-02T19:53:17+00:00 1f23b2d98c11fed43c552a5dbd00c793f81a8736 This patch fixes the driver to allow both CONFIG_USB_EHCI_HCD_PPC_OF and CONFIG_USB_ECHI_HCD_XILINX to be selected. Signed-off-by: Grant Likely <grant.likely@secretlab.ca> CC: John Linn <john.linn@xilinx.com> CC: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> 
This patch fixes the driver to allow both CONFIG_USB_EHCI_HCD_PPC_OF and
CONFIG_USB_ECHI_HCD_XILINX to be selected.

Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
CC: John Linn <john.linn@xilinx.com>
CC: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
USB: xhci: Print NEC firmware version. 2010-06-04T20:16:19+00:00 Sarah Sharp sarah.a.sharp@linux.intel.com 2010-05-24T20:25:28+00:00 0238634d02dd10b678ebe9ea5d8803483277ee93 The NEC xHCI host controller firmware version can be found by putting a vendor-specific command on the command ring and extracting the BCD encoded-version out of the vendor-specific event TRB. The firmware version debug line in dmesg will look like: xhci_hcd 0000:05:00.0: NEC firmware version 30.21 (NEC merged with Renesas Technologies and became Renesas Electronics on April 1, 2010. I have their OK to merge this vendor-specific code.) Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Cc: Satoshi Otani <satoshi.otani.xm@renesas.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> 
The NEC xHCI host controller firmware version can be found by putting a
vendor-specific command on the command ring and extracting the BCD
encoded-version out of the vendor-specific event TRB.

The firmware version debug line in dmesg will look like:

xhci_hcd 0000:05:00.0: NEC firmware version 30.21

(NEC merged with Renesas Technologies and became Renesas Electronics on
April 1, 2010.  I have their OK to merge this vendor-specific code.)

Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Cc: Satoshi Otani <satoshi.otani.xm@renesas.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
USB: xhci: Wait for host to start running. 2010-06-04T20:16:19+00:00 Sarah Sharp sarah.a.sharp@linux.intel.com 2010-05-24T20:25:21+00:00 ed07453fd356025cc25272629e982f5e4607632c When the run bit is set in the xHCI command register, it may take a few microseconds for the host to start running. We cannot ring any doorbells until the host is actually running, so wait until the status register says the host is running. Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Reported-by: Shinya Saito <shinya.saito.sx@renesas.com> Cc: stable <stable@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> 
When the run bit is set in the xHCI command register, it may take a few
microseconds for the host to start running.  We cannot ring any doorbells
until the host is actually running, so wait until the status register says
the host is running.

Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Reported-by: Shinya Saito <shinya.saito.sx@renesas.com>
Cc: stable <stable@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
USB: xhci: Wait for controller to be ready after reset. 2010-06-04T20:16:18+00:00 Sarah Sharp sarah.a.sharp@linux.intel.com 2010-05-24T20:25:15+00:00 2d62f3eea98354d61f90d6b115eecf9be5f4bdfe After software resets an xHCI host controller, it must wait for the "Controller Not Ready" (CNR) bit in the status register to be cleared. Software is not supposed to ring any doorbells or write to any registers except the status register until this bit is cleared. 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> 
After software resets an xHCI host controller, it must wait for the
"Controller Not Ready" (CNR) bit in the status register to be cleared.
Software is not supposed to ring any doorbells or write to any registers
except the status register until this bit is cleared.

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>
USB: isp1362: fix inw warning on Blackfin systems 2010-06-04T20:16:18+00:00 Mike Frysinger vapier@gentoo.org 2010-05-21T08:37:42+00:00 0c8a32dff4f9ebed3e067e52e12842d7d7e047a0 The Blackfin code is incorrectly casting the argument to inw() to a pointer. Signed-off-by: Mike Frysinger <vapier@gentoo.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> 
The Blackfin code is incorrectly casting the argument to inw() to a pointer.

Signed-off-by: Mike Frysinger <vapier@gentoo.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>