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

USB: Fix: Don't skip endpoint descriptors with maxpacket=0

2020-01-14T19:03:06+00:00

commit 2548288b4fb059b2da9ceada172ef763077e8a59 upstream.

It turns out that even though endpoints with a maxpacket length of 0
aren't useful for data transfer, the descriptors do serve other
purposes.  In particular, skipping them will also skip over other
class-specific descriptors for classes such as UVC.  This unexpected
side effect has caused some UVC cameras to stop working.

In addition, the USB spec requires that when isochronous endpoint
descriptors are present in an interface's altsetting 0 (which is true
on some devices), the maxpacket size _must_ be set to 0.  Warning
about such things seems like a bad idea.

This patch updates an earlier commit which would log a warning and
skip these endpoint descriptors.  Now we only log a warning, and we
don't even do that for isochronous endpoints in altsetting 0.

We don't need to worry about preventing endpoints with maxpacket = 0
from ever being used for data transfers; usb_submit_urb() already
checks for this.

Reported-and-tested-by: Roger Whittaker 
Fixes: d482c7bb0541 ("USB: Skip endpoints with 0 maxpacket length")
Signed-off-by: Alan Stern 
CC: Laurent Pinchart 
Link: https://marc.info/?l=linux-usb&m=157790377329882&w=2
Link: https://lore.kernel.org/r/Pine.LNX.4.44L0.2001061040270.1514-100000@iolanthe.rowland.org
Signed-off-by: Greg Kroah-Hartman

usb: musb: dma: Correct parameter passed to IRQ handler

2020-01-14T19:03:05+00:00

commit c80d0f4426c7fdc7efd6ae8d8b021dcfc89b4254 upstream.

The IRQ handler was passed a pointer to a struct dma_controller, but the
argument was then casted to a pointer to a struct musb_dma_controller.

Fixes: 427c4f333474 ("usb: struct device - replace bus_id with dev_name(), dev_set_name()")
Signed-off-by: Paul Cercueil 
Tested-by: Artur Rojek 
Cc: stable@vger.kernel.org
Signed-off-by: Bin Liu 
Link: https://lore.kernel.org/r/20191216161844.772-2-b-liu@ti.com
Signed-off-by: Greg Kroah-Hartman

usb: musb: Disable pullup at init

2020-01-14T19:03:04+00:00

commit 96a0c12843109e5c4d5eb1e09d915fdd0ce31d25 upstream.

The pullup may be already enabled before the driver is initialized. This
happens for instance on JZ4740.

It has to be disabled at init time, as we cannot guarantee that a gadget
driver will be bound to the UDC.

Signed-off-by: Paul Cercueil 
Suggested-by: Bin Liu 
Cc: stable@vger.kernel.org
Signed-off-by: Bin Liu 
Link: https://lore.kernel.org/r/20200107152625.857-3-b-liu@ti.com
Signed-off-by: Greg Kroah-Hartman

USB: serial: option: add ZLP support for 0x1bc7/0x9010

2020-01-14T19:03:04+00:00

commit 2438c3a19dec5e98905fd3ffcc2f24716aceda6b upstream.

Telit FN980 flashing device 0x1bc7/0x9010 requires zero packet
to be sent if out data size is is equal to the endpoint max size.

Signed-off-by: Daniele Palmas 
[ johan: switch operands in conditional ]
Cc: stable 
Signed-off-by: Johan Hovold 
Signed-off-by: Greg Kroah-Hartman

usb: chipidea: host: Disable port power only if previously enabled

2020-01-14T19:03:00+00:00

commit c1ffba305dbcf3fb9ca969c20a97acbddc38f8e9 upstream.

On shutdown, ehci_power_off() is called unconditionally to power off
each port, even if it was never called to power on the port.
For chipidea, this results in a call to ehci_ci_portpower() with a request
to power off ports even if the port was never powered on.
This results in the following warning from the regulator code.

WARNING: CPU: 0 PID: 182 at drivers/regulator/core.c:2596 _regulator_disable+0x1a8/0x210
unbalanced disables for usb_otg2_vbus
Modules linked in:
CPU: 0 PID: 182 Comm: init Not tainted 5.4.6 #1
Hardware name: Freescale i.MX7 Dual (Device Tree)
[] (unwind_backtrace) from [] (show_stack+0x10/0x14)
[] (show_stack) from [] (dump_stack+0xe0/0x10c)
[] (dump_stack) from [] (__warn+0xf4/0x10c)
[] (__warn) from [] (warn_slowpath_fmt+0x78/0xbc)
[] (warn_slowpath_fmt) from [] (_regulator_disable+0x1a8/0x210)
[] (_regulator_disable) from [] (regulator_disable+0x38/0xe8)
[] (regulator_disable) from [] (ehci_ci_portpower+0x38/0xdc)
[] (ehci_ci_portpower) from [] (ehci_port_power+0x50/0xa4)
[] (ehci_port_power) from [] (ehci_silence_controller+0x5c/0xc4)
[] (ehci_silence_controller) from [] (ehci_stop+0x3c/0xcc)
[] (ehci_stop) from [] (usb_remove_hcd+0xe0/0x19c)
[] (usb_remove_hcd) from [] (host_stop+0x38/0xa8)
[] (host_stop) from [] (ci_hdrc_remove+0x44/0xe4)
...

Keeping track of the power enable state avoids the warning and traceback.

Fixes: c8679a2fb8dec ("usb: chipidea: host: add portpower override")
Cc: Michael Grzeschik 
Cc: Peter Chen 
Cc: stable@vger.kernel.org
Signed-off-by: Guenter Roeck 
Acked-by: Peter Chen 
Link: https://lore.kernel.org/r/20191226155754.25451-1-linux@roeck-us.net
Signed-off-by: Greg Kroah-Hartman

