linux-toradex.git/drivers/usb, branch v4.2.8

xhci: Workaround to get Intel xHCI reset working more reliably

2015-12-09T19:31:26+00:00

commit a5964396190d0c40dd549c23848c282fffa5d1f2 upstream.

Existing Intel xHCI controllers require a delay of 1 mS,
after setting the CMD_RESET bit in command register, before
accessing any HC registers. This allows the HC to complete
the reset operation and be ready for HC register access.
Without this delay, the subsequent HC register access,
may result in a system hang, very rarely.

Verified CherryView / Braswell platforms go through over
5000 warm reboot cycles (which was not possible without
this patch), without any xHCI reset hang.

Signed-off-by: Rajmohan Mani 
Tested-by: Joe Lawrence 
Signed-off-by: Mathias Nyman 
Signed-off-by: Greg Kroah-Hartman

USB: option: add XS Stick W100-2 from 4G Systems

2015-12-09T19:31:24+00:00

commit 638148e20c7f8f6e95017fdc13bce8549a6925e0 upstream.

Thomas reports
"
4gsystems sells two total different LTE-surfsticks under the same name.
..
The newer version of XS Stick W100 is from "omega"
..
Under windows the driver switches to the same ID, and uses MI03\6 for
network and MI01\6 for modem.
..
echo "1c9e 9b01" > /sys/bus/usb/drivers/qmi_wwan/new_id
echo "1c9e 9b01" > /sys/bus/usb-serial/drivers/option1/new_id

T:  Bus=01 Lev=01 Prnt=01 Port=03 Cnt=01 Dev#=  4 Spd=480 MxCh= 0
D:  Ver= 2.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs=  1
P:  Vendor=1c9e ProdID=9b01 Rev=02.32
S:  Manufacturer=USB Modem
S:  Product=USB Modem
S:  SerialNumber=
C:  #Ifs= 5 Cfg#= 1 Atr=80 MxPwr=500mA
I:  If#= 0 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=option
I:  If#= 1 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=ff Driver=option
I:  If#= 2 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=ff Driver=option
I:  If#= 3 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=ff Driver=qmi_wwan
I:  If#= 4 Alt= 0 #EPs= 2 Cls=08(stor.) Sub=06 Prot=50 Driver=usb-storage

Now all important things are there:

wwp0s29f7u2i3 (net), ttyUSB2 (at), cdc-wdm0 (qmi), ttyUSB1 (at)

There is also ttyUSB0, but it is not usable, at least not for at.

The device works well with qmi and ModemManager-NetworkManager.
"

Reported-by: Thomas Schäfer 
Signed-off-by: Bjørn Mork 
Signed-off-by: Greg Kroah-Hartman

USB: serial: option: add support for Novatel MiFi USB620L

2015-12-09T19:31:24+00:00

commit e07af133c3e2716db25e3e1e1d9f10c2088e9c1a upstream.

Also known as Verizon U620L.

The device is modeswitched from 1410:9020 to 1410:9022 by selecting the
4th USB configuration:

 $ sudo usb_modeswitch –v 0x1410 –p 0x9020 –u 4

