linux-stable.git/drivers/usb, branch v5.4.38

usb: gadget: udc: atmel: Fix vbus disconnect handling

2020-05-02T06:48:43+00:00

commit 12b94da411f9c6d950beb067d913024fd5617a61 upstream.

A DMA transfer can be in progress while vbus is lost due to a cable
disconnect. For endpoints that use DMA, this condition can lead to
peripheral hang. The patch ensures that endpoints are disabled before
the clocks are stopped to prevent this issue.

Fixes: a64ef71ddc13 ("usb: gadget: atmel_usba_udc: condition clocks to vbus state")
Signed-off-by: Cristian Birsan 
Signed-off-by: Felipe Balbi 
Signed-off-by: Greg Kroah-Hartman

usb: gadget: udc: bdc: Remove unnecessary NULL checks in bdc_req_complete

2020-05-02T06:48:43+00:00

commit 09b04abb70f096333bef6bc95fa600b662e7ee13 upstream.

When building with Clang + -Wtautological-pointer-compare:

drivers/usb/gadget/udc/bdc/bdc_ep.c:543:28: warning: comparison of
address of 'req->queue' equal to a null pointer is always false
[-Wtautological-pointer-compare]
        if (req == NULL  || &req->queue == NULL || &req->usb_req == NULL)
                             ~~~~~^~~~~    ~~~~
drivers/usb/gadget/udc/bdc/bdc_ep.c:543:51: warning: comparison of
address of 'req->usb_req' equal to a null pointer is always false
[-Wtautological-pointer-compare]
        if (req == NULL  || &req->queue == NULL || &req->usb_req == NULL)
                                                    ~~~~~^~~~~~~    ~~~~
2 warnings generated.

As it notes, these statements will always evaluate to false so remove
them.

Fixes: efed421a94e6 ("usb: gadget: Add UDC driver for Broadcom USB3.0 device controller IP BDC")
Link: https://github.com/ClangBuiltLinux/linux/issues/749
Signed-off-by: Nathan Chancellor 
Signed-off-by: Felipe Balbi 
Signed-off-by: Greg Kroah-Hartman

usb: dwc3: gadget: Do link recovery for SS and SSP

2020-05-02T06:48:42+00:00

commit d0550cd20e52558ecf6847a0f96ebd5d944c17e4 upstream.

The controller always supports link recovery for device in SS and SSP.
Remove the speed limit check. Also, when the device is in RESUME or
RESET state, it means the controller received the resume/reset request.
The driver must send the link recovery to acknowledge the request. They
are valid states for the driver to send link recovery.

Fixes: 72246da40f37 ("usb: Introduce DesignWare USB3 DRD Driver")
Fixes: ee5cd41c9117 ("usb: dwc3: Update speed checks for SuperSpeedPlus")
Signed-off-by: Thinh Nguyen 
Signed-off-by: Felipe Balbi 
Signed-off-by: Greg Kroah-Hartman

xhci: Don't clear hub TT buffer on ep0 protocol stall

2020-04-29T14:33:23+00:00

commit 8f97250c21f0cf36434bf5b7ddf4377406534cd1 upstream.

The default control endpoint ep0 can return a STALL indicating the
device does not support the control transfer requests. This is called
a protocol stall and does not halt the endpoint.

xHC behaves a bit different. Its internal endpoint state will always
be halted on any stall, even if the device side of the endpiont is not
halted. So we do need to issue the reset endpoint command to clear the
xHC host intenal endpoint halt state, but should not request the HS hub
to clear the TT buffer unless device side of endpoint is halted.

Clearing the hub TT buffer at protocol stall caused ep0 to become
unresponsive for some FS/LS devices behind HS hubs, and class drivers
failed to set the interface due to timeout:

usb 1-2.1: 1:1: usb_set_interface failed (-110)

Fixes: ef513be0a905 ("usb: xhci: Add Clear_TT_Buffer")
Cc:  # v5.3
Signed-off-by: Mathias Nyman 
Link: https://lore.kernel.org/r/20200421140822.28233-4-mathias.nyman@linux.intel.com
Signed-off-by: Greg Kroah-Hartman

xhci: prevent bus suspend if a roothub port detected a over-current condition

2020-04-29T14:33:23+00:00

commit e9fb08d617bfae5471d902112667d0eeb9dee3c4 upstream.

Suspending the bus and host controller while a port is in a over-current
condition may halt the host.
Also keep the roothub running if over-current is active.

Cc: 
Signed-off-by: Mathias Nyman 
Link: https://lore.kernel.org/r/20200421140822.28233-3-mathias.nyman@linux.intel.com
Signed-off-by: Greg Kroah-Hartman

xhci: Fix handling halted endpoint even if endpoint ring appears empty

2020-04-29T14:33:23+00:00

commit 93ceaa808e8defc67ebca1396e2f42f812a2efc0 upstream.

If a class driver cancels its only URB then the endpoint ring buffer will
appear empty to the xhci driver. xHC hardware may still process cached
TRBs, and complete with a STALL, halting the endpoint.

This halted endpoint was not handled correctly by xhci driver as events on
empty rings were all assumed to be spurious events.
xhci driver refused to restart the ring with EP_HALTED flag set, so class
driver was never informed the endpoint halted even if it queued new URBs.

