linux-stable.git/drivers/usb, branch v5.4.149 Linux kernel stable tree usbip:vhci_hcd USB port can get stuck in the disabled state 2021-09-22T10:26:35+00:00 Shuah Khan skhan@linuxfoundation.org 2021-08-19T22:59:37+00:00 a1c7bc02e19216bdf870b866907a1b7714b8c6e3 [ Upstream commit 66cce9e73ec61967ed1f97f30cee79bd9a2bb7ee ] When a remote usb device is attached to the local Virtual USB Host Controller Root Hub port, the bound device driver may send a port reset command. vhci_hcd accepts port resets only when the device doesn't have port address assigned to it. When reset happens device is in assigned/used state and vhci_hcd rejects it leaving the port in a stuck state. This problem was found when a blue-tooth or xbox wireless dongle was passed through using usbip. A few drivers reset the port during probe including mt76 driver specific to this bug report. Fix the problem with a change to honor reset requests when device is in used state (VDEV_ST_USED). Reported-and-tested-by: Michael <msbroadf@gmail.com> Suggested-by: Michael <msbroadf@gmail.com> Signed-off-by: Shuah Khan <skhan@linuxfoundation.org> Link: https://lore.kernel.org/r/20210819225937.41037-1-skhan@linuxfoundation.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Sasha Levin <sashal@kernel.org> 
[ Upstream commit 66cce9e73ec61967ed1f97f30cee79bd9a2bb7ee ]

When a remote usb device is attached to the local Virtual USB
Host Controller Root Hub port, the bound device driver may send
a port reset command.

vhci_hcd accepts port resets only when the device doesn't have
port address assigned to it. When reset happens device is in
assigned/used state and vhci_hcd rejects it leaving the port in
a stuck state.

This problem was found when a blue-tooth or xbox wireless dongle
was passed through using usbip.

A few drivers reset the port during probe including mt76 driver
specific to this bug report. Fix the problem with a change to
honor reset requests when device is in used state (VDEV_ST_USED).

Reported-and-tested-by: Michael <msbroadf@gmail.com>
Suggested-by: Michael <msbroadf@gmail.com>
Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>
Link: https://lore.kernel.org/r/20210819225937.41037-1-skhan@linuxfoundation.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
usbip: give back URBs for unsent unlink requests during cleanup 2021-09-22T10:26:35+00:00 Anirudh Rayabharam mail@anirudhrb.com 2021-08-20T19:01:21+00:00 4f6095b0c9d5181fa4a9b1eb410701c7f00ce4b6 [ Upstream commit 258c81b341c8025d79073ce2d6ce19dcdc7d10d2 ] In vhci_device_unlink_cleanup(), the URBs for unsent unlink requests are not given back. This sometimes causes usb_kill_urb to wait indefinitely for that urb to be given back. syzbot has reported a hung task issue [1] for this. To fix this, give back the urbs corresponding to unsent unlink requests (unlink_tx list) similar to how urbs corresponding to unanswered unlink requests (unlink_rx list) are given back. [1]: https://syzkaller.appspot.com/bug?id=08f12df95ae7da69814e64eb5515d5a85ed06b76 Reported-by: syzbot+74d6ef051d3d2eacf428@syzkaller.appspotmail.com Tested-by: syzbot+74d6ef051d3d2eacf428@syzkaller.appspotmail.com Reviewed-by: Shuah Khan <skhan@linuxfoundation.org> Signed-off-by: Anirudh Rayabharam <mail@anirudhrb.com> Link: https://lore.kernel.org/r/20210820190122.16379-2-mail@anirudhrb.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Sasha Levin <sashal@kernel.org> 
[ Upstream commit 258c81b341c8025d79073ce2d6ce19dcdc7d10d2 ]

In vhci_device_unlink_cleanup(), the URBs for unsent unlink requests are
not given back. This sometimes causes usb_kill_urb to wait indefinitely
for that urb to be given back. syzbot has reported a hung task issue [1]
for this.

