linux.git/drivers/usb, branch v4.7-rc4

usbip: rate limit get_frame_number message

2016-06-18T01:00:46+00:00

It's annoying to constantly see the same "Not yet implemented" message
over and over with nothing able to be done about it, so rate limit it
for now to keep user's logs "clean".

Reported-by: Lars Täuber 
Tested-by: Lars Täuber 
Signed-off-by: Greg Kroah-Hartman

usb: musb: sunxi: Remove bogus "Frees glue" comment

2016-06-14T20:36:23+00:00

The comment is wrong, glue is devm_kzalloc-ed mem attached to the
"allwinner,sun4i-a10-musb" compatible platform-dev. Where as
glue->musb_pdev is a newly created "musb-hdrc" platform-dev.

Signed-off-by: Hans de Goede 
[b-liu@ti.com: revise subject prefix]
Signed-off-by: Bin Liu 
Signed-off-by: Greg Kroah-Hartman

usb: musb: sunxi: Fix NULL ptr deref when gadget is registered before musb

2016-06-14T20:36:23+00:00

Stop using the return value of platform_device_register_full() to get to
the struct musb in sunxi_musb_work(). If a gadget has been registered
(insmod-ed) before the musb driver, then musb_start will get called
from the musb_core probe function and sunxi_musb_work() may run before
platform_device_register_full() has returned.

Instead store a pointer to struct musb in struct sunxi_glue when
sunxi_musb_enable gets called. Note that sunxi_musb_enable always gets
called before sunxi_musb_work() can run.

Signed-off-by: Hans de Goede 
[b-liu@ti.com: revise subject prefix]
Signed-off-by: Bin Liu 
Signed-off-by: Greg Kroah-Hartman

usb: echi-hcd: Add ehci_setup check before echi_shutdown

2016-06-08T05:15:25+00:00

This patch protects system from crashing at shutdown in
cases where usb host is not added yet from OTG controller driver.
As ehci_setup() not done yet, so stop accessing registers or
variables initialized as part of ehci_setup().

The use case is simple, for boards like DB410c where the usb host
or device functionality is decided based on the micro-usb cable
presence. If the board boots up with micro-usb connected, the
OTG driver like echi-msm would not add the usb host by default.
However a system shutdown would go and access registers and
uninitialized variables, resulting in below crash.

Unable to handle kernel NULL pointer dereference at virtual address
 00000008
pgd = ffffffc034581000
[00000008] *pgd=0000000000000000, *pud=0000000000000000
CPU: 2 PID: 1957 Comm: reboot Not tainted 4.6.0+ #99
task: ffffffc034bc0000 ti: ffffffc0345cc000 task.ti: ffffffc0345cc000
PC is at ehci_halt+0x54/0x108
LR is at ehci_halt+0x38/0x108
pc : [] lr : [] pstate: a00001c5
sp : ffffffc0345cfc60
x29: ffffffc0345cfc60 x28: ffffffc0345cc000
x27: ffffff8008a4d000 x26: 000000000000008e
x25: ffffff8008d86cb0 x24: ffffff800908b040
x23: ffffffc036068870 x22: ffffff8009d0a000
x21: ffffffc03512a410 x20: ffffffc03512a410
x19: ffffffc03512a338 x18: 00000000000065ba
x17: ffffff8009b16b80 x16: 0000000000000003
x15: 00000000000065b9 x14: 00000000000065b6
x13: 0000000000000000 x12: 0000000000000000
x11: 000000000000003d x10: ffffffc0345cf9e0
x9 : 0000000000000001 x8 : ffffffc0345cc000
x7 : ffffff8008698360 x6 : 0000000000000000
x5 : 0000000000000080 x4 : 0000000000000001
x3 : 0000000000000000 x2 : 0000000000000000
x1 : 0000000000000008 x0 : ffffffc034bc0000

