Commit Graph

2184 Commits

Author SHA1 Message Date
Greg Kroah-Hartman
58bfe7d8e3 Revert "usb: add quirks for Lenovo OneLink+ Dock"
This reverts commit 3d5f70949f.

The quirk does not work properly, more work is needed to determine what
should be done here.

Reported-by: Oliver Neukum <oneukum@suse.com>
Cc: Jean-Francois Le Fillatre <jflf_kernel@gmx.com>
Cc: stable <stable@kernel.org>
Fixes: 3d5f70949f ("usb: add quirks for Lenovo OneLink+ Dock")
Link: https://lore.kernel.org/r/9a17ea86-079f-510d-e919-01bc53a6d09f@gmx.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-08-31 10:34:25 +02:00
Alan Stern
9c6d778800 USB: core: Prevent nested device-reset calls
Automatic kernel fuzzing revealed a recursive locking violation in
usb-storage:

============================================
WARNING: possible recursive locking detected
5.18.0 #3 Not tainted
--------------------------------------------
kworker/1:3/1205 is trying to acquire lock:
ffff888018638db8 (&us_interface_key[i]){+.+.}-{3:3}, at:
usb_stor_pre_reset+0x35/0x40 drivers/usb/storage/usb.c:230

but task is already holding lock:
ffff888018638db8 (&us_interface_key[i]){+.+.}-{3:3}, at:
usb_stor_pre_reset+0x35/0x40 drivers/usb/storage/usb.c:230

...

stack backtrace:
CPU: 1 PID: 1205 Comm: kworker/1:3 Not tainted 5.18.0 #3
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS
1.13.0-1ubuntu1.1 04/01/2014
Workqueue: usb_hub_wq hub_event
Call Trace:
<TASK>
__dump_stack lib/dump_stack.c:88 [inline]
dump_stack_lvl+0xcd/0x134 lib/dump_stack.c:106
print_deadlock_bug kernel/locking/lockdep.c:2988 [inline]
check_deadlock kernel/locking/lockdep.c:3031 [inline]
validate_chain kernel/locking/lockdep.c:3816 [inline]
__lock_acquire.cold+0x152/0x3ca kernel/locking/lockdep.c:5053
lock_acquire kernel/locking/lockdep.c:5665 [inline]
lock_acquire+0x1ab/0x520 kernel/locking/lockdep.c:5630
__mutex_lock_common kernel/locking/mutex.c:603 [inline]
__mutex_lock+0x14f/0x1610 kernel/locking/mutex.c:747
usb_stor_pre_reset+0x35/0x40 drivers/usb/storage/usb.c:230
usb_reset_device+0x37d/0x9a0 drivers/usb/core/hub.c:6109
r871xu_dev_remove+0x21a/0x270 drivers/staging/rtl8712/usb_intf.c:622
usb_unbind_interface+0x1bd/0x890 drivers/usb/core/driver.c:458
device_remove drivers/base/dd.c:545 [inline]
device_remove+0x11f/0x170 drivers/base/dd.c:537
__device_release_driver drivers/base/dd.c:1222 [inline]
device_release_driver_internal+0x1a7/0x2f0 drivers/base/dd.c:1248
usb_driver_release_interface+0x102/0x180 drivers/usb/core/driver.c:627
usb_forced_unbind_intf+0x4d/0xa0 drivers/usb/core/driver.c:1118
usb_reset_device+0x39b/0x9a0 drivers/usb/core/hub.c:6114

This turned out not to be an error in usb-storage but rather a nested
device reset attempt.  That is, as the rtl8712 driver was being
unbound from a composite device in preparation for an unrelated USB
reset (that driver does not have pre_reset or post_reset callbacks),
its ->remove routine called usb_reset_device() -- thus nesting one
reset call within another.

Performing a reset as part of disconnect processing is a questionable
practice at best.  However, the bug report points out that the USB
core does not have any protection against nested resets.  Adding a
reset_in_progress flag and testing it will prevent such errors in the
future.

Link: https://lore.kernel.org/all/CAB7eexKUpvX-JNiLzhXBDWgfg2T9e9_0Tw4HQ6keN==voRbP0g@mail.gmail.com/
Cc: stable@vger.kernel.org
Reported-and-tested-by: Rondreis <linhaoguo86@gmail.com>
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Link: https://lore.kernel.org/r/YwkflDxvg0KWqyZK@rowland.harvard.edu
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-08-30 15:32:04 +02:00
Jean-Francois Le Fillatre
3d5f70949f usb: add quirks for Lenovo OneLink+ Dock
The Lenovo OneLink+ Dock contains two VL812 USB3.0 controllers:
17ef:1018 upstream
17ef:1019 downstream

Those two controllers both have problems with some USB3.0 devices,
particularly self-powered ones. Typical error messages include:

  Timeout while waiting for setup device command
  device not accepting address X, error -62
  unable to enumerate USB device

By process of elimination the controllers themselves were identified as
the cause of the problem. Through trial and error the issue was solved
by using USB_QUIRK_RESET_RESUME for both chips.

Signed-off-by: Jean-Francois Le Fillatre <jflf_kernel@gmx.com>
Cc: stable <stable@kernel.org>
Link: https://lore.kernel.org/r/20220824191320.17883-1-jflf_kernel@gmx.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-08-30 15:29:57 +02:00
Linus Torvalds
c993e07be0 dma-mapping updates
- convert arm32 to the common dma-direct code (Arnd Bergmann, Robin Murphy,
    Christoph Hellwig)
  - restructure the PCIe peer to peer mapping support (Logan Gunthorpe)
  - allow the IOMMU code to communicate an optional DMA mapping length
    and use that in scsi and libata (John Garry)
  - split the global swiotlb lock (Tianyu Lan)
  - various fixes and cleanup (Chao Gao, Dan Carpenter, Dongli Zhang,
    Lukas Bulwahn, Robin Murphy)
 -----BEGIN PGP SIGNATURE-----
 
 iQI/BAABCgApFiEEgdbnc3r/njty3Iq9D55TZVIEUYMFAmLuIYULHGhjaEBsc3Qu
 ZGUACgkQD55TZVIEUYPS5A//Ty1ZNyXExmwZ6J6g7/oIvQlpAHilDr22mCd8tR8Y
 Ne7TgLa/X+usFvJTxJfkvg/LNMDjD7qx0J/mhDGm4reOFcEL4/PBy0rDSOgnmntV
 k/fPhgwnpuztiAQ+s+WkJ3pkrmG1HaEId7GGj2JaoYdas6RX2mGX7vL8uvUFepjw
 lYPAqWMtJHkOfsDK0PqqyQsr7dcC6lyFLqnn/wqvHtTJeKCfGs6W/SIrlWme2SZY
 3dNx84ZR1uPjaazAmtf2IWfjh/TBmd0ETRYycgUUKRP9iwsCkBQDBwsBGSIYXiWj
 BUKQ5oMvjAlUGRF0jYz9e77KuedE6GxWiXNQstitBmid142M37DHA5tvZRf65MPS
 THHcjTDmmoaO4YfFhhXOcFOrjG4/V8bF7fgHB6XkHDjhVVTcnIx8zuOAXIVBZvIV
 VAALmamBqEfIZZrCqgr7hzFssK2bip+TIMkdoD46Wcr+D7bAlujhuzWxubn9+ulT
 23v/pAvC80ut6LvKj6EA+GpRm/pejfOtEbjXPoO2hguNxvuUKvPQqNh9hy0q+v1e
 8n2Y/4lhy5bv02S7wKooNkfCoV753jBY1TIru45UmEYc3EkTQPii6okYe0DvW4QX
 VCnKgo156wSBfE+9eWdxCROv2SZqJFMV/wL3vw54dpJQMbDy7VkNsh4mGREdUkU1
 uek=
 =Bv19
 -----END PGP SIGNATURE-----

Merge tag 'dma-mapping-5.20-2022-08-06' of git://git.infradead.org/users/hch/dma-mapping

Pull dma-mapping updates from Christoph Hellwig:

 - convert arm32 to the common dma-direct code (Arnd Bergmann, Robin
   Murphy, Christoph Hellwig)

 - restructure the PCIe peer to peer mapping support (Logan Gunthorpe)

 - allow the IOMMU code to communicate an optional DMA mapping length
   and use that in scsi and libata (John Garry)

 - split the global swiotlb lock (Tianyu Lan)

 - various fixes and cleanup (Chao Gao, Dan Carpenter, Dongli Zhang,
   Lukas Bulwahn, Robin Murphy)