To fix this, give back the urbs corresponding to unsent unlink requests
(unlink_tx list) similar to how urbs corresponding to unanswered unlink
requests (unlink_rx list) are given back.

[1]: https://syzkaller.appspot.com/bug?id=08f12df95ae7da69814e64eb5515d5a85ed06b76

Reported-by: syzbot+74d6ef051d3d2eacf428@syzkaller.appspotmail.com
Tested-by: syzbot+74d6ef051d3d2eacf428@syzkaller.appspotmail.com
Reviewed-by: Shuah Khan <skhan@linuxfoundation.org>
Signed-off-by: Anirudh Rayabharam <mail@anirudhrb.com>
Link: https://lore.kernel.org/r/20210820190122.16379-2-mail@anirudhrb.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
usb: musb: musb_dsps: request_irq() after initializing musb 2021-09-22T10:26:35+00:00 Nadezda Lutovinova lutovinova@ispras.ru 2021-08-19T16:33:23+00:00 9a4a6805294fa7d2653e82972bdaf9e3e1f3d3c9 [ Upstream commit 7c75bde329d7e2a93cf86a5c15c61f96f1446cdc ] If IRQ occurs between calling dsps_setup_optional_vbus_irq() and dsps_create_musb_pdev(), then null pointer dereference occurs since glue->musb wasn't initialized yet. The patch puts initializing of neccesery data before registration of the interrupt handler. Found by Linux Driver Verification project (linuxtesting.org). Signed-off-by: Nadezda Lutovinova <lutovinova@ispras.ru> Link: https://lore.kernel.org/r/20210819163323.17714-1-lutovinova@ispras.ru Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Sasha Levin <sashal@kernel.org> 
[ Upstream commit 7c75bde329d7e2a93cf86a5c15c61f96f1446cdc ]

If IRQ occurs between calling  dsps_setup_optional_vbus_irq()
and  dsps_create_musb_pdev(), then null pointer dereference occurs
since glue->musb wasn't initialized yet.

The patch puts initializing of neccesery data before registration
of the interrupt handler.

Found by Linux Driver Verification project (linuxtesting.org).

Signed-off-by: Nadezda Lutovinova <lutovinova@ispras.ru>
Link: https://lore.kernel.org/r/20210819163323.17714-1-lutovinova@ispras.ru
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Revert "USB: xhci: fix U1/U2 handling for hardware with XHCI_INTEL_HOST quirk set" 2021-09-22T10:26:35+00:00 Mathias Nyman mathias.nyman@linux.intel.com 2021-08-20T12:35:01+00:00 d24381e5a73b84a9c89912ae524b115ccd9b4c67 [ Upstream commit 2847c46c61486fd8bca9136a6e27177212e78c69 ] This reverts commit 5d5323a6f3625f101dbfa94ba3ef7706cce38760. That commit effectively disabled Intel host initiated U1/U2 lpm for devices with periodic endpoints. Before that commit we disabled host initiated U1/U2 lpm if the exit latency was larger than any periodic endpoint service interval, this is according to xhci spec xhci 1.1 specification section 4.23.5.2 After that commit we incorrectly checked that service interval was smaller than U1/U2 inactivity timeout. This is not relevant, and can't happen for Intel hosts as previously set U1/U2 timeout = 105% * service interval. Patch claimed it solved cases where devices can't be enumerated because of bandwidth issues. This might be true but it's a side effect of accidentally turning off lpm. exit latency calculations have been revised since then Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Link: https://lore.kernel.org/r/20210820123503.2605901-5-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Sasha Levin <sashal@kernel.org> 
[ Upstream commit 2847c46c61486fd8bca9136a6e27177212e78c69 ]

This reverts commit 5d5323a6f3625f101dbfa94ba3ef7706cce38760.

That commit effectively disabled Intel host initiated U1/U2 lpm for devices
with periodic endpoints.