Process reboot (pid: 1957, stack limit = 0xffffffc0345cc020)
Stack: (0xffffffc0345cfc60 to 0xffffffc0345d0000)
fc60: ffffffc0345cfc90 ffffff8008698448 ffffffc03512a338 ffffffc03512a338
fc80: ffffffc03512a410 ffffff8008a3bbfc ffffffc0345cfcc0 ffffff8008698548
fca0: ffffffc03512a338 ffffffc03512a000 ffffffc03512a410 ffffff8009d0a000
fcc0: ffffffc0345cfcf0 ffffff800865d2bc ffffffc036068828 ffffffc036068810
fce0: ffffffc036003810 ffffff800853f43c ffffffc0345cfd00 ffffff800854338c
fd00: ffffffc0345cfd10 ffffff800853f45c ffffffc0345cfd60 ffffff80080e0f48
fd20: 0000000000000000 0000000001234567 ffffff8008f8c000 ffffff8008f8c060
fd40: 0000000000000000 0000000000000015 0000000000000120 ffffff80080e0f30
fd60: ffffffc0345cfd70 ffffff80080e1020 ffffffc0345cfd90 ffffff80080e12fc
fd80: 0000000000000000 0000000001234567 0000000000000000 ffffff8008085e70
fda0: 0000000000000000 0000005592905000 ffffffffffffffff 0000007f79daf1cc
fdc0: 0000000000000000 0000000000000000 0000007ffcbb1198 000000000000000a
fde0: 00000055928d3f58 0000000000000001 ffffffc034900000 00000000fffffffe
fe00: ffffffc034900000 0000007f79da902c ffffffc0345cfe40 ffffff800820af38
fe20: 0000000000000000 0000007ffcbb1078 ffffffffffffffff ffffff80081e9b38
fe40: ffffffc0345cfe60 ffffff80081eb410 ffffffc0345cfe60 ffffff80081eb444
fe60: ffffffc0345cfec0 ffffff80081ec4f4 0000000000000000 0000007ffcbb1078
fe80: ffffffffffffffff 0000000000000015 ffffffc0345cfec0 0000007ffcbb1078
fea0: 0000000000000002 000000000000000a ffffffffffffffff 0000000000000000
fec0: 0000000000000000 ffffff8008085e70 fffffffffee1dead 0000000028121969
fee0: 0000000001234567 0000000000000000 ffffffffffffffff 8080800000800000
ff00: 0000800000808080 0000007ffcbb10f0 000000000000008e fefeff54918cb8c7
ff20: 7f7f7f7fffffffff 0101010101010101 0000000000000010 0000000000000000
ff40: 0000000000000000 0000007f79e33588 0000005592905eb8 0000007f79daf1b0
ff60: 0000007ffcbb1340 0000005592906000 0000005592905000 0000005592906000
ff80: 0000005592907000 0000000000000002 0000007ffcbb1d98 0000005592906000
ffa0: 00000055928d2000 0000000000000000 0000000000000000 0000007ffcbb1aa0
ffc0: 00000055928b819c 0000007ffcbb1aa0 0000007f79daf1cc 0000000000000000
ffe0: fffffffffee1dead 000000000000008e 05ef555057155555 d555544d55d775d3
Call trace:
Exception stack(0xffffffc0345cfaa0 to 0xffffffc0345cfbc0)
Set corner to 6
faa0: ffffffc03512a338 ffffffc03512a410 ffffffc0345cfc60 ffffff800869837c
fac0: ffffff8008114210 0000000100000001 ffffff8009ce1b20 ffffff8009ce5f20
fae0: ffffffc0345cfb80 ffffff80081145a8 ffffffc0345cfc10 ffffff800810b924
fb00: ffffffc0345cc000 00000000000001c0 ffffffc03512a410 ffffff8009d0a000
fb20: ffffffc036068870 ffffff800908b040 ffffff8008d86cb0 000000000000008e
fb40: ffffffc034bc0000 0000000000000008 0000000000000000 0000000000000000
fb60: 0000000000000001 0000000000000080 0000000000000000 ffffff8008698360
fb80: ffffffc0345cc000 0000000000000001 ffffffc0345cf9e0 000000000000003d
fba0: 0000000000000000 0000000000000000 00000000000065b6 00000000000065b9
[] ehci_halt+0x54/0x108
[] ehci_silence_controller+0x18/0xcc
[] ehci_shutdown+0x4c/0x64
[] usb_hcd_platform_shutdown+0x1c/0x24
[] platform_drv_shutdown+0x20/0x28
[] device_shutdown+0xf4/0x1b0
[] kernel_restart_prepare+0x34/0x3c
[] kernel_restart+0x14/0x74
[] SyS_reboot+0x110/0x21c
[] el0_svc_naked+0x24/0x28
Code: 53001c42 350000a2 d5033e9f 91002021 (b9000022)

