linux-stable.git/drivers/usb, branch v4.9.162

usb: gadget: Potential NULL dereference on allocation error

2019-03-05T16:57:04+00:00

[ Upstream commit df28169e1538e4a8bcd8b779b043e5aa6524545c ]

The source_sink_alloc_func() function is supposed to return error
pointers on error.  The function is called from usb_get_function() which
doesn't check for NULL returns so it would result in an Oops.

Of course, in the current kernel, small allocations always succeed so
this doesn't affect runtime.

Signed-off-by: Dan Carpenter 
Signed-off-by: Felipe Balbi 
Signed-off-by: Sasha Levin

usb: dwc3: gadget: Fix the uninitialized link_state when udc starts

2019-03-05T16:57:04+00:00

[ Upstream commit 88b1bb1f3b88e0bf20b05d543a53a5b99bd7ceb6 ]

Currently the link_state is uninitialized and the default value is 0(U0)
before the first time we start the udc, and after we start the udc then
 stop the udc, the link_state will be undefined.
We may have the following warnings if we start the udc again with
an undefined link_state:

WARNING: CPU: 0 PID: 327 at drivers/usb/dwc3/gadget.c:294 dwc3_send_gadget_ep_cmd+0x304/0x308
dwc3 100e0000.hidwc3_0: wakeup failed --> -22
[...]
Call Trace:
[] (unwind_backtrace) from [] (show_stack+0x10/0x14)
[] (show_stack) from [] (dump_stack+0x84/0x98)
[] (dump_stack) from [] (__warn+0xe8/0x100)
[] (__warn) from [](warn_slowpath_fmt+0x38/0x48)
[] (warn_slowpath_fmt) from [](dwc3_send_gadget_ep_cmd+0x304/0x308)
[] (dwc3_send_gadget_ep_cmd) from [](dwc3_ep0_start_trans+0x48/0xf4)
[] (dwc3_ep0_start_trans) from [](dwc3_ep0_out_start+0x64/0x80)
[] (dwc3_ep0_out_start) from [](__dwc3_gadget_start+0x1e0/0x278)
[] (__dwc3_gadget_start) from [](dwc3_gadget_start+0x88/0x10c)
[] (dwc3_gadget_start) from [](udc_bind_to_driver+0x88/0xbc)
[] (udc_bind_to_driver) from [](usb_gadget_probe_driver+0xf8/0x140)
[] (usb_gadget_probe_driver) from [](gadget_dev_desc_UDC_store+0xac/0xc4 [libcomposite])
[] (gadget_dev_desc_UDC_store [libcomposite]) from[] (configfs_write_file+0xd4/0x160)
[] (configfs_write_file) from [] (__vfs_write+0x1c/0x114)
[] (__vfs_write) from [] (vfs_write+0xa4/0x168)
[] (vfs_write) from [] (SyS_write+0x3c/0x90)
[] (SyS_write) from [] (ret_fast_syscall+0x0/0x3c)

Signed-off-by: Zeng Tao 
Signed-off-by: Felipe Balbi 
Signed-off-by: Sasha Levin

usb: dwc3: gadget: synchronize_irq dwc irq in suspend

2019-03-05T16:57:04+00:00

[ Upstream commit 01c10880d24291a96a4ab0da773e3c5ce4d12da8 ]

We see dwc3 endpoint stopped by unwanted irq during
suspend resume test, which is caused dwc3 ep can't be started
with error "No Resource".

Here, add synchronize_irq before suspend to sync the
pending IRQ handlers complete.

Signed-off-by: Bo He 
Signed-off-by: Yu Wang 
Signed-off-by: Felipe Balbi 
Signed-off-by: Sasha Levin

usb: dwc2: Remove unnecessary kfree

2019-02-20T09:18:34+00:00

commit cd4b1e34655d46950c065d9284b596cd8d7b28cd upstream.

This shouldn't be freed by the HCD as it is owned by the core and
allocated with devm_kzalloc.

Signed-off-by: John Youn 
Signed-off-by: Felipe Balbi 
Signed-off-by: Linus Walleij 
Signed-off-by: Greg Kroah-Hartman

usb: gadget: musb: fix short isoc packets with inventra dma

2019-02-12T18:45:01+00:00

commit c418fd6c01fbc5516a2cd1eaf1df1ec86869028a upstream.

Handling short packets (length < max packet size) in the Inventra DMA
engine in the MUSB driver causes the MUSB DMA controller to hang. An
example of a problem that is caused by this problem is when streaming
video out of a UVC gadget, only the first video frame is transferred.