Before that commit we disabled host initiated U1/U2 lpm if the exit latency
was larger than any periodic endpoint service interval, this is according
to xhci spec xhci 1.1 specification section 4.23.5.2

After that commit we incorrectly checked that service interval was smaller
than U1/U2 inactivity timeout. This is not relevant, and can't happen for
Intel hosts as previously set U1/U2 timeout = 105% * service interval.

Patch claimed it solved cases where devices can't be enumerated because of
bandwidth issues. This might be true but it's a side effect of accidentally
turning off lpm.

exit latency calculations have been revised since then

Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
Link: https://lore.kernel.org/r/20210820123503.2605901-5-mathias.nyman@linux.intel.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
usb: chipidea: host: fix port index underflow and UBSAN complains 2021-09-22T10:26:33+00:00 Li Jun jun.li@nxp.com 2021-06-18T08:28:58+00:00 a18cfd715e91d2013da3dac86ce18f34a25d9e64 [ Upstream commit e5d6a7c6cfae9e714a0e8ff64facd1ac68a784c6 ] If wIndex is 0 (and it often is), these calculations underflow and UBSAN complains, here resolve this by not decrementing the index when it is equal to 0, this copies the solution from commit 85e3990bea49 ("USB: EHCI: avoid undefined pointer arithmetic and placate UBSAN") Reported-by: Zhipeng Wang <zhipeng.wang_1@nxp.com> Signed-off-by: Li Jun <jun.li@nxp.com> Link: https://lore.kernel.org/r/1624004938-2399-1-git-send-email-jun.li@nxp.com Signed-off-by: Peter Chen <peter.chen@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org> 
[ Upstream commit e5d6a7c6cfae9e714a0e8ff64facd1ac68a784c6 ]

If wIndex is 0 (and it often is), these calculations underflow and
UBSAN complains, here resolve this by not decrementing the index when
it is equal to 0, this copies the solution from commit 85e3990bea49
("USB: EHCI: avoid undefined pointer arithmetic and placate UBSAN")

Reported-by: Zhipeng Wang <zhipeng.wang_1@nxp.com>
Signed-off-by: Li Jun <jun.li@nxp.com>
Link: https://lore.kernel.org/r/1624004938-2399-1-git-send-email-jun.li@nxp.com
Signed-off-by: Peter Chen <peter.chen@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
usb: gadget: composite: Allow bMaxPower=0 if self-powered 2021-09-22T10:26:28+00:00 Jack Pham jackp@codeaurora.org 2021-07-20T08:09:07+00:00 995567ded0198773215872bdf235d3320d35217c [ Upstream commit bcacbf06c891374e7fdd7b72d11cda03b0269b43 ] Currently the composite driver encodes the MaxPower field of the configuration descriptor by reading the c->MaxPower of the usb_configuration only if it is non-zero, otherwise it falls back to using the value hard-coded in CONFIG_USB_GADGET_VBUS_DRAW. However, there are cases when a configuration must explicitly set bMaxPower to 0, particularly if its bmAttributes also has the Self-Powered bit set, which is a valid combination. This is specifically called out in the USB PD specification section 9.1, in which a PDUSB device "shall report zero in the bMaxPower field after negotiating a mutually agreeable Contract", and also verified by the USB Type-C Functional Test TD.4.10.2 Sink Power Precedence Test. The fix allows the c->MaxPower to be used for encoding the bMaxPower even if it is 0, if the self-powered bit is also set. An example usage of this would be for a ConfigFS gadget to be dynamically updated by userspace when the Type-C connection is determined to be operating in Power Delivery mode. Co-developed-by: Ronak Vijay Raheja <rraheja@codeaurora.org> Acked-by: Felipe Balbi <balbi@kernel.org> Signed-off-by: Ronak Vijay Raheja <rraheja@codeaurora.org> Signed-off-by: Jack Pham <jackp@codeaurora.org> Link: https://lore.kernel.org/r/20210720080907.30292-1-jackp@codeaurora.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Sasha Levin <sashal@kernel.org> 
[ Upstream commit bcacbf06c891374e7fdd7b72d11cda03b0269b43 ]