Fixes 4bb3cad7125b ("usb: host: ehci-msm: Register usb shutdown function")
Signed-off-by: Srinivas Kandagatla 
Tested-by: Pramod Gurav 
Tested-by: Andy Gross 
Acked-by: Alan Stern 
Signed-off-by: Greg Kroah-Hartman

usb: host: ehci-msm: Conditionally call ehci suspend/resume

2016-06-08T05:15:25+00:00

This patch fixes a suspend/resume issue where the driver is blindly
calling ehci_suspend/resume functions when the ehci hasn't been setup.
This results in a crash during suspend/resume operations.

Signed-off-by: Andy Gross 
Tested-by: Pramod Gurav 
Acked-by: Alan Stern 
Signed-off-by: Greg Kroah-Hartman

usb: host: ehci-tegra: Avoid getting the same reset twice

2016-06-08T05:15:25+00:00

Starting with commit 0b52297f2288 ("reset: Add support for shared reset
controls") there is a reference count for reset control assertions. The
goal is to allow resets to be shared by multiple devices and an assert
will take effect only when all instances have asserted the reset.

In order to preserve backwards-compatibility, all reset controls become
exclusive by default. This is to ensure that reset_control_assert() can
immediately assert in hardware.

However, this new behaviour triggers the following warning in the EHCI
driver for Tegra:

[    3.365019] ------------[ cut here ]------------
[    3.369639] WARNING: CPU: 0 PID: 1 at drivers/reset/core.c:187 __of_reset_control_get+0x16c/0x23c
[    3.382151] Modules linked in:
[    3.385214] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.6.0-rc6-next-20160503 #140
[    3.392769] Hardware name: NVIDIA Tegra SoC (Flattened Device Tree)
[    3.399046] [] (unwind_backtrace) from [] (show_stack+0x10/0x14)
[    3.406787] [] (show_stack) from [] (dump_stack+0x90/0xa4)
[    3.414007] [] (dump_stack) from [] (__warn+0xe8/0x100)
[    3.420964] [] (__warn) from [] (warn_slowpath_null+0x20/0x28)
[    3.428525] [] (warn_slowpath_null) from [] (__of_reset_control_get+0x16c/0x23c)
[    3.437648] [] (__of_reset_control_get) from [] (tegra_ehci_probe+0x394/0x518)
[    3.446600] [] (tegra_ehci_probe) from [] (platform_drv_probe+0x4c/0xb0)
[    3.455029] [] (platform_drv_probe) from [] (driver_probe_device+0x1ec/0x330)
[    3.463892] [] (driver_probe_device) from [] (__driver_attach+0xb8/0xbc)
[    3.472320] [] (__driver_attach) from [] (bus_for_each_dev+0x68/0x9c)
[    3.480489] [] (bus_for_each_dev) from [] (bus_add_driver+0x1a0/0x218)
[    3.488743] [] (bus_add_driver) from [] (driver_register+0x78/0xf8)
[    3.496738] [] (driver_register) from [] (do_one_initcall+0x40/0x170)
[    3.504909] [] (do_one_initcall) from [] (kernel_init_freeable+0x158/0x1f8)
[    3.513600] [] (kernel_init_freeable) from [] (kernel_init+0x8/0x114)
[    3.521770] [] (kernel_init) from [] (ret_from_fork+0x14/0x3c)
[    3.529361] ---[ end trace 4bda87dbe4ecef8a ]---

The reason is that Tegra SoCs have three EHCI controllers, each with a
separate reset line. However the first controller contains UTMI pads
configuration registers that are shared with its siblings and that are
reset as part of the first controller's reset. There is special code in
the driver to assert and deassert this shared reset at probe time, and
it does so irrespective of which controller is probed first to ensure
that these shared registers are reset before any of the controllers are
initialized. Unfortunately this means that if the first controller gets
probed first, it will request its own reset line and will subsequently
request the same reset line again (temporarily) to perform the reset.
This used to work fine before the above-mentioned commit, but now
triggers the new WARN.

Work around this by making sure we reuse the controller's reset if the
controller happens to be the first controller.

Cc: Philipp Zabel 
Cc: Hans de Goede 
Reviewed-by: Philipp Zabel 
Signed-off-by: Thierry Reding 
Signed-off-by: Greg Kroah-Hartman

usb: host: ehci-tegra: Grab the correct UTMI pads reset

2016-06-08T05:15:25+00:00

There are three EHCI controllers on Tegra SoCs, each with its own reset
line. However, the first controller contains a set of UTMI configuration
registers that are shared with its siblings. These registers will only
be reset as part of the first controller's reset. For proper operation
it must be ensured that the UTMI configuration registers are reset
before any of the EHCI controllers are enabled, irrespective of the
probe order.

Commit a47cc24cd1e5 ("USB: EHCI: tegra: Fix probe order issue leading to
broken USB") introduced code that ensures the first controller is always
reset before setting up any of the controllers, and is never again reset
afterwards.

This code, however, grabs the wrong reset. Each EHCI controller has two
reset controls attached: 1) the USB controller reset and 2) the UTMI
pads reset (really the first controller's reset). In order to reset the
UTMI pads registers the code must grab the second reset, but instead it
grabbing the first.

Fixes: a47cc24cd1e5 ("USB: EHCI: tegra: Fix probe order issue leading to broken USB")
Acked-by: Jon Hunter 
Cc: stable@vger.kernel.org
Signed-off-by: Thierry Reding 
Signed-off-by: Greg Kroah-Hartman

USB: mos7720: delete parport

2016-06-08T05:15:25+00:00

parport subsystem has introduced parport_del_port() to delete a port
when it is going away. Without parport_del_port() the registered port
will not be unregistered.
To reproduce and verify the error:
Command to be used is : ls /sys/bus/parport/devices
1) without the device attached there is no output as there is no
registered parport.
2) Attach the device, and the command will show "parport0".
3) Remove the device and the command still shows "parport0".
4) Attach the device again and we get "parport1".

