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

usb: isp1760: otg control register access

2021-09-18T11:43:59+00:00

[ Upstream commit 9c1587d99f9305aa4f10b47fcf1981012aa5381f ]

The set/clear of the otg control values is done writing to
two different 16bit registers, however we setup the regmap
width for isp1760/61 to 32bit value bits.

So, just access the clear register address (0x376)as the high
part of the otg control register set (0x374), and write the
values in one go to make sure they get clear/set.

Reported-by: Dietmar Eggemann 
Tested-by: Dietmar Eggemann 
Signed-off-by: Rui Miguel Silva 
Link: https://lore.kernel.org/r/20210827131154.4151862-6-rui.silva@linaro.org
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Sasha Levin

usb: isp1760: use the right irq status bit

2021-09-18T11:43:59+00:00

[ Upstream commit 955d0fb590f18ec5c3a4085c7d0e39b6abde0dd6 ]

Instead of using the fields enum values to check interrupts
trigged, use the correct bit values.

Reported-by: Dietmar Eggemann 
Tested-by: Dietmar Eggemann 
Signed-off-by: Rui Miguel Silva 
Link: https://lore.kernel.org/r/20210827131154.4151862-5-rui.silva@linaro.org
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Sasha Levin

usb: isp1760: write to status and address register

2021-09-18T11:43:59+00:00

[ Upstream commit 36815a4a0763bb405ebd776c45553005c1ef7a15 ]

We were already writing directly the port status register to
trigger changes in isp1763. The same is needed in other IP
from the family, including also to setup the read address
before reading from device.

Reported-by: Dietmar Eggemann 
Tested-by: Dietmar Eggemann 
Signed-off-by: Rui Miguel Silva 
Link: https://lore.kernel.org/r/20210827131154.4151862-4-rui.silva@linaro.org
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Sasha Levin

usb: isp1760: fix qtd fill length

2021-09-18T11:43:59+00:00

[ Upstream commit cbfa3effdf5c2d411c9ce9820f3d33d77bc4697d ]

When trying to send bulks bigger than the biggest block size
we need to split them over several qtd. Fix this limiting the
maximum qtd size to largest block size.

Reported-by: Dietmar Eggemann 
Tested-by: Dietmar Eggemann 
Signed-off-by: Rui Miguel Silva 
Link: https://lore.kernel.org/r/20210827131154.4151862-3-rui.silva@linaro.org
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Sasha Levin

usb: isp1760: fix memory pool initialization

2021-09-18T11:43:59+00:00

[ Upstream commit f757f9291f920e1da4c6cfd4064c6bf59639983e ]

The loops to setup the memory pool were skipping some
blocks, that was not visible on the ISP1763 because it has
fewer blocks than the ISP1761. But won testing on that IP
from the family that would be an issue.

Reported-by: Dietmar Eggemann 
Tested-by: Dietmar Eggemann 
Signed-off-by: Rui Miguel Silva 
Link: https://lore.kernel.org/r/20210827131154.4151862-2-rui.silva@linaro.org
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Sasha Levin

usb: xhci-mtk: Do not use xhci's virt_dev in drop_endpoint

2021-09-18T11:43:57+00:00

[ Upstream commit b8731209958a1dffccc2888121f4c0280c990550 ]

xhci-mtk depends on xhci's internal virt_dev when it retrieves its
internal data from usb_host_endpoint both in add_endpoint and
drop_endpoint callbacks. But when setup packet was retired by
transaction errors in xhci_setup_device() path, a virt_dev for the slot
is newly created with real_port 0. This leads to xhci-mtks's NULL pointer
dereference from drop_endpoint callback as xhci-mtk assumes that virt_dev's
real_port is always started from one. The similar problems were addressed
by [1] but that can't cover the failure cases from setup_device.

This patch drops the usages of xhci's virt_dev in xhci-mtk's drop_endpoint
callback by adopting rhashtable for searching mtk's schedule entity
from a given usb_host_endpoint pointer instead of searching a linked list.
So mtk's drop_endpoint callback doesn't have to rely on virt_dev at all.

[1] https://lore.kernel.org/r/1617179142-2681-2-git-send-email-chunfeng.yun@mediatek.com

Signed-off-by: Ikjoon Jang 
Link: https://lore.kernel.org/r/20210805133731.1.Icc0f080e75b1312692d4c7c7d25e7df9fe1a05c2@changeid
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Sasha Levin

usb: xhci-mtk: fix use-after-free of mtk->hcd

2021-09-18T11:43:57+00:00

[ Upstream commit 7f85c16f40d8be5656fb3476909db5c3a5a9c6ea ]

 BUG: KASAN: use-after-free in usb_hcd_is_primary_hcd+0x38/0x60
 Call trace:
  dump_backtrace+0x0/0x3dc
  show_stack+0x20/0x2c
  dump_stack+0x15c/0x1d4
  print_address_description+0x7c/0x510
  kasan_report+0x164/0x1ac
  __asan_report_load8_noabort+0x44/0x50
  usb_hcd_is_primary_hcd+0x38/0x60
  xhci_mtk_runtime_suspend+0x68/0x148
  pm_generic_runtime_suspend+0x90/0xac
  __rpm_callback+0xb8/0x1f4
  rpm_callback+0x54/0x1d0
  rpm_suspend+0x4e0/0xc84
  __pm_runtime_suspend+0xc4/0x114
  xhci_mtk_probe+0xa58/0xd00

This may happen when probe fails, needn't suspend it synchronously,
fix it by using pm_runtime_put_noidle().

Reported-by: Pi Hsun 
Signed-off-by: Chunfeng Yun 
Link: https://lore.kernel.org/r/1629189389-18779-3-git-send-email-chunfeng.yun@mediatek.com
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Sasha Levin

usbip:vhci_hcd USB port can get stuck in the disabled state

2021-09-18T11:43:56+00:00

[ 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 
Suggested-by: Michael 
Signed-off-by: Shuah Khan 
Link: https://lore.kernel.org/r/20210819225937.41037-1-skhan@linuxfoundation.org
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Sasha Levin

usbip: give back URBs for unsent unlink requests during cleanup

2021-09-18T11:43:56+00:00

[ 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 
Signed-off-by: Anirudh Rayabharam 
Link: https://lore.kernel.org/r/20210820190122.16379-2-mail@anirudhrb.com
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Sasha Levin

usb: musb: musb_dsps: request_irq() after initializing musb

2021-09-18T11:43:56+00:00

[ 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 
Link: https://lore.kernel.org/r/20210819163323.17714-1-lutovinova@ispras.ru
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Sasha Levin