linux/drivers/usb/host, branch v4.7

Merge tag 'mfd-fixes-4.7' of git://git.kernel.org/pub/scm/linux/kernel/git/lee/mfd

2016-06-30T16:44:34Z

Pull MFD fixes from Lee Jones: "Contained are some standard fixes and unusually an extension to the Reset API. Some of those changes are required to fix a bug introduced in -rc1, which introduces extra 'reset line checks' i.e. whether the line is shared or not. If a line is shared and the new *_shared() API is not used, the request fails with an error. This breaks USB in v4.7 for ST's platforms. Admittedly, there are some patches contained in our (MFD/Reset) immutable branch which are not true -fixes, but there isn't anything I can do about that. Rest assured though, there aren't any API 'changes'. Everything is the same from the consumer's perspective. - Use new reset_*_get_shared() variant to prevent reset line obtainment failure (Fixes commit 0b52297f2288: "reset: Add support for shared reset controls") - Fix unintentional switch() fall-through into error path - Fix uninitialised variable compiler warning" * tag 'mfd-fixes-4.7' of git://git.kernel.org/pub/scm/linux/kernel/git/lee/mfd: mfd: da9053: Fix compiler warning message for uninitialised variable mfd: max77620: Fix FPS switch statements phy: phy-stih407-usb: Inform the reset framework that our reset line may be shared usb: dwc3: st: Inform the reset framework that our reset line may be shared usb: host: ehci-st: Inform the reset framework that our reset line may be shared usb: host: ohci-st: Inform the reset framework that our reset line may be shared reset: TRIVIAL: Add line break at same place for similar APIs reset: Supply *_shared variant calls when using *_optional APIs reset: Supply *_shared variant calls when using of_* API reset: Ensure drivers are explicit when requesting reset lines reset: Reorder inline reset_control_get*() wrappers

usb: host: ehci-st: Inform the reset framework that our reset line may be shared

2016-06-30T06:44:21Z

On the STiH410 B2120 development board the ST EHCI IP shares its reset line with the OHCI IP. New functionality in the reset subsystems forces consumers to be explicit when requesting shared/exclusive reset lines. Acked-by: Peter Griffin Acked-by: Alan Stern Signed-off-by: Lee Jones

usb: host: ohci-st: Inform the reset framework that our reset line may be shared

2016-06-30T06:44:20Z

usb: echi-hcd: Add ehci_setup check before echi_shutdown

2016-06-08T05:15:25Z

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:25Z

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:25Z

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:25Z

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: OHCI: Don't mark EDs as ED_OPER if scheduling fails

2016-06-08T05:15:25Z

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: xhci: Add broken streams quirk for Frescologic device id 1009

2016-06-01T21:57:11Z

I got one of these cards for testing uas with, it seems that with streams it dma-s all over the place, corrupting memory. On my first tests it managed to dma over the BIOS of the motherboard somehow and completely bricked it. Tests on another motherboard show that it does work with streams disabled. Cc: stable@vger.kernel.org Signed-off-by: Hans de Goede Signed-off-by: Greg Kroah-Hartman

USB: EHCI: avoid undefined pointer arithmetic and placate UBSAN

2016-06-01T21:56:24Z

Several people have reported that UBSAN doesn't like the pointer arithmetic in ehci_hub_control(): u32 __iomem *status_reg = &ehci->regs->port_status[ (wIndex & 0xff) - 1]; u32 __iomem *hostpc_reg = &ehci->regs->hostpc[(wIndex & 0xff) - 1]; If wIndex is 0 (and it often is), these calculations underflow and UBSAN complains. According to the C standard, pointer computations leading to locations outside the bounds of an array object (other than 1 position past the end) are undefined. In this case, the compiler would be justified in concluding the wIndex can never be 0 and then optimizing away the tests for !wIndex that occur later in the subroutine. (Although, since ehci->regs->port_status and ehci->regs->hostpc are both 0-length arrays and are thus GCC extensions to the C standard, it's not clear what the compiler is really allowed to do.) At any rate, we can avoid all these difficulties, at the cost of making the code slightly longer, by not decrementing the index when it is equal to 0. The runtime effect is minimal, and anyway ehci_hub_control() is not on a hot path. Signed-off-by: Alan Stern Reported-by: Valdis Kletnieks Reported-by: Meelis Roos Reported-by: Martin_MOKREJÅ Reported-by: "Navin P.S" CC: Andrey Ryabinin Signed-off-by: Greg Kroah-Hartman