Currently the composite driver encodes the MaxPower field of
the configuration descriptor by reading the c->MaxPower of the
usb_configuration only if it is non-zero, otherwise it falls back
to using the value hard-coded in CONFIG_USB_GADGET_VBUS_DRAW.
However, there are cases when a configuration must explicitly set
bMaxPower to 0, particularly if its bmAttributes also has the
Self-Powered bit set, which is a valid combination.

This is specifically called out in the USB PD specification section
9.1, in which a PDUSB device "shall report zero in the bMaxPower
field after negotiating a mutually agreeable Contract", and also
verified by the USB Type-C Functional Test TD.4.10.2 Sink Power
Precedence Test.

The fix allows the c->MaxPower to be used for encoding the bMaxPower
even if it is 0, if the self-powered bit is also set.  An example
usage of this would be for a ConfigFS gadget to be dynamically
updated by userspace when the Type-C connection is determined to be
operating in Power Delivery mode.

Co-developed-by: Ronak Vijay Raheja <rraheja@codeaurora.org>
Acked-by: Felipe Balbi <balbi@kernel.org>
Signed-off-by: Ronak Vijay Raheja <rraheja@codeaurora.org>
Signed-off-by: Jack Pham <jackp@codeaurora.org>
Link: https://lore.kernel.org/r/20210720080907.30292-1-jackp@codeaurora.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
USB: EHCI: ehci-mv: improve error handling in mv_ehci_enable() 2021-09-22T10:26:28+00:00 Evgeny Novikov novikov@ispras.ru 2021-07-08T08:30:56+00:00 44bbd4e6366f01ef8d5dc5c608b4669b8f36b79f [ Upstream commit 61136a12cbed234374ec6f588af57c580b20b772 ] mv_ehci_enable() did not disable and unprepare clocks in case of failures of phy_init(). Besides, it did not take into account failures of ehci_clock_enable() (in effect, failures of clk_prepare_enable()). The patch fixes both issues and gets rid of redundant wrappers around clk_prepare_enable() and clk_disable_unprepare() to simplify this a bit. Found by Linux Driver Verification project (linuxtesting.org). Acked-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Evgeny Novikov <novikov@ispras.ru> Link: https://lore.kernel.org/r/20210708083056.21543-1-novikov@ispras.ru Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Sasha Levin <sashal@kernel.org> 
[ Upstream commit 61136a12cbed234374ec6f588af57c580b20b772 ]

mv_ehci_enable() did not disable and unprepare clocks in case of
failures of phy_init(). Besides, it did not take into account failures
of ehci_clock_enable() (in effect, failures of clk_prepare_enable()).
The patch fixes both issues and gets rid of redundant wrappers around
clk_prepare_enable() and clk_disable_unprepare() to simplify this a bit.

Found by Linux Driver Verification project (linuxtesting.org).

Acked-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Evgeny Novikov <novikov@ispras.ru>
Link: https://lore.kernel.org/r/20210708083056.21543-1-novikov@ispras.ru
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
usb: gadget: u_ether: fix a potential null pointer dereference 2021-09-22T10:26:28+00:00 Maciej Żenczykowski maze@google.com 2021-07-01T11:48:34+00:00 7b96de5c3042f66a3064701d532ad6b9ec028496 [ Upstream commit 8ae01239609b29ec2eff55967c8e0fe3650cfa09 ] f_ncm tx timeout can call us with null skb to flush a pending frame. In this case skb is NULL to begin with but ceases to be null after dev->wrap() completes. In such a case in->maxpacket will be read, even though we've failed to check that 'in' is not NULL. Though I've never observed this fail in practice, however the 'flush operation' simply does not make sense with a null usb IN endpoint - there's nowhere to flush to... (note that we're the gadget/device, and IN is from the point of view of the host, so here IN actually means outbound...) Cc: Brooke Basile <brookebasile@gmail.com> Cc: "Bryan O'Donoghue" <bryan.odonoghue@linaro.org> Cc: Felipe Balbi <balbi@kernel.org> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: Lorenzo Colitti <lorenzo@google.com> Signed-off-by: Maciej Żenczykowski <maze@google.com> Link: https://lore.kernel.org/r/20210701114834.884597-6-zenczykowski@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Sasha Levin <sashal@kernel.org> 
[ Upstream commit 8ae01239609b29ec2eff55967c8e0fe3650cfa09 ]