* tag 'dma-mapping-5.20-2022-08-06' of git://git.infradead.org/users/hch/dma-mapping: (45 commits)
  swiotlb: fix passing local variable to debugfs_create_ulong()
  dma-mapping: reformat comment to suppress htmldoc warning
  PCI/P2PDMA: Remove pci_p2pdma_[un]map_sg()
  RDMA/rw: drop pci_p2pdma_[un]map_sg()
  RDMA/core: introduce ib_dma_pci_p2p_dma_supported()
  nvme-pci: convert to using dma_map_sgtable()
  nvme-pci: check DMA ops when indicating support for PCI P2PDMA
  iommu/dma: support PCI P2PDMA pages in dma-iommu map_sg
  iommu: Explicitly skip bus address marked segments in __iommu_map_sg()
  dma-mapping: add flags to dma_map_ops to indicate PCI P2PDMA support
  dma-direct: support PCI P2PDMA pages in dma-direct map_sg
  dma-mapping: allow EREMOTEIO return code for P2PDMA transfers
  PCI/P2PDMA: Introduce helpers for dma_map_sg implementations
  PCI/P2PDMA: Attempt to set map_type if it has not been set
  lib/scatterlist: add flag for indicating P2PDMA segments in an SGL
  swiotlb: clean up some coding style and minor issues
  dma-mapping: update comment after dmabounce removal
  scsi: sd: Add a comment about limiting max_sectors to shost optimal limit
  ata: libata-scsi: cap ata_device->max_sectors according to shost->max_sectors
  scsi: scsi_transport_sas: cap shost opt_sectors according to DMA optimal limit
  ...
2022-08-06 10:56:45 -07:00
Linus Torvalds
9e2e5ea3b2 USB / Thunderbolt changes for 6.0-rc1
Here is the big set of Thunderbolt and USB changes for 6.0-rc1.
 
 Lots of little things here, nothing major, just constant development on
 some new hardware support and cleanups of older drivers.  Highlights of
 this pull request are:
 	- lots of typec changes and improvements for new hardware
 	- new gadget controller driver
 	- thunderbolt support for new hardware
 	- the normal set of new usb-serial device ids and cleanups
 	- loads of dwc3 controller fixes and improvements
 	- mtu3 driver updates
 	- testusb fixes for longtime issues (not many people use this
 	  tool it seems.)
 	- minor driver fixes and improvements over the USB tree
 	- chromeos platform driver changes were added and then reverted
 	  as they depened on some typec changes, but the cross-tree
 	  merges caused problems so they will come back later through
 	  the platform tree.
 
 All of these have been in linux-next for a while now with no reported
 issues.
 
 Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
 -----BEGIN PGP SIGNATURE-----
 
 iG0EABECAC0WIQT0tgzFv3jCIUoxPcsxR9QN2y37KQUCYup5Rg8cZ3JlZ0Brcm9h
 aC5jb20ACgkQMUfUDdst+yko/ACfYD9mdlr4WleUpVw5/uNywN6sL9EAn1tv0V8W
 cUTAoWxAf5orClAC22ZU
 =Vcqd
 -----END PGP SIGNATURE-----

Merge tag 'usb-6.0-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb

Pull USB / Thunderbolt updates from Greg KH:
 "Here is the big set of Thunderbolt and USB changes for 6.0-rc1.

  Lots of little things here, nothing major, just constant development
  on some new hardware support and cleanups of older drivers. Highlights
  are:

   - lots of typec changes and improvements for new hardware

   - new gadget controller driver

   - thunderbolt support for new hardware

   - the normal set of new usb-serial device ids and cleanups

   - loads of dwc3 controller fixes and improvements

   - mtu3 driver updates

   - testusb fixes for longtime issues (not many people use this tool it
     seems.)

   - minor driver fixes and improvements over the USB tree

   - chromeos platform driver changes were added and then reverted as
     they depened on some typec changes, but the cross-tree merges
     caused problems so they will come back later through the platform
     tree.

  All of these have been in linux-next for a while now with no reported
  issues"

* tag 'usb-6.0-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb: (193 commits)
  usb: misc: onboard_usb_hub: Remove duplicated power_on delay
  usb: misc: onboard_usb_hub: Add TI USB8041 hub support
  usb: misc: onboard_usb_hub: Add reset-gpio support
  USB: usbsevseg: convert sysfs snprintf to sysfs_emit
  dt-bindings: usb: Add binding for TI USB8041 hub controller
  ARM: multi_v7_defconfig: enable USB onboard HUB driver
  ARM: dts: stm32: add support for USB2514B onboard hub on stm32mp15xx-dkx
  usb: misc: onboard-hub: add support for Microchip USB2514B USB 2.0 hub
  dt-bindings: usb: generic-ehci: allow usb-hcd schema properties
  usb: typec: ucsi: stm32g0: add bootloader support
  usb: typec: ucsi: stm32g0: add support for stm32g0 controller
  dt-bindings: usb: typec: add bindings for stm32g0 controller
  usb: typec: ucsi: Acknowledge the GET_ERROR_STATUS command completion
  usb: cdns3: change place of 'priv_ep' assignment in cdns3_gadget_ep_dequeue(), cdns3_gadget_ep_enable()
  usb/chipidea: fix repeated words in comments
  usb: renesas-xhci: Do not print any log while fw verif success
  usb: typec: retimer: Add missing id check in match callback
  USB: xhci: Fix comment typo
  usb/typec/tcpm: fix repeated words in comments
  usb/musb: fix repeated words in comments
  ...
2022-08-04 11:41:28 -07:00
Jilin Yuan
a7a9f4c006 usb/core: fix repeated words in comments
Delete the redundant word 'the'.

Signed-off-by: Jilin Yuan <yuanjilin@cdjrlc.com>
Link: https://lore.kernel.org/r/20220716132403.35270-1-yuanjilin@cdjrlc.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-07-27 14:32:29 +02:00
Weitao Wang
26c6c2f8a9 USB: HCD: Fix URB giveback issue in tasklet function
Usb core introduce the mechanism of giveback of URB in tasklet context to
reduce hardware interrupt handling time. On some test situation(such as
FIO with 4KB block size), when tasklet callback function called to
giveback URB, interrupt handler add URB node to the bh->head list also.
If check bh->head list again after finish all URB giveback of local_list,
then it may introduce a "dynamic balance" between giveback URB and add URB
to bh->head list. This tasklet callback function may not exit for a long
time, which will cause other tasklet function calls to be delayed. Some
real-time applications(such as KB and Mouse) will see noticeable lag.

In order to prevent the tasklet function from occupying the cpu for a long
time at a time, new URBS will not be added to the local_list even though
the bh->head list is not empty. But also need to ensure the left URB
giveback to be processed in time, so add a member high_prio for structure
giveback_urb_bh to prioritize tasklet and schelule this tasklet again if
bh->head list is not empty.

At the same time, we are able to prioritize tasklet through structure
member high_prio. So, replace the local high_prio_bh variable with this
structure member in usb_hcd_giveback_urb.