USB: serial: option: add Telit ME910G1 0x110a composition

2020-01-12T10:22:53+00:00

commit 0d3010fa442429f8780976758719af05592ff19f upstream.

This patch adds the following Telit ME910G1 composition:

0x110a: tty, tty, tty, rmnet

Signed-off-by: Daniele Palmas 
Cc: stable 
Signed-off-by: Johan Hovold 
Signed-off-by: Greg Kroah-Hartman

USB: core: fix check for duplicate endpoints

2020-01-12T10:22:53+00:00

commit 3e4f8e21c4f27bcf30a48486b9dcc269512b79ff upstream.

Amend the endpoint-descriptor sanity checks to detect all duplicate
endpoint addresses in a configuration.

Commit 0a8fd1346254 ("USB: fix problems with duplicate endpoint
addresses") added a check for duplicate endpoint addresses within a
single alternate setting, but did not look for duplicate addresses in
other interfaces.

The current check would also not detect all duplicate addresses when one
endpoint is as a (bi-directional) control endpoint.

This specifically avoids overwriting the endpoint entries in struct
usb_device when enabling a duplicate endpoint, something which could
potentially lead to crashes or leaks, for example, when endpoints are
later disabled.

Cc: stable 
Signed-off-by: Johan Hovold 
Acked-by: Alan Stern 
Link: https://lore.kernel.org/r/20191219161016.6695-1-johan@kernel.org
Signed-off-by: Greg Kroah-Hartman

usb: gadget: fix wrong endpoint desc

2020-01-12T10:22:39+00:00

[ Upstream commit e5b5da96da50ef30abb39cb9f694e99366404d24 ]

Gadget driver should always use config_ep_by_speed() to initialize
usb_ep struct according to usb device's operating speed. Otherwise,
usb_ep struct may be wrong if usb devcie's operating speed is changed.

The key point in this patch is that we want to make sure the desc pointer
in usb_ep struct will be set to NULL when gadget is disconnected.
This will force it to call config_ep_by_speed() to correctly initialize
usb_ep struct based on the new operating speed when gadget is
re-connected later.

Reviewed-by: Peter Chen 
Signed-off-by: EJ Hsu 
Signed-off-by: Felipe Balbi 
Signed-off-by: Sasha Levin

USB: EHCI: Do not return -EPIPE when hub is disconnected

2020-01-04T12:34:22+00:00

commit 64cc3f12d1c7dd054a215bc1ff9cc2abcfe35832 upstream.

When disconnecting a USB hub that has some child device(s) connected to it
(such as a USB mouse), then the stack tries to clear halt and
reset device(s) which are _already_ physically disconnected.

The issue has been reproduced with:

CPU: IMX6D5EYM10AD or MCIMX6D5EYM10AE.
SW: U-Boot 2019.07 and kernel 4.19.40.

CPU: HP Proliant Microserver Gen8.
SW: Linux version 4.2.3-300.fc23.x86_64

In this situation there will be error bit for MMF active yet the
CERR equals EHCI_TUNE_CERR + halt. Existing implementation
interprets this as a stall [1] (chapter 8.4.5).

The possible conditions when the MMF will be active + halt
can be found from [2] (Table 4-13).

Fix for the issue is to check whether MMF is active and PID Code is
IN before checking for the stall. If these conditions are true then
it is not a stall.

What happens after the fix is that when disconnecting a hub with
attached device(s) the situation is not interpret as a stall.

[1] [https://www.usb.org/document-library/usb-20-specification, usb_20.pdf]
[2] [https://www.intel.com/content/dam/www/public/us/en/documents/
     technical-specifications/ehci-specification-for-usb.pdf]

Signed-off-by: Erkka Talvitie 
Reviewed-by: Alan Stern 
Cc: stable 
Link: https://lore.kernel.org/r/ef70941d5f349767f19c0ed26b0dd9eed8ad81bb.1576050523.git.erkka.talvitie@vincit.fi
Signed-off-by: Greg Kroah-Hartman

usbip: Fix error path of vhci_recv_ret_submit()

2020-01-04T12:34:22+00:00

commit aabb5b833872524eaf28f52187e5987984982264 upstream.

If a transaction error happens in vhci_recv_ret_submit(), event
handler closes connection and changes port status to kick hub_event.
Then hub tries to flush the endpoint URBs, but that causes infinite
loop between usb_hub_flush_endpoint() and vhci_urb_dequeue() because
"vhci_priv" in vhci_urb_dequeue() was already released by
vhci_recv_ret_submit() before a transmission error occurred. Thus,
vhci_urb_dequeue() terminates early and usb_hub_flush_endpoint()
continuously calls vhci_urb_dequeue().

The root cause of this issue is that vhci_recv_ret_submit()
terminates early without giving back URB when transaction error
occurs in vhci_recv_ret_submit(). That causes the error URB to still
be linked at endpoint list without “vhci_priv".

So, in the case of transaction error in vhci_recv_ret_submit(),
unlink URB from the endpoint, insert proper error code in
urb->status and give back URB.

Reported-by: Marek Marczykowski-Górecki 
Tested-by: Marek Marczykowski-Górecki 
Signed-off-by: Suwan Kim 
Cc: stable 
Acked-by: Shuah Khan 
Link: https://lore.kernel.org/r/20191213023055.19933-3-suwan.kim027@gmail.com
Signed-off-by: Greg Kroah-Hartman