This configuration provides a ECM interface as well as TTYs ('Enterprise
Mode' according to the U620 Linux integration guide).

Signed-off-by: Aleksander Morgado 
Signed-off-by: Johan Hovold 
Signed-off-by: Greg Kroah-Hartman

USB: ti_usb_3410_5052: Add Honeywell HGI80 ID

2015-12-09T19:31:24+00:00

commit 1bcb49e663f88bccee35b8688e6a3da2bea31fd4 upstream.

The Honeywell HGI80 is a wireless interface to the evohome connected
thermostat. It uses a TI 3410 USB-serial port.

Signed-off-by: David Woodhouse 
Signed-off-by: Johan Hovold 
Signed-off-by: Greg Kroah-Hartman

usb: musb: core: fix order of arguments to ulpi write callback

2015-12-09T19:31:24+00:00

commit 705e63d2b29c8bbf091119084544d353bda70393 upstream.

There is a bit of a mess in the order of arguments to the ulpi write
callback. There is

	int ulpi_write(struct ulpi *ulpi, u8 addr, u8 val)

in drivers/usb/common/ulpi.c;

	struct usb_phy_io_ops {
		...
		int (*write)(struct usb_phy *x, u32 val, u32 reg);
	}

in include/linux/usb/phy.h.

The callback registered by the musb driver has to comply to the latter,
but up to now had "offset" first which effectively made the function
broken for correct users. So flip the order and while at it also
switch to the parameter names of struct usb_phy_io_ops's write.

Fixes: ffb865b1e460 ("usb: musb: add ulpi access operations")
Signed-off-by: Uwe Kleine-König 
Signed-off-by: Felipe Balbi 
Signed-off-by: Greg Kroah-Hartman

USB: qcserial: Fix support for HP lt4112 LTE/HSPA+ Gobi 4G Modem

2015-12-09T19:31:23+00:00

commit 59536da34513c594af2a6fd35ba65ea45b6960a1 upstream.

The DEVICE_HWI type was added under the faulty assumption that Huawei
devices based on Qualcomm chipsets and firmware use the static USB
interface numbering known from Gobi devices.  But this model does
not apply to Huawei devices like the HP branded lt4112 (Huawei me906e).
Huawei firmwares will dynamically assign interface numbers. Functions
are renumbered when the firmware is reconfigured.

Fix by changing the DEVICE_HWI type to use a simplified version
of Huawei's subclass + protocol scheme: Blacklisting known network
interface combinations and assuming the rest are serial.

Reported-and-tested-by: Muri Nicanor 
Tested-by: Martin Hauke 
Fixes: e7181d005e84 ("USB: qcserial: Add support for HP lt4112 LTE/HSPA+ Gobi 4G Modem")
Signed-off-by: Bjørn Mork 
Signed-off-by: Johan Hovold 
Signed-off-by: Greg Kroah-Hartman

USB: qcserial: Add support for Quectel EC20 Mini PCIe module

2015-12-09T19:31:23+00:00

commit 9d5b5ed796d7afd7e8d2ac4b4fb77c6a49463f4b upstream.

It seems like this device has same vendor and product IDs as G2K
devices, but it has different number of interfaces(4 vs 5) and also
different interface layout which makes it currently unusable:

	usbcore: registered new interface driver qcserial
	usbserial: USB Serial support registered for Qualcomm USB modem
	usb 2-1.2: unknown number of interfaces: 5

lsusb output:

	Bus 002 Device 003: ID 05c6:9215 Qualcomm, Inc. Acer Gobi 2000 Wireless
	Device Descriptor:
	  bLength                18
	  bDescriptorType         1
	  bcdUSB               2.00
	  bDeviceClass            0 (Defined at Interface level)
	  bDeviceSubClass         0
	  bDeviceProtocol         0
	  bMaxPacketSize0        64
	  idVendor           0x05c6 Qualcomm, Inc.
	  idProduct          0x9215 Acer Gobi 2000 Wireless Modem
	  bcdDevice            2.32
	  iManufacturer           1 Quectel
	  iProduct                2 Quectel LTE Module
	  iSerial                 0
	  bNumConfigurations      1
	  Configuration Descriptor:
	    bLength                 9
	    bDescriptorType         2
	    wTotalLength          209
	    bNumInterfaces          5
	    bConfigurationValue     1
	    iConfiguration          0
	    bmAttributes         0xa0
	      (Bus Powered)
	      Remote Wakeup
	    MaxPower              500mA

Signed-off-by: Petr Štetiar 
[johan: rename define and add comment ]
Signed-off-by: Johan Hovold 
Signed-off-by: Greg Kroah-Hartman

usblp: do not set TASK_INTERRUPTIBLE before lock

2015-12-09T19:31:23+00:00

commit 19cd80a214821f4b558560ebd76bfb2c38b4f3d8 upstream.

It is not permitted to set task state before lock. usblp_wwait sets
the state to TASK_INTERRUPTIBLE and calls mutex_lock_interruptible.
Upon return from that function, the state will be TASK_RUNNING again.

This is clearly a bug and a warning is generated with LOCKDEP too:
WARNING: CPU: 1 PID: 5109 at kernel/sched/core.c:7404 __might_sleep+0x7d/0x90()
do not call blocking ops when !TASK_RUNNING; state=1 set at [] usblp_wwait+0xa0/0x310 [usblp]
Modules linked in: ...
CPU: 1 PID: 5109 Comm: captmon Tainted: G        W       4.2.5-0.gef2823b-default #1
Hardware name: LENOVO 23252SG/23252SG, BIOS G2ET33WW (1.13 ) 07/24/2012
 ffffffff81a4edce ffff880236ec7ba8 ffffffff81716651 0000000000000000
 ffff880236ec7bf8 ffff880236ec7be8 ffffffff8106e146 0000000000000282
 ffffffff81a50119 000000000000028b 0000000000000000 ffff8802dab7c508
Call Trace:
...
 [] warn_slowpath_fmt+0x46/0x50
 [] __might_sleep+0x7d/0x90
 [] mutex_lock_interruptible_nested+0x2f/0x4b0
 [] usblp_wwait+0xcc/0x310 [usblp]
 [] usblp_write+0x72/0x350 [usblp]
 [] __vfs_write+0x28/0xf0
...

Commit 7f477358e2384c54b190cc3b6ce28277050a041b (usblp: Implement the
ENOSPC convention) moved the set prior locking. So move it back after
the lock.

Signed-off-by: Jiri Slaby 
Fixes: 7f477358e2 ("usblp: Implement the ENOSPC convention")
Acked-By: Pete Zaitcev 
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Greg Kroah-Hartman

usb: ehci-orion: fix probe for !GENERIC_PHY

2015-12-09T19:31:23+00:00

commit db1319e166c5e872c4be54eac4e47454133708cf upstream.

Commit d445913ce0ab7f ("usb: ehci-orion: add optional PHY support")
added support for optional phys, but devm_phy_optional_get returns
-ENOSYS if GENERIC_PHY is not enabled.

This causes probe failures, even when there are no phys specified:

[    1.443365] orion-ehci f1058000.usb: init f1058000.usb fail, -38
[    1.449403] orion-ehci: probe of f1058000.usb failed with error -38

Similar to dwc3, treat -ENOSYS as no phy.

Fixes: d445913ce0ab7f ("usb: ehci-orion: add optional PHY support")

Signed-off-by: Jonas Gorski 
Acked-by: Alan Stern 
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Greg Kroah-Hartman

usb: chipidea: imx: refine clock operations to adapt for all platforms

2015-12-09T19:31:22+00:00

commit ae3e57ae26cdcc85728bb566f999bcb9a7cc6954 upstream.

Some i.mx platforms need three clocks to let controller work, but
others only need one, refine clock operation to adapt for all
platforms, it fixes a regression found at i.mx27.

Signed-off-by: Peter Chen 
Tested-by: Fabio Estevam 
Signed-off-by: Greg Kroah-Hartman