The host side of the endpoint needs to be reset, and dequeue pointer should
be moved in order to clear the cached TRBs and resetart the endpoint.

Small adjustments in finding the new dequeue pointer are needed to support
the case of stall on an empty ring and unknown current TD.

Cc: 
cc: Jeremy Compostella 
Signed-off-by: Mathias Nyman 
Link: https://lore.kernel.org/r/20200421140822.28233-2-mathias.nyman@linux.intel.com
Signed-off-by: Greg Kroah-Hartman

usb: typec: altmode: Fix typec_altmode_get_partner sometimes returning an invalid pointer

2020-04-29T14:33:23+00:00

commit 0df9433fcae02215c8fd79690c134d535c7bb905 upstream.

Before this commit, typec_altmode_get_partner would return a
const struct typec_altmode * pointing to address 0x08 when
to_altmode(adev)->partner was NULL.

Add a check for to_altmode(adev)->partner being NULL to fix this.

BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=206365
BugLink: https://bugzilla.redhat.com/show_bug.cgi?id=1785972
Fixes: 5f54a85db5df ("usb: typec: Make sure an alt mode exist before getting its partner")
Cc: stable@vger.kernel.org
Signed-off-by: Naoki Kiryu 
Signed-off-by: Hans de Goede 
Link: https://lore.kernel.org/r/20200422144345.43262-1-hdegoede@redhat.com
Signed-off-by: Greg Kroah-Hartman

usb: typec: tcpm: Ignore CC and vbus changes in PORT_RESET change

2020-04-29T14:33:23+00:00

commit 901789745a053286e0ced37960d44fa60267b940 upstream.

After PORT_RESET, the port is set to the appropriate
default_state. Ignore processing CC changes here as this
could cause the port to be switched into sink states
by default.

echo source > /sys/class/typec/port0/port_type

Before:
[  154.528547] pending state change PORT_RESET -> PORT_RESET_WAIT_OFF @ 100 ms
[  154.528560] CC1: 0 -> 0, CC2: 3 -> 0 [state PORT_RESET, polarity 0, disconnected]
[  154.528564] state change PORT_RESET -> SNK_UNATTACHED

After:
[  151.068814] pending state change PORT_RESET -> PORT_RESET_WAIT_OFF @ 100 ms [rev3 NONE_AMS]
[  151.072440] CC1: 3 -> 0, CC2: 0 -> 0 [state PORT_RESET, polarity 0, disconnected]
[  151.172117] state change PORT_RESET -> PORT_RESET_WAIT_OFF [delayed 100 ms]
[  151.172136] pending state change PORT_RESET_WAIT_OFF -> SRC_UNATTACHED @ 870 ms [rev3 NONE_AMS]
[  152.060106] state change PORT_RESET_WAIT_OFF -> SRC_UNATTACHED [delayed 870 ms]
[  152.060118] Start toggling

Signed-off-by: Badhri Jagan Sridharan 
Cc: stable 
Reviewed-by: Heikki Krogerus 
Reviewed-by: Guenter Roeck 
Link: https://lore.kernel.org/r/20200402215947.176577-1-badhri@google.com
Signed-off-by: Greg Kroah-Hartman

usb: f_fs: Clear OS Extended descriptor counts to zero in ffs_data_reset()

2020-04-29T14:33:23+00:00

commit 1c2e54fbf1da5e5445a0ab132c862b02ccd8d230 upstream.

For userspace functions using OS Descriptors, if a function also supplies
Extended Property descriptors currently the counts and lengths stored in
the ms_os_descs_ext_prop_{count,name_len,data_len} variables are not
getting reset to 0 during an unbind or when the epfiles are closed. If
the same function is re-bound and the descriptors are re-written, this
results in those count/length variables to monotonically increase
causing the VLA allocation in _ffs_func_bind() to grow larger and larger
at each bind/unbind cycle and eventually fail to allocate.

Fix this by clearing the ms_os_descs_ext_prop count & lengths to 0 in
ffs_data_reset().

Fixes: f0175ab51993 ("usb: gadget: f_fs: OS descriptors support")
Cc: stable@vger.kernel.org
Signed-off-by: Udipto Goswami 
Signed-off-by: Sriharsha Allenki 
Reviewed-by: Manu Gautam 
Link: https://lore.kernel.org/r/20200402044521.9312-1-sallenki@codeaurora.org
Signed-off-by: Greg Kroah-Hartman

usb: dwc3: gadget: Fix request completion check

2020-04-29T14:33:23+00:00

commit 49e0590e3a60e75b493e5df879e216e5073c7663 upstream.

A request may not be completed because not all the TRBs are prepared for
it. This happens when we run out of available TRBs. When some TRBs are
completed, the driver needs to prepare the rest of the TRBs for the
request. The check dwc3_gadget_ep_request_completed() shouldn't be
checking the amount of data received but rather the number of pending
TRBs. Revise this request completion check.

Cc: stable@vger.kernel.org
Fixes: e0c42ce590fe ("usb: dwc3: gadget: simplify IOC handling")
Signed-off-by: Thinh Nguyen 
Signed-off-by: Felipe Balbi 
Signed-off-by: Greg Kroah-Hartman