With the patch applied:
1) without the device attached there is no output as there is no
registered parport.
2) Attach the device, and the command will show "parport0".
3) Remove the device and there is no output as "parport0" is now
removed.
4) Attach device again to get "parport0" again.

Cc:  # 4.2+
Signed-off-by: Sudip Mukherjee 
Signed-off-by: Greg Kroah-Hartman

USB: OHCI: Don't mark EDs as ED_OPER if scheduling fails

2016-06-08T05:15:25+00:00

Since ed_schedule begins with marking the ED as "operational",
the ED may be left in such state even if scheduling actually
fails.

This allows future submission attempts to smuggle this ED to the
hardware behind the scheduler's back and without linking it to
the ohci->eds_in_use list.

The former causes bandwidth saturation and data loss on isoc
endpoints, the latter crashes the kernel when attempt is made
to unlink such ED from this list.

Fix ed_schedule to update ED state only on successful return.

Signed-off-by: Michal Pecio 
Acked-by: Alan Stern 
Signed-off-by: Greg Kroah-Hartman

usb: musb: Stop bulk endpoint while queue is rotated

2016-06-01T21:58:59+00:00

Ensure that the endpoint is stopped by clearing REQPKT before
clearing DATAERR_NAKTIMEOUT before rotating the queue on the
dedicated bulk endpoint.
This addresses an issue where a race could result in the endpoint
receiving data before it was reprogrammed resulting in a warning
about such data from musb_rx_reinit before it was thrown away.
The data thrown away was a valid packet that had been correctly
ACKed which meant the host and device got out of sync.

Signed-off-by: Andrew Goodbody 
Cc: stable@vger.kernel.org
Signed-off-by: Bin Liu 
Signed-off-by: Greg Kroah-Hartman