f_ncm tx timeout can call us with null skb to flush
a pending frame.  In this case skb is NULL to begin
with but ceases to be null after dev->wrap() completes.

In such a case in->maxpacket will be read, even though
we've failed to check that 'in' is not NULL.

Though I've never observed this fail in practice,
however the 'flush operation' simply does not make sense with
a null usb IN endpoint - there's nowhere to flush to...
(note that we're the gadget/device, and IN is from the point
 of view of the host, so here IN actually means outbound...)

Cc: Brooke Basile <brookebasile@gmail.com>
Cc: "Bryan O'Donoghue" <bryan.odonoghue@linaro.org>
Cc: Felipe Balbi <balbi@kernel.org>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Lorenzo Colitti <lorenzo@google.com>
Signed-off-by: Maciej Żenczykowski <maze@google.com>
Link: https://lore.kernel.org/r/20210701114834.884597-6-zenczykowski@gmail.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
usb: host: fotg210: fix the actual_length of an iso packet 2021-09-22T10:26:28+00:00 Kelly Devilliv kelly.devilliv@gmail.com 2021-06-27T12:57:47+00:00 e1480bcb407e31f243f4e65e034c23fcf4b13ed5 [ Upstream commit 091cb2f782f32ab68c6f5f326d7868683d3d4875 ] We should acquire the actual_length of an iso packet from the iTD directly using FOTG210_ITD_LENGTH() macro. Signed-off-by: Kelly Devilliv <kelly.devilliv@gmail.com> Link: https://lore.kernel.org/r/20210627125747.127646-4-kelly.devilliv@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Sasha Levin <sashal@kernel.org> 
[ Upstream commit 091cb2f782f32ab68c6f5f326d7868683d3d4875 ]

We should acquire the actual_length of an iso packet
from the iTD directly using FOTG210_ITD_LENGTH() macro.

Signed-off-by: Kelly Devilliv <kelly.devilliv@gmail.com>
Link: https://lore.kernel.org/r/20210627125747.127646-4-kelly.devilliv@gmail.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
usb: host: fotg210: fix the endpoint's transactional opportunities calculation 2021-09-22T10:26:28+00:00 Kelly Devilliv kelly.devilliv@gmail.com 2021-06-27T12:57:46+00:00 33109bdf2c41315cbd1afc8c20dca9a4fdf1951d [ Upstream commit c2e898764245c852bc8ee4857613ba4f3a6d761d ] Now that usb_endpoint_maxp() only returns the lowest 11 bits from wMaxPacketSize, we should make use of the usb_endpoint_* helpers instead and remove the unnecessary max_packet()/hb_mult() macro. Signed-off-by: Kelly Devilliv <kelly.devilliv@gmail.com> Link: https://lore.kernel.org/r/20210627125747.127646-3-kelly.devilliv@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Sasha Levin <sashal@kernel.org> 
[ Upstream commit c2e898764245c852bc8ee4857613ba4f3a6d761d ]

Now that usb_endpoint_maxp() only returns the lowest
11 bits from wMaxPacketSize, we should make use of the
usb_endpoint_* helpers instead and remove the unnecessary
max_packet()/hb_mult() macro.

Signed-off-by: Kelly Devilliv <kelly.devilliv@gmail.com>
Link: https://lore.kernel.org/r/20210627125747.127646-3-kelly.devilliv@gmail.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>