Fixes: 94dfd7edfd ("USB: HCD: support giveback of URB in tasklet context")
Cc: stable <stable@kernel.org>
Reviewed-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Weitao Wang <WeitaoWang-oc@zhaoxin.com>
Link: https://lore.kernel.org/r/20220726074918.5114-1-WeitaoWang-oc@zhaoxin.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-07-27 14:30:19 +02:00
Alexey Sheplyakov
d7de14d74d usb: xhci_plat_remove: avoid NULL dereference
Since commit 4736ebd7fc ("usb: host:
xhci-plat: omit shared hcd if either root hub has no ports")
xhci->shared_hcd can be NULL, which causes the following Oops
on reboot:

[  710.124450] systemd-shutdown[1]: Rebooting.
[  710.298861] xhci-hcd xhci-hcd.2.auto: remove, state 4
[  710.304217] usb usb3: USB disconnect, device number 1
[  710.317441] xhci-hcd xhci-hcd.2.auto: USB bus 3 deregistered
[  710.323280] xhci-hcd xhci-hcd.2.auto: remove, state 1
[  710.328401] usb usb2: USB disconnect, device number 1
[  710.333515] usb 2-3: USB disconnect, device number 2
[  710.467649] xhci-hcd xhci-hcd.2.auto: USB bus 2 deregistered
[  710.475450] Unable to handle kernel NULL pointer dereference at virtual address 00000000000003b8
[  710.484425] Mem abort info:
[  710.487265]   ESR = 0x0000000096000004
[  710.491060]   EC = 0x25: DABT (current EL), IL = 32 bits
[  710.496427]   SET = 0, FnV = 0
[  710.499525]   EA = 0, S1PTW = 0
[  710.502716]   FSC = 0x04: level 0 translation fault
[  710.507648] Data abort info:
[  710.510577]   ISV = 0, ISS = 0x00000004
[  710.514462]   CM = 0, WnR = 0
[  710.517480] user pgtable: 4k pages, 48-bit VAs, pgdp=00000008b0050000
[  710.523976] [00000000000003b8] pgd=0000000000000000, p4d=0000000000000000
[  710.530961] Internal error: Oops: 96000004 [#1] PREEMPT SMP
[  710.536551] Modules linked in: rfkill input_leds snd_soc_simple_card snd_soc_simple_card_utils snd_soc_nau8822 designware_i2s snd_soc_core dw_hdmi_ahb_audio snd_pcm_dmaengine arm_ccn panfrost ac97_bus gpu_sched snd_pcm at24 fuse configfs sdhci_of_dwcmshc sdhci_pltfm sdhci nvme led_class mmc_core nvme_core bt1_pvt polynomial tp_serio snd_seq_midi snd_seq_midi_event snd_seq snd_timer snd_rawmidi snd_seq_device snd soundcore efivarfs ipv6
[  710.575286] CPU: 7 PID: 1 Comm: systemd-shutdow Not tainted 5.19.0-rc7-00043-gfd8619f4fd54 #1
[  710.583822] Hardware name: T-Platforms TF307-MB/BM1BM1-A, BIOS 5.6 07/06/2022
[  710.590972] pstate: 40000005 (nZcv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)
[  710.597949] pc : usb_remove_hcd+0x34/0x1e4
[  710.602067] lr : xhci_plat_remove+0x74/0x140
[  710.606351] sp : ffff800009f3b7c0
[  710.609674] x29: ffff800009f3b7c0 x28: ffff000800960040 x27: 0000000000000000
[  710.616833] x26: ffff800008dc22a0 x25: 0000000000000000 x24: 0000000000000000
[  710.623992] x23: 0000000000000000 x22: ffff000805465810 x21: ffff000805465800
[  710.631149] x20: ffff000800f80000 x19: 0000000000000000 x18: ffffffffffffffff
[  710.638307] x17: ffff000805096000 x16: ffff00080633b800 x15: ffff000806537a1c
[  710.645465] x14: 0000000000000001 x13: 0000000000000000 x12: ffff00080378d6f0
[  710.652621] x11: ffff00080041a900 x10: ffff800009b204e8 x9 : ffff8000088abaa4
[  710.659779] x8 : ffff000800960040 x7 : ffff800009409000 x6 : 0000000000000001
[  710.666936] x5 : ffff800009241000 x4 : ffff800009241440 x3 : 0000000000000000
[  710.674094] x2 : ffff000800960040 x1 : ffff000800960040 x0 : 0000000000000000
[  710.681251] Call trace:
[  710.683704]  usb_remove_hcd+0x34/0x1e4
[  710.687467]  xhci_plat_remove+0x74/0x140
[  710.691400]  platform_remove+0x34/0x70
[  710.695165]  device_remove+0x54/0x90
[  710.698753]  device_release_driver_internal+0x200/0x270
[  710.703992]  device_release_driver+0x24/0x30
[  710.708273]  bus_remove_device+0xe0/0x16c
[  710.712293]  device_del+0x178/0x390
[  710.715797]  platform_device_del.part.0+0x24/0x90
[  710.720514]  platform_device_unregister+0x30/0x50
[  710.725232]  dwc3_host_exit+0x20/0x30
[  710.728907]  dwc3_remove+0x174/0x1b0
[  710.732494]  platform_remove+0x34/0x70
[  710.736254]  device_remove+0x54/0x90
[  710.739840]  device_release_driver_internal+0x200/0x270
[  710.745078]  device_release_driver+0x24/0x30
[  710.749359]  bus_remove_device+0xe0/0x16c
[  710.753380]  device_del+0x178/0x390
[  710.756881]  platform_device_del.part.0+0x24/0x90
[  710.761598]  platform_device_unregister+0x30/0x50
[  710.766314]  of_platform_device_destroy+0xe8/0x100
[  710.771119]  device_for_each_child_reverse+0x70/0xc0
[  710.776099]  of_platform_depopulate+0x48/0x90
[  710.780468]  __dwc3_of_simple_teardown+0x28/0xe0
[  710.785099]  dwc3_of_simple_shutdown+0x20/0x30
[  710.789555]  platform_shutdown+0x30/0x40
[  710.793490]  device_shutdown+0x138/0x32c
[  710.797425]  __do_sys_reboot+0x1c4/0x2ac
[  710.801362]  __arm64_sys_reboot+0x30/0x40
[  710.805383]  invoke_syscall+0x50/0x120
[  710.809146]  el0_svc_common.constprop.0+0x68/0x124
[  710.813950]  do_el0_svc+0x3c/0xcc
[  710.817275]  el0_svc+0x60/0x12c
[  710.820428]  el0t_64_sync_handler+0xc0/0x13c
[  710.824710]  el0t_64_sync+0x18c/0x190
[  710.828386] Code: a9025bf5 f942c420 f9001fe0 d2800000 (b943ba62)
[  710.834498] ---[ end trace 0000000000000000 ]---
[  710.875958] pstore: crypto_comp_compress failed, ret = -22!
[  710.895047] Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b
[  710.902757] Kernel Offset: disabled
[  710.906255] CPU features: 0x800,00004811,00001082
[  710.910971] Memory Limit: none
[  710.927474] ---[ end Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b ]---

To avoid the problem check for NULL in usb_remove_hcd.

Fixes: 4736ebd7fc ("usb: host: xhci-plat: omit shared hcd if either root hub has no ports")
Signed-off-by: Alexey Sheplyakov <asheplyakov@basealt.ru>
Link: https://lore.kernel.org/r/20220722141700.1271439-1-asheplyakov@basealt.ru
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-07-27 14:29:14 +02:00
Matthias Kaehlcke
3a6bf4a081 usb: core: hub: Create platform devices for onboard hubs in hub_probe()
Call onboard_hub_create/destroy_pdevs() from hub_probe/disconnect()
to create/destroy platform devices for onboard USB hubs that may be
connected to the hub. The onboard hubs must have nodes in the
device tree.

onboard_hub_create/destroy_pdevs() are NOPs unless
CONFIG_USB_ONBOARD_HUB=y/m.

Also add a field to struct usb_hub to keep track of the onboard hub
platform devices that are owned by the hub.

Reviewed-by: Douglas Anderson <dianders@chromium.org>
Signed-off-by: Matthias Kaehlcke <mka@chromium.org>
Link: https://lore.kernel.org/r/20220630123445.v24.4.Ic9dd36078f9d803de82ca01a6700c58b8e4de27e@changeid
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-07-08 14:53:50 +02:00
Matthias Kaehlcke
8bc063641c usb: misc: Add onboard_usb_hub driver
The main issue this driver addresses is that a USB hub needs to be
powered before it can be discovered. For discrete onboard hubs (an
example for such a hub is the Realtek RTS5411) this is often solved
by supplying the hub with an 'always-on' regulator, which is kind
of a hack. Some onboard hubs may require further initialization
steps, like changing the state of a GPIO or enabling a clock, which
requires even more hacks. This driver creates a platform device
representing the hub which performs the necessary initialization.
Currently it only supports switching on a single regulator, support
for multiple regulators or other actions can be added as needed.
Different initialization sequences can be supported based on the
compatible string.

Besides performing the initialization the driver can be configured
to power the hub off during system suspend. This can help to extend
battery life on battery powered devices which have no requirements
to keep the hub powered during suspend. The driver can also be
configured to leave the hub powered when a wakeup capable USB device
is connected when suspending, and power it off otherwise.

Technically the driver consists of two drivers, the platform driver
described above and a very thin USB driver that subclasses the
generic driver. The purpose of this driver is to provide the platform
driver with the USB devices corresponding to the hub(s) (a hub
controller may provide multiple 'logical' hubs, e.g. one to support
USB 2.0 and another for USB 3.x).

Co-developed-by: Ravi Chandra Sadineni <ravisadineni@chromium.org>
Reviewed-by: Douglas Anderson <dianders@chromium.org>
Signed-off-by: Ravi Chandra Sadineni <ravisadineni@chromium.org>
Signed-off-by: Matthias Kaehlcke <mka@chromium.org>
Link: https://lore.kernel.org/r/20220630123445.v24.3.I7c9a1f1d6ced41dd8310e8a03da666a32364e790@changeid
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-07-08 14:53:50 +02:00
Arnd Bergmann
9ba26f5cec ARM: sa1100/assabet: move dmabounce hack to ohci driver
The sa1111 platform is one of the two remaining users of the old Arm
specific "dmabounce" code, which is an earlier implementation of the
generic swiotlb.

Linus Walleij submitted a patch that removes dmabounce support from
the ixp4xx, and I had a look at the other user, which is the sa1111
companion chip.

Looking at how dmabounce is used, I could narrow it down to one driver
one three machines:

 - dmabounce is only initialized on assabet/neponset, jornada720 and
   badge4, which are the platforms that have an sa1111 and support
   DMA on it.

 - All three of these suffer from "erratum #7" that requires only
   doing DMA to half the memory sections based on one of the address
   lines, in addition, the neponset also can't DMA to the RAM that
   is connected to sa1111 itself.

 - the pxa lubbock machine also has sa1111, but does not support DMA
   on it and does not set dmabounce.

 - only the OHCI and audio devices on sa1111 support DMA, but as
   there is no audio driver for this hardware, only OHCI remains.

In the OHCI code, I noticed that two other platforms already have
a local bounce buffer support in the form of the "local_mem"
allocator. Specifically, TMIO and SM501 use this on a few other ARM
boards with 16KB or 128KB of local SRAM that can be accessed from the
OHCI and from the CPU.

While this is not the same problem as on sa1111, I could not find a
reason why we can't re-use the existing implementation but replace the
physical SRAM address mapping with a locally allocated DMA buffer.

There are two main downsides:

 - rather than using a dynamically sized pool, this buffer needs
   to be allocated at probe time using a fixed size. Without
   having any idea of what it should be, I picked a size of
   64KB, which is between what the other two OHCI front-ends use
   in their SRAM. If anyone has a better idea what that size
   is reasonable, this can be trivially changed.

 - Previously, only USB transfers to unaddressable memory needed
   to go through the bounce buffer, now all of them do, which may
   impact runtime performance for USB endpoints that do a lot of
   transfers.

On the upside, the local_mem support uses write-combining buffers,
which should be a bit faster for transfers to the device compared to
normal uncached coherent memory as used in dmabounce.

Cc: Linus Walleij <linus.walleij@linaro.org>
Cc: Russell King <linux@armlinux.org.uk>
Cc: Christoph Hellwig <hch@infradead.org>
Cc: Laurentiu Tudor <laurentiu.tudor@nxp.com>
Cc: linux-usb@vger.kernel.org
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Christoph Hellwig <hch@lst.de>
2022-07-07 18:18:47 +02:00
Xuezhi Zhang
6569689e78 usb: core: sysfs: convert sysfs snprintf to sysfs_emit
Fix up all sysfs show entries to use sysfs_emit

Signed-off-by: Xuezhi Zhang <zhangxuezhi1@coolpad.com>
Link: https://lore.kernel.org/r/20220624121238.134256-1-zhangxuezhi1@coolpad.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-06-27 14:58:26 +02:00
Rafael J. Wysocki
bf5fb8ae82 USB: ACPI: Replace usb_acpi_find_port() with acpi_find_child_by_adr()
Instead of walking the list of children of an ACPI device directly
in order to find the child matching a given bus address, use
acpi_find_child_by_adr() for this purpose.

Also notice that if acpi_find_child_by_adr() doesn't find a matching
child, acpi_find_child_device() will not find it too, so directly
replace usb_acpi_find_port() in usb_acpi_get_companion_for_port() with
acpi_find_child_by_adr() and drop it entirely.

Apart from simplifying the code, this will help to eliminate the
children list head from struct acpi_device as it is redundant and it
is used in questionable ways in some places (in particular, locking is
needed for walking the list pointed to it safely, but it is often
missing).

Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Reviewed-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
2022-06-20 20:32:59 +02:00
Mathias Nyman
e146caf303 usb: Avoid extra usb SET_SEL requests when enabling link power management
The host needs to tell the device the exit latencies using the SET_SEL
request before device initiated link powermanagement can be enabled.

The exit latency values do not change after enumeration, it's enough
to set them once. So do like Windows 10 and issue the SET_SEL request
once just before setting the configuration.

This is also the sequence described in USB 3.2 specs "9.1.2 Bus
enumeration". SET_SEL is issued once before the Set Configuration
request, and won't be cleared by the Set Configuration,
Set Interface or ClearFeature (STALL) requests.

Only warm reset, hot reset, set Address 0 clears the exit latencies.
See USB 3.2 section 9.4.14 Table 9-10 Device parameters and events

Add udev->lpm_devinit_allow, and set it if SET_SEL was successful.
If not set, then don't try to enable device initiated LPM

We used to issue a SET_SEL request every time lpm is enabled for either
U1 or U2 link states, meaning a SET_SEL was issued twice after every
Set Configuration and Set Interface requests, easily accumulating to
over 15 SET_SEL requets during a USB3 webcam enumeration.

Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
Link: https://lore.kernel.org/r/20220506161807.3369439-1-mathias.nyman@linux.intel.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-06-12 06:49:47 +02:00
Michael Grzeschik
f061f43d74 usb: hub: port: add sysfs entry to switch port power
In some cases the port of an hub needs to be disabled or switched off
and on again. E.g. when the connected device needs to be re-enumerated.
Or it needs to be explicitly disabled while the rest of the usb tree
stays working.

For this purpose this patch adds an sysfs switch to enable/disable the
port on any hub. In the case the hub is supporting power switching, the
power line will be disabled to the connected device.

When the port gets disabled, the associated device gets disconnected and
removed from the logical usb tree. No further device will be enumerated
on that port until the port gets enabled again.

Reviewed-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Michael Grzeschik <m.grzeschik@pengutronix.de>
Link: https://lore.kernel.org/r/20220607114522.3359148-1-m.grzeschik@pengutronix.de
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-06-12 06:49:46 +02:00
Monish Kumar R
97fa5887cf USB: new quirk for Dell Gen 2 devices
Add USB_QUIRK_NO_LPM and USB_QUIRK_RESET_RESUME quirks for Dell usb gen
2 device to not fail during enumeration.

Found this bug on own testing

Signed-off-by: Monish Kumar R <monish.kumar.r@intel.com>
Cc: stable <stable@vger.kernel.org>
Link: https://lore.kernel.org/r/20220520130044.17303-1-monish.kumar.r@intel.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-05-20 21:18:23 +02:00
Bhuvanesh Surachari
6c5ba7395b usb: hub: Simplify error and success path in port_over_current_notify
kasprintf() returns NULL or valid pointer. Since kfree() can handle
NULL pointer condition, simplify error and success paths in function
port_over_current_notify() by removing multiple error path labels.

Signed-off-by: Bhuvanesh Surachari <Bhuvanesh_Surachari@mentor.com>
Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com>
Link: https://lore.kernel.org/r/1652369834-4480-1-git-send-email-erosca@de.adit-jv.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-05-19 18:14:49 +02:00
Kishon Vijay Abraham I
a44623d927 usb: core: hcd: Add support for deferring roothub registration
It has been observed with certain PCIe USB cards (like Inateck connected
to AM64 EVM or J7200 EVM) that as soon as the primary roothub is
registered, port status change is handled even before xHC is running
leading to cold plug USB devices not detected. For such cases, registering
both the root hubs along with the second HCD is required. Add support for
deferring roothub registration in usb_add_hcd(), so that both primary and
secondary roothubs are registered along with the second HCD.

This patch has been added and reverted earier as it triggered a race
in usb device enumeration.
That race is now fixed in 5.16-rc3, and in stable back to 5.4
commit 6cca13de26 ("usb: hub: Fix locking issues with address0_mutex")
commit 6ae6dc22d2 ("usb: hub: Fix usb enumeration issue due to address0
race")

CC: stable@vger.kernel.org # 5.4+
Suggested-by: Mathias Nyman <mathias.nyman@linux.intel.com>
Tested-by: Chris Chiu <chris.chiu@canonical.com>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
Link: https://lore.kernel.org/r/20220510091630.16564-2-kishon@ti.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-05-12 13:59:59 +02:00
Heikki Krogerus
f7ffaa6f62 usb: core: acpi: Use the sysdev pointer instead of controller device
The controller device (hcd) does not always have the ACPI
companion assigned to it at all. We can not rely on it when
finding the ACPI companion for the root hub. Instead we need
to use the sysdev pointer.

Signed-off-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Link: https://lore.kernel.org/r/20220428111056.3558-2-heikki.krogerus@linux.intel.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-05-05 21:57:31 +02:00
Greg Kroah-Hartman
f2b6e79c73 Revert "usb: core: hcd: Create platform devices for onboard hubs in probe()"
This reverts commit c40b62216c.

The series still has built errors as reported in linux-next, so revert
it for now.

Reported-by: Stephen Rothwell <sfr@canb.auug.org.au>
Link: https://lore.kernel.org/r/20220502210728.0b36f3cd@canb.auug.org.au
Cc: Stephen Boyd <swboyd@chromium.org>
Cc: Douglas Anderson <dianders@chromium.org>
Cc: Matthias Kaehlcke <mka@chromium.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-05-03 16:48:09 +02:00
Greg Kroah-Hartman
b9c92fb4aa Linux 5.18-rc5
-----BEGIN PGP SIGNATURE-----
 
 iQFSBAABCAA8FiEEq68RxlopcLEwq+PEeb4+QwBBGIYFAmJu9FYeHHRvcnZhbGRz
 QGxpbnV4LWZvdW5kYXRpb24ub3JnAAoJEHm+PkMAQRiGAyEH/16xtJSpLmLwrQzG
 o+4ToQxSQ+/9UHyu0RTEvHg2THm9/8emtIuYyc/5FgdoWctcSa3AaDcveWmuWmkS
 KYcdhfJsaEqjNHS3OPYXN84fmo9Hel7263shu5+IYmP/sN0DfQp6UWTryX1q4B3Q
 4Pdutkuq63Uwd8nBZ5LXQBumaBrmkkuMgWEdT4+6FOo1mPzwdIGBxCuz1UsNNl5k
 chLWxkQfe2eqgWbYJrgCQfrVdORXVtoU2fGilZUNrHRVGkkldXkkz5clJfapyZD3
 odmZCEbrE4GPKgZwCmDERMfD1hzhZDtYKiHfOQ506szH5ykJjPBcOjHed7dA60eB
 J3+wdek=
 =39Ca
 -----END PGP SIGNATURE-----

Merge 5.18-rc5 into usb-next

We need the USB fixes in here, and this resolves a merge issue in
drivers/usb/dwc3/drd.c

Reported-by: Stephen Rothwell <sfr@canb.auug.org.au>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-05-03 16:35:26 +02:00
Matthias Kaehlcke
c40b62216c usb: core: hcd: Create platform devices for onboard hubs in probe()
Call onboard_hub_create/destroy_pdevs() from usb_add/remove_hcd()
for primary HCDs to create/destroy platform devices for onboard
USB hubs that may be connected to the root hub of the controller.
These functions are a NOP unless CONFIG_USB_ONBOARD_HUB=y/m.

Also add a field to struct usb_hcd to keep track of the onboard hub
platform devices that are owned by the HCD.

Reviewed-by: Douglas Anderson <dianders@chromium.org>
Reviewed-by: Stephen Boyd <swboyd@chromium.org>
Signed-off-by: Matthias Kaehlcke <mka@chromium.org>
Link: https://lore.kernel.org/r/20220217104219.v21.3.I7a3a7d9d2126c34079b1cab87aa0b2ec3030f9b7@changeid
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-04-26 14:01:12 +02:00
Sergey Shtylyov
08908fa154 usb: core: devices: drop redundant buffer overflow checks
The USB device dump code often checks for the buffer overflow just before
calling the functions that do that first thing anyways.  Such checks are
redundant and may be dropped...

Signed-off-by: Sergey Shtylyov <s.shtylyov@omp.ru>
Link: https://lore.kernel.org/r/0453cb0d-7b2b-25e6-50e3-091610951e58@omp.ru
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-04-26 13:57:38 +02:00
Vincent Mailhol
dcd2e49b55 usb: remove third argument of usb_maxpacket()
The third argument of usb_maxpacket(): in_out has been deprecated
because it could be derived from the second argument (e.g. using
usb_pipeout(pipe)).

N.B. function usb_maxpacket() was made variadic to accommodate the
transition from the old prototype with three arguments to the new one
with only two arguments (so that no renaming is needed). The variadic
argument is to be removed once all users of usb_maxpacket() get
migrated.

CC: Duncan Sands <duncan.sands@free.fr>
CC: Alan Stern <stern@rowland.harvard.edu>
CC: Olav Kongas <ok@artecdesign.ee>
CC: Rui Miguel Silva <rui.silva@linaro.org>
Signed-off-by: Vincent Mailhol <mailhol.vincent@wanadoo.fr>
Link: https://lore.kernel.org/r/20220317035514.6378-7-mailhol.vincent@wanadoo.fr
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-04-23 10:33:53 +02:00
Evan Green
63acaa8e9c USB: hcd-pci: Fully suspend across freeze/thaw cycle
The documentation for the freeze() method says that it "should quiesce
the device so that it doesn't generate IRQs or DMA". The unspoken
consequence of not doing this is that MSIs aimed at non-boot CPUs may
get fully lost if they're sent during the period where the target CPU is
offline.

The current callbacks for USB HCD do not fully quiesce interrupts,
specifically on XHCI. Change to use the full suspend/resume flow for
freeze/thaw to ensure interrupts are fully quiesced. This fixes issues
where USB devices fail to thaw during hibernation because XHCI misses
its interrupt and cannot recover.

Acked-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Evan Green <evgreen@chromium.org>
Link: https://lore.kernel.org/r/20220421103751.v3.2.I8226c7fdae88329ef70957b96a39b346c69a914e@changeid
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-04-23 10:33:53 +02:00
Evan Green
9671d55037 USB: core: Disable remote wakeup for freeze/quiesce
The PM_EVENT_FREEZE and PM_EVENT_QUIESCE messages should cause the
device to stop generating interrupts. USB core was previously allowing
devices that were already runtime suspended to keep remote wakeup
enabled if they had gone down that way. This violates the contract with
pm, and can potentially cause MSI interrupts to be lost.

Change that so that if a device is runtime suspended with remote wakeups
enabled, it will be resumed to ensure remote wakeup is always disabled
across a freeze.

Acked-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Evan Green <evgreen@chromium.org>
Link: https://lore.kernel.org/r/20220421103751.v3.1.I2c636c4decc358f5e6c27b810748904cc69beada@changeid
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-04-23 10:33:52 +02:00
Sergey Shtylyov
4f8cfe675f usb: core: devices: remove dead code under #ifdef PROC_EXTRA
usb_dump_hub_descriptor() and usb_dump_string() are defined under #ifdef
PROC_EXTRA (while PROC_EXTRA doesn't seem to have ever been #define'd)
since the dawn of the git era -- remove this dead code at last...

Signed-off-by: Sergey Shtylyov <s.shtylyov@omp.ru>

Link: https://lore.kernel.org/r/ec08915b-faf2-2f0b-dfb1-048dfa2c67f3@omp.ru
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-04-21 19:20:42 +02:00
Tasos Sahanidis
0543e4e885 usb: core: Don't hold the device lock while sleeping in do_proc_control()
Since commit ae8709b296 ("USB: core: Make do_proc_control() and
do_proc_bulk() killable") if a device has the USB_QUIRK_DELAY_CTRL_MSG
quirk set, it will temporarily block all other URBs (e.g. interrupts)
while sleeping due to a control.

This results in noticeable delays when, for example, a userspace usbfs
application is sending URB interrupts at a high rate to a keyboard and
simultaneously updates the lock indicators using controls. Interrupts
with direction set to IN are also affected by this, meaning that
delivery of HID reports (containing scancodes) to the usbfs application
is delayed as well.

This patch fixes the regression by calling msleep() while the device
mutex is unlocked, as was the case originally with usb_control_msg().

Fixes: ae8709b296 ("USB: core: Make do_proc_control() and do_proc_bulk() killable")
Cc: stable <stable@kernel.org>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Tasos Sahanidis <tasos@tasossah.com>
Link: https://lore.kernel.org/r/3e299e2a-13b9-ddff-7fee-6845e868bc06@tasossah.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-04-21 19:17:00 +02:00
Christophe Leroy
eafc69a488 usb: Prepare cleanup of powerpc's asm/prom.h
powerpc's asm/prom.h brings some headers that it doesn't
need itself.

In order to clean it up in a further step, first clean all
files that include asm/prom.h

Some files don't need asm/prom.h at all. For those ones,
just remove inclusion of asm/prom.h

Some files don't need any of the items provided by asm/prom.h,
but need some of the headers included by asm/prom.h. For those
ones, add the needed headers that are brought by asm/prom.h at
the moment, then remove asm/prom.h

Some files really need asm/prom.h but also need some of the
headers included by asm/prom.h. For those one, leave asm/prom.h
but also add the needed headers so that they can be removed
from asm/prom.h in a later step.

Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu>
Link: https://lore.kernel.org/r/295e87a3094a92784657f7060fb0927e762a2e3c.1650011506.git.christophe.leroy@csgroup.eu
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-04-21 19:01:30 +02:00
Oliver Neukum
ec547af8a9 USB: quirks: add STRING quirk for VCOM device
This has been reported to stall if queried

Cc: stable <stable@vger.kernel.org>
Signed-off-by: Oliver Neukum <oneukum@suse.com>
Link: https://lore.kernel.org/r/20220414123152.1700-1-oneukum@suse.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-04-14 18:03:45 +02:00
Oliver Neukum
2a7ccf6bb6 USB: quirks: add a Realtek card reader
This device is reported to stall when enummerated.

Cc: stable <stable@vger.kernel.org>
Signed-off-by: Oliver Neukum <oneukum@suse.com>
Link: https://lore.kernel.org/r/20220414110209.30924-1-oneukum@suse.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-04-14 18:03:36 +02:00
Linus Torvalds
710f5d627a USB/Thunderbolt patches for 5.18-rc1
Here is the big set of USB and Thunderbolt changes for 5.18-rc1.
 
 Nothing major in here, just lots of little improvements and cleanups and
 new device support.  Highlights are:
 	- list iterator fixups for when we walk past the end of the list
 	  (a common problem that was cut/pasted in almost all USB gadget
 	  drivers)
 	- xen USB driver "hardening" for malicious hosts
 	- xhci driver updates and fixes for more hardware types
 	- xhci debug cable fixes to make it actually work again
 	- usb gadget audio driver improvements
 	- usb gadget storage fixes to work with OS-X
 	- lots of other small usb gadget fixes and updates
 	- USB DWC3 driver improvements for more hardware types
 	- Lots of other small USB driver improvements
 	- DTS updates for some USB platforms
 
 Note, the DTS updates will have a merge conflict in your tree.  The
 fixup should be simple, but if not, I can provide a merged tree if
 needed.
 
 All of these have been in linux-next for a while with no reported
 issues.
 
 Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
 -----BEGIN PGP SIGNATURE-----
 
 iG0EABECAC0WIQT0tgzFv3jCIUoxPcsxR9QN2y37KQUCYj7qpQ8cZ3JlZ0Brcm9h
 aC5jb20ACgkQMUfUDdst+ylRsQCcCryYifAvE2gHaNfI4B01JRWk7gQAoLNiUgvl
 l+srEAXgIVueDhmDxy5P
 =/Ppv
 -----END PGP SIGNATURE-----

Merge tag 'usb-5.18-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb

Pull USB/Thunderbolt updates from Greg KH:
 "Here is the big set of USB and Thunderbolt changes for 5.18-rc1.

  Nothing major in here, just lots of little improvements and cleanups
  and new device support. Highlights are:

   - list iterator fixups for when we walk past the end of the list (a
     common problem that was cut/pasted in almost all USB gadget
     drivers)

   - xen USB driver "hardening" for malicious hosts

   - xhci driver updates and fixes for more hardware types

   - xhci debug cable fixes to make it actually work again

   - usb gadget audio driver improvements

   - usb gadget storage fixes to work with OS-X

   - lots of other small usb gadget fixes and updates

   - USB DWC3 driver improvements for more hardware types

   - Lots of other small USB driver improvements

   - DTS updates for some USB platforms

  All of these have been in linux-next for a while with no reported
  issues"

* tag 'usb-5.18-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb: (172 commits)
  usb: gadget: fsl_qe_udc: Add missing semicolon in qe_ep_dequeue()
  dt-bindings: usb: mtk-xhci: add compatible for mt8186
  usb: dwc3: Issue core soft reset before enabling run/stop
  usb: gadget: Makefile: remove ccflags-y
  USB: usb-storage: Fix use of bitfields for hardware data in ene_ub6250.c
  usb: gadget: eliminate anonymous module_init & module_exit
  usb: usbip: eliminate anonymous module_init & module_exit
  xen/usb: harden xen_hcd against malicious backends
  usb: dwc3: gadget: Wait for ep0 xfers to complete during dequeue
  usb: dwc3: gadget: move cmd_endtransfer to extra function
  usb: dwc3: gadget: ep_queue simplify isoc start condition
  xen/usb: don't use arbitrary_virt_to_machine()
  usb: isp1760: remove redundant max_packet() macro
  usb: oxu210hp-hcd: remove redundant call to max_packet() macro
  usb: common: usb-conn-gpio: Make VBUS supply completely optional
  USB: storage: ums-realtek: fix error code in rts51x_read_mem()
  usb: early: xhci-dbc: Fix xdbc number parsing
  usb: early: xhci-dbc: Remove duplicate keep parsing
  x86/tsc: Be consistent about use_tsc_delay()
  usb: gadget: udc: s3c2410: remove usage of list iterator past the loop body
  ...
2022-03-26 13:08:25 -07:00
Youngjin Jang
a759de6991 PM: sleep: Add device name to suspend_report_result()
Currently, suspend_report_result() prints only function information.

If any driver uses a common PM function, nobody knows who exactly
called the failing function.

A device pinter is needed to recognize the failing device.

For example:

 PM: dpm_run_callback(): pnp_bus_suspend+0x0/0x10 returns 0
 PM: dpm_run_callback(): pci_pm_suspend+0x0/0x150 returns 0

become after the change:

 serial 00:05: PM: dpm_run_callback(): pnp_bus_suspend+0x0/0x10 returns 0
 pci 0000:00:01.3: PM: dpm_run_callback(): pci_pm_suspend+0x0/0x150 returns 0

Signed-off-by: Youngjin Jang <yj84.jang@samsung.com>
[ rjw: Changelog edits ]
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2022-03-08 19:57:01 +01:00
Alan Stern
f6a9a2d64d USB: core: Update kerneldoc for usb_get_dev() and usb_get_intf()
The kerneldoc for usb_get_dev() and usb_get_intf() says that drivers
should always refcount the references they hold for the usb_device or
usb_interface structure, respectively.  But this is an overstatement:
In many cases drivers do not access these references after they have
been unbound, and in such cases refcounting is unnecessary.

This patch updates the kerneldoc for the two routines, explaining when
a driver does not need to increment and decrement the refcount.  This
should help dispel misconceptions which might otherwise afflict
programmers new to the USB subsystem.

Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Link: https://lore.kernel.org/r/Yhjp4Rp9Alipmwtq@rowland.harvard.edu
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-02-25 16:53:41 +01:00
Mathias Nyman
cd36facf10 usb: remove Link Powermanagement (LPM) disable before port reset.
Trying to disable Link Powermanagement (LPM) before port reset is
unnecessary and can cause additional delay if host can't communicate
with the device, which is often the reason why device is reset in the
first place.

usb_disable_lpm() will
- zero usb U1/U2 timeouts for the hub downstream port
- send ENABLE U1/U2 clear feature requests to the connected device.
- increase internal reference count for udev->lpm_disable_count

There is no need to zero U1/U2 hub port timeouts, or clearing the
U1/U2 enable for the connected device before reset. These are set
to default by the reset.

USB 3.1 section 10.2.2 "HUB Downstream port U1/U2 timers" states that:
"the U1 and U2 timeout values for a downstream port reset to the default
values when the port receives a SetPortFeature request for a port reset"

Set the udev->lpm_disable_count to "1" after port reset, which is the
default lpm_disable_count value when allocating udev, representing
disabled LPM.

Cc: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
Link: https://lore.kernel.org/r/20220216095153.1303105-8-mathias.nyman@linux.intel.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-02-17 16:20:46 +01:00
Greg Kroah-Hartman
fbd533e90d Linux 5.17-rc4
-----BEGIN PGP SIGNATURE-----
 
 iQFSBAABCAA8FiEEq68RxlopcLEwq+PEeb4+QwBBGIYFAmIJZmoeHHRvcnZhbGRz
 QGxpbnV4LWZvdW5kYXRpb24ub3JnAAoJEHm+PkMAQRiGZdoH/04d8zUhM3Fd3ACB
 V/ONtOXmkfP2mEJSjb7cXTN1EM2SlOBdSnSsEw09FtGhjHABjOnLho4J5ixk9TH8
 zNMNI3EMksM2T9KadHwxv8Vvp1LTrWRzMbws8tOCPA0RkOpikJfClC8CzRAyidJ3
 cAbbDH/Jl1GnVZ8bpKmv2auYt+kNVGb0cwJ2W8phCwwkL7sLky5tgYeaGiJEXbJf
 Tfi/3qtFdmYjD8wtYnCfzjnB7suG5nF7rGEnxCIxNi+IA4DieUv2c1KchuoaBfT9
 df364VjKaGT3j+GB07ksQ/8mkwWiRXsCzOXAyMZSZaWjdMD4aAhCTJak5j7/TvGC
 wtgHPww=
 =/CMW
 -----END PGP SIGNATURE-----

Merge 5.17-rc4 into usb-next

We need the USB fixes in here as well.

Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-02-14 09:04:36 +01:00
Ingo Rohloff
6a3cd5bef2 USB: usbfs: Use a spinlock instead of atomic accesses to tally used memory.
While the existing code code imposes a limit on the used memory, it might be
over pessimistic (even if this is unlikely).

Example scenario:
8 threads running in parallel, all entering
"usbfs_increase_memory_usage()" at the same time.
The atomic accesses in "usbfs_increase_memory_usage()" could be
serialized like this:
  8 x "atomic64_add"
  8 x "atomic64_read"
If the 8 x "atomic64_add" raise "usbfs_memory_usage" above the limit,
then all 8 calls of "usbfs_increase_memory_usage()" will return with
-ENOMEM.  If you instead serialize over the whole access to
"usbfs_memory_usage" by using a spinlock, some of these calls will
succeed.

Acked-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Ingo Rohloff <ingo.rohloff@lauterbach.com>
Link: https://lore.kernel.org/r/20220209123303.103340-2-ingo.rohloff@lauterbach.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-02-11 11:01:09 +01:00
Fabio M. De Francesco
c853685d11 usb: core: Unregister device on component_add() failure
Commit 8c67d06f3f ("usb: Link the ports to the connectors they are
attached to") creates a link to the USB Type-C connector for every new
port that is added when possible. If component_add() fails,
usb_hub_create_port_device() prints a warning but does not unregister
the device and does not return errors to the callers.

Syzbot reported a "WARNING in component_del()".

Fix this issue in usb_hub_create_port_device by calling device_unregister()
and returning the errors from component_add().

Fixes: 8c67d06f3f ("usb: Link the ports to the connectors they are attached to")
Reported-and-tested-by: syzbot+60df062e1c41940cae0f@syzkaller.appspotmail.com
Reviewed-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Signed-off-by: Fabio M. De Francesco <fmdefrancesco@gmail.com>
Link: https://lore.kernel.org/r/20220209164500.8769-1-fmdefrancesco@gmail.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-02-11 10:57:21 +01:00
Rafael J. Wysocki
c067688ae2 USB: ACPI: Replace acpi_bus_get_device()
Replace acpi_bus_get_device() that is going to be dropped with
acpi_fetch_acpi_dev().

No intentional functional impact.

Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Link: https://lore.kernel.org/r/1899393.PYKUYFuaPT@kreacher
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-01-31 14:24:23 +01:00
Greg Kroah-Hartman
60c250a98d Linux 5.17-rc2
-----BEGIN PGP SIGNATURE-----
 
 iQFSBAABCAA8FiEEq68RxlopcLEwq+PEeb4+QwBBGIYFAmH2lIMeHHRvcnZhbGRz
 QGxpbnV4LWZvdW5kYXRpb24ub3JnAAoJEHm+PkMAQRiGWzkH/jmR4RpGgrV5SUHF
 8R6tsIjae1WItJ8NoaDgImWRxLKXFU7MM77HoFykuZx5Y5yz5Xf5zuJNXRPrHQbC
 lE/8wqWut89LX0+k/pKSzt8BQbyZzImfm5rOSBpMC9VkvMcbuQ8NSJ/YbJOD4iAp
 jfRRIkJtLQWL6YRc/xPlHCfVY5Qx+TkNZuFFckPtM2HKIEXS225VCESX9JcABDcQ
 j7zG5bq/H+8qGItD2iUg8Nw9hqrLutdKSOgP29wxVOajY5QWVczYr1J0nfyRSPMb
 /Xs1Oo1/+zO+dfCmR45puJZYua+e/iFTJv2RPFLRIE2AV1vMq4WNIgTJlq8DwfQK
 C7Jq080=
 =6u+c
 -----END PGP SIGNATURE-----

Merge tag 'v5.17-rc2' into usb-next

We need the USB fixes in here as well.

Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-01-31 10:13:10 +01:00
Bjorn Helgaas
5d0c4393b2 USB: hcd-pci: Use PCI_STD_NUM_BARS when checking standard BARs
usb_hcd_pci_probe() searches for an I/O BAR using a combination of
PCI_STD_NUM_BARS (to control loop iteration) and PCI_ROM_RESOURCE (to check
whether the loop exits without finding anything).

Use PCI_STD_NUM_BARS consistently.

No functional change since PCI_STD_NUM_BARS == PCI_ROM_RESOURCE, but this
removes a dependency on that relationship and makes the code read better.

Fixes: c9c13ba428 ("PCI: Add PCI_STD_NUM_BARS for the number of standard BARs")
Cc: Denis Efremov <efremov@linux.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Link: https://lore.kernel.org/r/20220121183330.1141702-1-helgaas@kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-01-26 14:02:51 +01:00
Kai-Heng Feng
c89686118c usb: core: Bail out when port is stuck in reset loop
Unplugging USB device may cause an incorrect warm reset loop and the
port can no longer be used:
[  143.039019] xhci_hcd 0000:00:14.0: Port change event, 2-3, id 19, portsc: 0x4202c0
[  143.039025] xhci_hcd 0000:00:14.0: handle_port_status: starting usb2 port polling.
[  143.039051] hub 2-0:1.0: state 7 ports 10 chg 0000 evt 0008
[  143.039058] xhci_hcd 0000:00:14.0: Get port status 2-3 read: 0x4202c0, return 0x4102c0
[  143.039092] xhci_hcd 0000:00:14.0: clear port3 connect change, portsc: 0x4002c0
[  143.039096] usb usb2-port3: link state change
[  143.039099] xhci_hcd 0000:00:14.0: clear port3 link state change, portsc: 0x2c0
[  143.039101] usb usb2-port3: do warm reset
[  143.096736] xhci_hcd 0000:00:14.0: Get port status 2-3 read: 0x2b0, return 0x2b0
[  143.096751] usb usb2-port3: not warm reset yet, waiting 50ms
[  143.131500] xhci_hcd 0000:00:14.0: Can't queue urb, port error, link inactive
[  143.138260] xhci_hcd 0000:00:14.0: Port change event, 2-3, id 19, portsc: 0x2802a0
[  143.138263] xhci_hcd 0000:00:14.0: handle_port_status: starting usb2 port polling.
[  143.160756] xhci_hcd 0000:00:14.0: Get port status 2-3 read: 0x2802a0, return 0x3002a0
[  143.160798] usb usb2-port3: not warm reset yet, waiting 200ms

The port status is PP=1, CCS=0, PED=0, PLS=Inactive, which is Error
state per "USB3 Root Hub Port State Machine". It's reasonable to perform
warm reset several times, but if the port is still not enabled after
many attempts, consider it's gone and treat it as disconnected.

Signed-off-by: Kai-Heng Feng <kai.heng.feng@canonical.com>
Link: https://lore.kernel.org/r/20220120070518.1643873-1-kai.heng.feng@canonical.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-01-26 14:01:50 +01:00
Alan Stern
26fbe9772b USB: core: Fix hang in usb_kill_urb by adding memory barriers
The syzbot fuzzer has identified a bug in which processes hang waiting
for usb_kill_urb() to return.  It turns out the issue is not unlinking
the URB; that works just fine.  Rather, the problem arises when the
wakeup notification that the URB has completed is not received.

The reason is memory-access ordering on SMP systems.  In outline form,
usb_kill_urb() and __usb_hcd_giveback_urb() operating concurrently on
different CPUs perform the following actions:

CPU 0					CPU 1
----------------------------		---------------------------------
usb_kill_urb():				__usb_hcd_giveback_urb():
  ...					  ...
  atomic_inc(&urb->reject);		  atomic_dec(&urb->use_count);
  ...					  ...
  wait_event(usb_kill_urb_queue,
	atomic_read(&urb->use_count) == 0);
					  if (atomic_read(&urb->reject))
						wake_up(&usb_kill_urb_queue);

Confining your attention to urb->reject and urb->use_count, you can
see that the overall pattern of accesses on CPU 0 is:

	write urb->reject, then read urb->use_count;

whereas the overall pattern of accesses on CPU 1 is:

	write urb->use_count, then read urb->reject.

This pattern is referred to in memory-model circles as SB (for "Store
Buffering"), and it is well known that without suitable enforcement of
the desired order of accesses -- in the form of memory barriers -- it
is entirely possible for one or both CPUs to execute their reads ahead
of their writes.  The end result will be that sometimes CPU 0 sees the
old un-decremented value of urb->use_count while CPU 1 sees the old
un-incremented value of urb->reject.  Consequently CPU 0 ends up on
the wait queue and never gets woken up, leading to the observed hang
in usb_kill_urb().

The same pattern of accesses occurs in usb_poison_urb() and the
failure pathway of usb_hcd_submit_urb().

The problem is fixed by adding suitable memory barriers.  To provide
proper memory-access ordering in the SB pattern, a full barrier is
required on both CPUs.  The atomic_inc() and atomic_dec() accesses
themselves don't provide any memory ordering, but since they are
present, we can use the optimized smp_mb__after_atomic() memory
barrier in the various routines to obtain the desired effect.

This patch adds the necessary memory barriers.

CC: <stable@vger.kernel.org>
Reported-and-tested-by: syzbot+76629376e06e2c2ad626@syzkaller.appspotmail.com
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Link: https://lore.kernel.org/r/Ye8K0QYee0Q0Nna2@rowland.harvard.edu
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-01-25 18:43:19 +01:00
Alan Stern
0f663729bb USB: core: Fix bug in resuming hub's handling of wakeup requests
Bugzilla #213839 reports a 7-port hub that doesn't work properly when
devices are plugged into some of the ports; the kernel goes into an
unending disconnect/reinitialize loop as shown in the bug report.

This "7-port hub" comprises two four-port hubs with one plugged into
the other; the failures occur when a device is plugged into one of the
downstream hub's ports.  (These hubs have other problems too.  For
example, they bill themselves as USB-2.0 compliant but they only run
at full speed.)

It turns out that the failures are caused by bugs in both the kernel
and the hub.  The hub's bug is that it reports a different
bmAttributes value in its configuration descriptor following a remote
wakeup (0xe0 before, 0xc0 after -- the wakeup-support bit has
changed).

The kernel's bug is inside the hub driver's resume handler.  When
hub_activate() sees that one of the hub's downstream ports got a
wakeup request from a child device, it notes this fact by setting the
corresponding bit in the hub->change_bits variable.  But this variable
is meant for connection changes, not wakeup events; setting it causes
the driver to believe the downstream port has been disconnected and
then connected again (in addition to having received a wakeup
request).

Because of this, the hub driver then tries to check whether the device
currently plugged into the downstream port is the same as the device
that had been attached there before.  Normally this check succeeds and
wakeup handling continues with no harm done (which is why the bug
remained undetected until now).  But with these dodgy hubs, the check
fails because the config descriptor has changed.  This causes the hub
driver to reinitialize the child device, leading to the
disconnect/reinitialize loop described in the bug report.

The proper way to note reception of a downstream wakeup request is
to set a bit in the hub->event_bits variable instead of
hub->change_bits.  That way the hub driver will realize that something
has happened to the port but will not think the port and child device
have been disconnected.  This patch makes that change.

Cc: <stable@vger.kernel.org>
Tested-by: Jonathan McDowell <noodles@earth.li>
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Link: https://lore.kernel.org/r/YdCw7nSfWYPKWQoD@rowland.harvard.edu
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-01-03 14:40:39 +01:00
Alan Stern
1d7d4c0793 USB: Fix "slab-out-of-bounds Write" bug in usb_hcd_poll_rh_status
When the USB core code for getting root-hub status reports was
originally written, it was assumed that the hub driver would be its
only caller.  But this isn't true now; user programs can use usbfs to
communicate with root hubs and get status reports.  When they do this,
they may use a transfer_buffer that is smaller than the data returned
by the HCD, which will lead to a buffer overflow error when
usb_hcd_poll_rh_status() tries to store the status data.  This was
discovered by syzbot:

BUG: KASAN: slab-out-of-bounds in memcpy include/linux/fortify-string.h:225 [inline]
BUG: KASAN: slab-out-of-bounds in usb_hcd_poll_rh_status+0x5f4/0x780 drivers/usb/core/hcd.c:776
Write of size 2 at addr ffff88801da403c0 by task syz-executor133/4062

This patch fixes the bug by reducing the amount of status data if it
won't fit in the transfer_buffer.  If some data gets discarded then
the URB's completion status is set to -EOVERFLOW rather than 0, to let
the user know what happened.

Reported-and-tested-by: syzbot+3ae6a2b06f131ab9849f@syzkaller.appspotmail.com
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Cc: <stable@vger.kernel.org>
Link: https://lore.kernel.org/r/Yc+3UIQJ2STbxNua@rowland.harvard.edu
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-01-03 14:38:34 +01:00
Heikki Krogerus
510a0bdb2b usb: Remove usb_for_each_port()
There are no more users for the function.

Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Link: https://lore.kernel.org/r/20211223082432.45653-1-heikki.krogerus@linux.intel.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-12-30 12:13:04 +01:00
Heikki Krogerus
8c67d06f3f usb: Link the ports to the connectors they are attached to
Creating link to the USB Type-C connector for every new port
that is added when possible.

Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Link: https://lore.kernel.org/r/20211223082349.45616-1-heikki.krogerus@linux.intel.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-12-30 12:13:04 +01:00
Greg Kroah-Hartman
236c9ad1f8 Linux 5.16-rc6
-----BEGIN PGP SIGNATURE-----
 
 iQFSBAABCAA8FiEEq68RxlopcLEwq+PEeb4+QwBBGIYFAmG/rsoeHHRvcnZhbGRz
 QGxpbnV4LWZvdW5kYXRpb24ub3JnAAoJEHm+PkMAQRiGLW8H/0sfRUxZNJ+DgO6W
 0LpyIx1DF7S2x1wOQGl7VZsjdy+dtuOW4BtEoqhuQWgQ2sr0zbavbeyZYTXD1+d6
 I1h5C6JMD138JkoqZNdeyWwsalAFtVItH+lzszUGKTxueTbKCJTkGMerBZVu/gVY
 U3QYZHEkUH6o/2fINYfSMhEgyJpjVEUoaztB2drsC0tNUGeDjTmrhlRrWIKZ6Kn+
 oAiMqsomSBF09TZ++GEqMYDTm39CwNDPJzKGyyOx86ydcg4ErWvjp1jfAUX0cvFG
 dso2K5mDzTewdF8bW0A1KvsQaliMFpxgZ5CTblYQ6HvyltjRj+0B8207VzHQXBKV
 YFZ8y9A=
 =mfug
 -----END PGP SIGNATURE-----

Merge 5.16-rc6 into usb-next

We need the USB fixes in here as well.

Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-12-20 09:58:10 +01:00
Razvan Heghedus
b1e9e7ebe6 usb: core: Export usb_device_match_id
Export usb_device_match_id so that it can be used for easily matching an
usb_device with a table of IDs.

Signed-off-by: Razvan Heghedus <heghedus.razvan@gmail.com>
Link: https://lore.kernel.org/r/20211213183617.14156-1-heghedus.razvan@gmail.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-12-17 17:02:04 +01:00
Kai-Heng Feng
0055858638 usb: hub: Add delay for SuperSpeed hub resume to let links transit to U0
When a new USB device gets plugged to nested hubs, the affected hub,
which connects to usb 2-1.4-port2, doesn't report there's any change,
hence the nested hubs go back to runtime suspend like nothing happened:
[  281.032951] usb usb2: usb wakeup-resume
[  281.032959] usb usb2: usb auto-resume
[  281.032974] hub 2-0:1.0: hub_resume
[  281.033011] usb usb2-port1: status 0263 change 0000
[  281.033077] hub 2-0:1.0: state 7 ports 4 chg 0000 evt 0000
[  281.049797] usb 2-1: usb wakeup-resume
[  281.069800] usb 2-1: Waited 0ms for CONNECT
[  281.069810] usb 2-1: finish resume
[  281.070026] hub 2-1:1.0: hub_resume
[  281.070250] usb 2-1-port4: status 0203 change 0000
[  281.070272] usb usb2-port1: resume, status 0
[  281.070282] hub 2-1:1.0: state 7 ports 4 chg 0010 evt 0000
[  281.089813] usb 2-1.4: usb wakeup-resume
[  281.109792] usb 2-1.4: Waited 0ms for CONNECT
[  281.109801] usb 2-1.4: finish resume
[  281.109991] hub 2-1.4:1.0: hub_resume
[  281.110147] usb 2-1.4-port2: status 0263 change 0000
[  281.110234] usb 2-1-port4: resume, status 0
[  281.110239] usb 2-1-port4: status 0203, change 0000, 10.0 Gb/s
[  281.110266] hub 2-1.4:1.0: state 7 ports 4 chg 0000 evt 0000
[  281.110426] hub 2-1.4:1.0: hub_suspend
[  281.110565] usb 2-1.4: usb auto-suspend, wakeup 1
[  281.130998] hub 2-1:1.0: hub_suspend
[  281.137788] usb 2-1: usb auto-suspend, wakeup 1
[  281.142935] hub 2-0:1.0: state 7 ports 4 chg 0000 evt 0000
[  281.177828] usb 2-1: usb wakeup-resume
[  281.197839] usb 2-1: Waited 0ms for CONNECT
[  281.197850] usb 2-1: finish resume
[  281.197984] hub 2-1:1.0: hub_resume
[  281.198203] usb 2-1-port4: status 0203 change 0000
[  281.198228] usb usb2-port1: resume, status 0
[  281.198237] hub 2-1:1.0: state 7 ports 4 chg 0010 evt 0000
[  281.217835] usb 2-1.4: usb wakeup-resume
[  281.237834] usb 2-1.4: Waited 0ms for CONNECT
[  281.237845] usb 2-1.4: finish resume
[  281.237990] hub 2-1.4:1.0: hub_resume
[  281.238067] usb 2-1.4-port2: status 0263 change 0000
[  281.238148] usb 2-1-port4: resume, status 0
[  281.238152] usb 2-1-port4: status 0203, change 0000, 10.0 Gb/s
[  281.238166] hub 2-1.4:1.0: state 7 ports 4 chg 0000 evt 0000
[  281.238385] hub 2-1.4:1.0: hub_suspend
[  281.238523] usb 2-1.4: usb auto-suspend, wakeup 1
[  281.258076] hub 2-1:1.0: hub_suspend
[  281.265744] usb 2-1: usb auto-suspend, wakeup 1
[  281.285976] hub 2-0:1.0: hub_suspend
[  281.285988] usb usb2: bus auto-suspend, wakeup 1

USB 3.2 spec, 9.2.5.4 "Changing Function Suspend State" says that "If
the link is in a non-U0 state, then the device must transition the link
to U0 prior to sending the remote wake message", but the hub only
transits the link to U0 after signaling remote wakeup.

So be more forgiving and use a 20ms delay to let the link transit to U0
for remote wakeup.

Suggested-by: Alan Stern <stern@rowland.harvard.edu>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Kai-Heng Feng <kai.heng.feng@canonical.com>
Link: https://lore.kernel.org/r/20211215120108.336597-1-kai.heng.feng@canonical.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-12-17 16:53:54 +01:00