For short packets (mode-0 or mode-1 DMA), MUSB_TXCSR_TXPKTRDY must be
set manually by the driver. This was previously done in musb_g_tx
(musb_gadget.c), but incorrectly (all csr flags were cleared, and only
MUSB_TXCSR_MODE and MUSB_TXCSR_TXPKTRDY were set). Fixing that problem
allows some requests to be transferred correctly, but multiple requests
were often put together in one USB packet, and caused problems if the
packet size was not a multiple of 4. Instead, set MUSB_TXCSR_TXPKTRDY
in dma_controller_irq (musbhsdma.c), just like host mode transfers.

This topic was originally tackled by Nicolas Boichat [0] [1] and is
discussed further at [2] as part of his GSoC project [3].

[0] https://groups.google.com/forum/?hl=en#!topic/beagleboard-gsoc/k8Azwfp75CU
[1] https://gitorious.org/beagleboard-usbsniffer/beagleboard-usbsniffer-kernel/commit/b0be3b6cc195ba732189b04f1d43ec843c3e54c9?p=beagleboard-usbsniffer:beagleboard-usbsniffer-kernel.git;a=patch;h=b0be3b6cc195ba732189b04f1d43ec843c3e54c9
[2] http://beagleboard-usbsniffer.blogspot.com/2010/07/musb-isochronous-transfers-fixed.html
[3] http://elinux.org/BeagleBoard/GSoC/USBSniffer

Fixes: 550a7375fe72 ("USB: Add MUSB and TUSB support")
Signed-off-by: Paul Elder 
Signed-off-by: Bin Liu 
Cc: stable 
Signed-off-by: Greg Kroah-Hartman

usb: gadget: udc: net2272: Fix bitwise and boolean operations

2019-02-12T18:45:01+00:00

commit 07c69f1148da7de3978686d3af9263325d9d60bd upstream.

(!x & y) strikes again.

Fix bitwise and boolean operations by enclosing the expression:

	intcsr & (1 << NET2272_PCI_IRQ)

in parentheses, before applying the boolean operator '!'.

Notice that this code has been there since 2011. So, it would
be helpful if someone can double-check this.

This issue was detected with the help of Coccinelle.

Fixes: ceb80363b2ec ("USB: net2272: driver for PLX NET2272 USB device controller")
Cc: stable@vger.kernel.org
Signed-off-by: Gustavo A. R. Silva 
Signed-off-by: Felipe Balbi 
Signed-off-by: Greg Kroah-Hartman

usb: phy: am335x: fix race condition in _probe

2019-02-12T18:45:01+00:00

commit a53469a68eb886e84dd8b69a1458a623d3591793 upstream.

power off the phy should be done before populate the phy. Otherwise,
am335x_init() could be called by the phy owner to power on the phy first,
then am335x_phy_probe() turns off the phy again without the caller knowing
it.

Fixes: 2fc711d76352 ("usb: phy: am335x: Enable USB remote wakeup using PHY wakeup")
Cc: stable@vger.kernel.org # v3.18+
Signed-off-by: Bin Liu 
Signed-off-by: Felipe Balbi 
Signed-off-by: Greg Kroah-Hartman

usb: hub: delay hub autosuspend if USB3 port is still link training

2019-02-12T18:44:54+00:00

[ Upstream commit e86108940e541febf35813402ff29fa6f4a9ac0b ]

When initializing a hub we want to give a USB3 port in link training
the same debounce delay time before autosuspening the hub as already
trained, connected enabled ports.

USB3 ports won't reach the enabled state with "current connect status" and
"connect status change" bits set until the USB3 link training finishes.

Catching the port in link training (polling) and adding the debounce delay
prevents unnecessary failed attempts to autosuspend the hub.

Signed-off-by: Mathias Nyman 
Acked-by: Alan Stern 
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Sasha Levin

USB: serial: pl2303: add new PID to support PL2303TB

2019-01-31T07:12:33+00:00

commit 4dcf9ddc9ad5ab649abafa98c5a4d54b1a33dabb upstream.

Add new PID to support PL2303TB (TYPE_HX)

Signed-off-by: Charles Yeh 
Cc: stable 
Signed-off-by: Johan Hovold 
Signed-off-by: Greg Kroah-Hartman

USB: serial: simple: add Motorola Tetra TPG2200 device id

2019-01-31T07:12:33+00:00

commit b81c2c33eab79dfd3650293b2227ee5c6036585c upstream.

Add new Motorola Tetra device id for Motorola Solutions TETRA PEI device

T:  Bus=02 Lev=01 Prnt=01 Port=01 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=0cad ProdID=9016 Rev=24.16
S:  Manufacturer=Motorola Solutions, Inc.
S:  Product=TETRA PEI interface
C:  #Ifs= 2 Cfg#= 1 Atr=80 MxPwr=500mA
I:  If#= 0 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=00 Prot=00 Driver=usb_serial_simple
I:  If#= 1 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=00 Prot=00 Driver=usb_serial_simple

Signed-off-by: Max Schulze 
Cc: stable 
Signed-off-by: Johan Hovold 
Signed-off-by: Greg Kroah-Hartman