Changes in 5.15.90
btrfs: fix trace event name typo for FLUSH_DELAYED_REFS
pNFS/filelayout: Fix coalescing test for single DS
selftests/bpf: check null propagation only neither reg is PTR_TO_BTF_ID
tools/virtio: initialize spinlocks in vring_test.c
virtio_pci: modify ENOENT to EINVAL
vduse: Validate vq_num in vduse_validate_config()
net/ethtool/ioctl: return -EOPNOTSUPP if we have no phy stats
r8169: move rtl_wol_enable_rx() and rtl_prepare_power_down()
RDMA/srp: Move large values to a new enum for gcc13
btrfs: always report error in run_one_delayed_ref()
x86/asm: Fix an assembler warning with current binutils
f2fs: let's avoid panic if extent_tree is not created
perf/x86/rapl: Treat Tigerlake like Icelake
fbdev: omapfb: avoid stack overflow warning
Bluetooth: hci_qca: Fix driver shutdown on closed serdev
wifi: brcmfmac: fix regression for Broadcom PCIe wifi devices
wifi: mac80211: sdata can be NULL during AMPDU start
Add exception protection processing for vd in axi_chan_handle_err function
zonefs: Detect append writes at invalid locations
nilfs2: fix general protection fault in nilfs_btree_insert()
efi: fix userspace infinite retry read efivars after EFI runtime services page fault
ALSA: hda/realtek: fix mute/micmute LEDs for a HP ProBook
ALSA: hda/realtek: fix mute/micmute LEDs don't work for a HP platform
drm/amdgpu: disable runtime pm on several sienna cichlid cards(v2)
drm/amd: Delay removal of the firmware framebuffer
hugetlb: unshare some PMDs when splitting VMAs
io_uring: don't gate task_work run on TIF_NOTIFY_SIGNAL
eventpoll: add EPOLL_URING_WAKE poll wakeup flag
eventfd: provide a eventfd_signal_mask() helper
io_uring: pass in EPOLL_URING_WAKE for eventfd signaling and wakeups
io_uring: improve send/recv error handling
io_uring: ensure recv and recvmsg handle MSG_WAITALL correctly
io_uring: add flag for disabling provided buffer recycling
io_uring: support MSG_WAITALL for IORING_OP_SEND(MSG)
io_uring: allow re-poll if we made progress
io_uring: fix async accept on O_NONBLOCK sockets
io_uring: ensure that cached task references are always put on exit
io_uring: remove duplicated calls to io_kiocb_ppos
io_uring: update kiocb->ki_pos at execution time
io_uring: do not recalculate ppos unnecessarily
io_uring/rw: defer fsnotify calls to task context
xhci-pci: set the dma max_seg_size
usb: xhci: Check endpoint is valid before dereferencing it
xhci: Fix null pointer dereference when host dies
xhci: Add update_hub_device override for PCI xHCI hosts
xhci: Add a flag to disable USB3 lpm on a xhci root port level.
usb: acpi: add helper to check port lpm capability using acpi _DSM
xhci: Detect lpm incapable xHC USB3 roothub ports from ACPI tables
prlimit: do_prlimit needs to have a speculation check
USB: serial: option: add Quectel EM05-G (GR) modem
USB: serial: option: add Quectel EM05-G (CS) modem
USB: serial: option: add Quectel EM05-G (RS) modem
USB: serial: option: add Quectel EC200U modem
USB: serial: option: add Quectel EM05CN (SG) modem
USB: serial: option: add Quectel EM05CN modem
staging: vchiq_arm: fix enum vchiq_status return types
USB: misc: iowarrior: fix up header size for USB_DEVICE_ID_CODEMERCS_IOW100
misc: fastrpc: Don't remove map on creater_process and device_release
misc: fastrpc: Fix use-after-free race condition for maps
usb: core: hub: disable autosuspend for TI TUSB8041
comedi: adv_pci1760: Fix PWM instruction handling
ACPI: PRM: Check whether EFI runtime is available
mmc: sunxi-mmc: Fix clock refcount imbalance during unbind
mmc: sdhci-esdhc-imx: correct the tuning start tap and step setting
btrfs: do not abort transaction on failure to write log tree when syncing log
btrfs: fix race between quota rescan and disable leading to NULL pointer deref
cifs: do not include page data when checking signature
thunderbolt: Use correct function to calculate maximum USB3 link rate
riscv: dts: sifive: fu740: fix size of pcie 32bit memory
bpf: restore the ebpf program ID for BPF_AUDIT_UNLOAD and PERF_BPF_EVENT_PROG_UNLOAD
staging: mt7621-dts: change some node hex addresses to lower case
tty: serial: qcom-geni-serial: fix slab-out-of-bounds on RX FIFO buffer
tty: fix possible null-ptr-defer in spk_ttyio_release
USB: gadgetfs: Fix race between mounting and unmounting
USB: serial: cp210x: add SCALANCE LPE-9000 device id
usb: cdns3: remove fetched trb from cache before dequeuing
usb: host: ehci-fsl: Fix module alias
usb: typec: tcpm: Fix altmode re-registration causes sysfs create fail
usb: typec: altmodes/displayport: Add pin assignment helper
usb: typec: altmodes/displayport: Fix pin assignment calculation
usb: gadget: g_webcam: Send color matching descriptor per frame
usb: gadget: f_ncm: fix potential NULL ptr deref in ncm_bitrate()
usb-storage: apply IGNORE_UAS only for HIKSEMI MD202 on RTL9210
dt-bindings: phy: g12a-usb2-phy: fix compatible string documentation
dt-bindings: phy: g12a-usb3-pcie-phy: fix compatible string documentation
serial: pch_uart: Pass correct sg to dma_unmap_sg()
dmaengine: lgm: Move DT parsing after initialization
dmaengine: tegra210-adma: fix global intr clear
dmaengine: idxd: Let probe fail when workqueue cannot be enabled
serial: amba-pl011: fix high priority character transmission in rs486 mode
serial: atmel: fix incorrect baudrate setup
gsmi: fix null-deref in gsmi_get_variable
mei: me: add meteor lake point M DID
drm/i915: re-disable RC6p on Sandy Bridge
drm/i915/display: Check source height is > 0
drm/amd/display: Fix set scaling doesn's work
drm/amd/display: Calculate output_color_space after pixel encoding adjustment
drm/amd/display: Fix COLOR_SPACE_YCBCR2020_TYPE matrix
drm/amdgpu: drop experimental flag on aldebaran
fs/ntfs3: Fix attr_punch_hole() null pointer derenference
arm64: efi: Execute runtime services from a dedicated stack
efi: rt-wrapper: Add missing include
Revert "drm/amdgpu: make display pinning more flexible (v2)"
x86/fpu: Use _Alignof to avoid undefined behavior in TYPE_ALIGN
tracing: Use alignof__(struct {type b;}) instead of offsetof()
io_uring: io_kiocb_update_pos() should not touch file for non -1 offset
io_uring/net: fix fast_iov assignment in io_setup_async_msg()
net/ulp: use consistent error code when blocking ULP
net/mlx5: fix missing mutex_unlock in mlx5_fw_fatal_reporter_err_work()
block: mq-deadline: Rename deadline_is_seq_writes()
Revert "wifi: mac80211: fix memory leak in ieee80211_if_add()"
soc: qcom: apr: Make qcom,protection-domain optional again
mm/khugepaged: fix collapse_pte_mapped_thp() to allow anon_vma
io_uring: Clean up a false-positive warning from GCC 9.3.0
io_uring: fix double poll leak on repolling
io_uring/rw: ensure kiocb_end_write() is always called
io_uring/rw: remove leftover debug statement
Linux 5.15.90
Change-Id: I8721d40cff2e6202b1aa7ed984e154a67d7c5276
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
commit 7171b0e261b17de96490adf053b8bb4b00061bcf upstream.
The Texas Instruments TUSB8041 has an autosuspend problem at high
temperature.
If there is not USB traffic, after a couple of ms, the device enters in
autosuspend mode. In this condition the external clock stops working, to
save energy. When the USB activity turns on, ther hub exits the
autosuspend state, the clock starts running again and all works fine.
At ambient temperature all works correctly, but at high temperature,
when the USB activity turns on, the external clock doesn't restart and
the hub disappears from the USB bus.
Disabling the autosuspend mode for this hub solves the issue.
Signed-off-by: Flavio Suligoi <f.suligoi@asem.it>
Cc: stable <stable@kernel.org>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Link: https://lore.kernel.org/r/20221219124759.3207032-1-f.suligoi@asem.it
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
When a broken USB accessory connects to a USB host, usbcore might
keep doing enumeration retries. If the host has a watchdog mechanism,
the kernel panic will happen on the host.
This patch provides an attribute early_stop to limit the numbers of retries
for each port of a hub. If a port was marked with early_stop attribute,
unsuccessful connection attempts will fail quickly. In addition, if an
early_stop port has failed to initialize, it will ignore all future
connection events until early_stop attribute is clear.
Signed-off-by: Ray Chi <raychi@google.com>
Reviewed-by: Alan Stern <stern@rowland.harvard.edu>
Link: https://lore.kernel.org/r/20221107072754.3336357-1-raychi@google.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Bug: 236915598
(cherry picked from commit 430d57f53eb1cdbf9ba9bbd397317912b3cd2de5
https: //git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git/ usb-next)
Change-Id: Ib85522ca38c0f26ece9807d5304991853f155669
Signed-off-by: Ray Chi <raychi@google.com>
(cherry picked from commit 92a7e867cf171c00aa0c7f1d39f36a11aed80bc5)
commit 9c6d778800b921bde3bff3cff5003d1650f942d1 upstream.
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>
Add vendor hook when core detect a new device. Vendor side
can use this hook to do several things. Our Unisoc ASIC had
some drawback. most scene, we use DWC3 controller and
associated PHY, when digital headset plug in, we need end the
enumeration and switch to another controller and phy. Using this
hook, we can do the switch easily and efficiently.
Bug: 229330749
Change-Id: I1cba28b43ff1b1f5ac0138c0bb743f3d8e9f1e4b
Signed-off-by: Yunxian He <yunxian.he@unisoc.com>
[ Upstream commit 00558586382891540c59c9febc671062425a6e47 ]
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>
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit 0f663729bb4afc92a9986b66131ebd5b8a9254d1 upstream.
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>
commit 6cca13de26eea6d32a98d96d916a048d16a12822 upstream.
Fix the circular lock dependency and unbalanced unlock of addess0_mutex
introduced when fixing an address0_mutex enumeration retry race in commit
ae6dc22d2d1 ("usb: hub: Fix usb enumeration issue due to address0 race")
Make sure locking order between port_dev->status_lock and address0_mutex
is correct, and that address0_mutex is not unlocked in hub_port_connect
"done:" codepath which may be reached without locking address0_mutex
Fixes: 6ae6dc22d2d1 ("usb: hub: Fix usb enumeration issue due to address0 race")
Cc: <stable@vger.kernel.org>
Reported-by: Marek Szyprowski <m.szyprowski@samsung.com>
Tested-by: Hans de Goede <hdegoede@redhat.com>
Tested-by: Marek Szyprowski <m.szyprowski@samsung.com>
Acked-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
Link: https://lore.kernel.org/r/20211123101656.1113518-1-mathias.nyman@linux.intel.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 6ae6dc22d2d1ce6aa77a6da8a761e61aca216f8b upstream.
xHC hardware can only have one slot in default state with address 0
waiting for a unique address at a time, otherwise "undefined behavior
may occur" according to xhci spec 5.4.3.4
The address0_mutex exists to prevent this across both xhci roothubs.
If hub_port_init() fails, it may unlock the mutex and exit with a xhci
slot in default state. If the other xhci roothub calls hub_port_init()
at this point we end up with two slots in default state.
Make sure the address0_mutex protects the slot default state across
hub_port_init() retries, until slot is addressed or disabled.
Note, one known minor case is not fixed by this patch.
If device needs to be reset during resume, but fails all hub_port_init()
retries in usb_reset_and_verify_device(), then it's possible the slot is
still left in default state when address0_mutex is unlocked.
Cc: <stable@vger.kernel.org>
Fixes: 638139eb95 ("usb: hub: allow to process more usb hub events in parallel")
Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
Link: https://lore.kernel.org/r/20211115221630.871204-1-mathias.nyman@linux.intel.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The device initiated link power management U1/U2 states should not be
enabled in case the system exit latency plus one bus interval (125us) is
greater than the shortest service interval of any periodic endpoint.
This is the case for both U1 and U2 sytstem exit latencies and link states.
See USB 3.2 section 9.4.9 "Set Feature" for more details
Note, before this patch the host and device initiated U1/U2 lpm states
were both enabled with lpm. After this patch it's possible to end up with
only host inititated U1/U2 lpm in case the exit latencies won't allow
device initiated lpm.
If this case we still want to set the udev->usb3_lpm_ux_enabled flag so
that sysfs users can see the link may go to U1/U2.
Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
Cc: stable <stable@vger.kernel.org>
Link: https://lore.kernel.org/r/20210715150122.1995966-2-mathias.nyman@linux.intel.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Maximum Exit Latency (MEL) value is used by host to know how much in
advance it needs to start waking up a U1/U2 suspended link in order to
service a periodic transfer in time.
Current MEL calculation only includes the time to wake up the path from
U1/U2 to U0. This is called tMEL1 in USB 3.1 section C 1.5.2
Total MEL = tMEL1 + tMEL2 +tMEL3 + tMEL4 which should additinally include:
- tMEL2 which is the time it takes for PING message to reach device
- tMEL3 time for device to process the PING and submit a PING_RESPONSE
- tMEL4 time for PING_RESPONSE to traverse back upstream to host.
Add the missing tMEL2, tMEL3 and tMEL4 to MEL calculation.
Cc: <stable@kernel.org> # v3.5
Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
Link: https://lore.kernel.org/r/20210715150122.1995966-1-mathias.nyman@linux.intel.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The Cypress CY7C65632 appears to have an issue with auto suspend and
detecting devices, not too dissimilar to the SMSC 5534B hub. It is
easiest to reproduce by connecting multiple mass storage devices to
the hub at the same time. On a Lenovo Yoga, around 1 in 3 attempts
result in the devices not being detected. It is however possible to
make them appear using lsusb -v.
Disabling autosuspend for this hub resolves the issue.
Fixes: 1208f9e1d7 ("USB: hub: Fix the broken detection of USB3 device in SMSC hub")
Cc: stable@vger.kernel.org
Signed-off-by: Andrew Lunn <andrew@lunn.ch>
Link: https://lore.kernel.org/r/20210614155524.2228800-1-andrew@lunn.ch
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Move the "removable" attribute from USB to core in order to allow it to be
supported by other subsystem / buses. Individual buses that want to support
this attribute can populate the removable property of the device while
enumerating it with the 3 possible values -
- "unknown"
- "fixed"
- "removable"
Leaving the field unchanged (i.e. "not supported") would mean that the
attribute would not show up in sysfs for that device. The UAPI (location,
symantics etc) for the attribute remains unchanged.
Move the "removable" attribute from USB to the device core so it can be
used by other subsystems / buses.
By default, devices do not have a "removable" attribute in sysfs.
If a subsystem or bus driver wants to support a "removable" attribute, it
should call device_set_removable() before calling device_register() or
device_add(), e.g.:
device_set_removable(dev, DEVICE_REMOVABLE);
device_register(dev);
The possible values and the resulting sysfs attribute contents are:
DEVICE_REMOVABLE_UNKNOWN -> "unknown"
DEVICE_REMOVABLE -> "removable"
DEVICE_FIXED -> "fixed"
Convert the USB "removable" attribute to use this new device core
functionality. There should be no user-visible change in the location or
semantics of attribute for USB devices.
Reviewed-by: Bjorn Helgaas <bhelgaas@google.com>
Signed-off-by: Rajat Jain <rajatja@google.com>
Link: https://lore.kernel.org/r/20210524171812.18095-1-rajatja@google.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The usage of in_interrupt() in drivers is phased out for various reasons.
Various comments use !in_interrupt() to describe calling context for
functions which might sleep. That's wrong because the calling context has
to be preemptible task context, which is not what !in_interrupt()
describes.
Replace !in_interrupt() with more accurate plain text descriptions.
The comment for usb_hcd_poll_rh_status() is misleading as this function is
called from all kinds of contexts including preemptible task
context. Remove it as there is obviously no restriction.
Signed-off-by: Ahmed S. Darwish <a.darwish@linutronix.de>
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Cc: linux-usb@vger.kernel.org
Link: https://lore.kernel.org/r/20201019101110.851821025@linutronix.de
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Description based on one by Yasushi Asano:
According to 6.7.22 A-UUT “Device No Response” for connection timeout
of USB OTG and EH automated compliance plan v1.2, enumeration failure
has to be detected within 30 seconds. However, the old and new
enumeration schemes each make a total of 12 attempts, and each attempt
can take 5 seconds to time out, so the PET test fails.
This patch adds a new Kconfig option (CONFIG_USB_FEW_INIT_RETRIES);
when the option is set all the initialization retry loops except the
outermost are reduced to a single iteration. This reduces the total
number of attempts to four, allowing Linux hosts to pass the PET test.
The new option is disabled by default to preserve the existing
behavior. The reduced number of retries may fail to initialize a few
devices that currently do work, but for the most part there should be
no change. And in cases where the initialization does fail, it will
fail much more quickly.
Reported-and-tested-by: yasushi asano <yazzep@gmail.com>
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Link: https://lore.kernel.org/r/20200928152217.GB134701@rowland.harvard.edu
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The SET_CONFIG_TRIES macro in hub.c is badly named; it controls the
number of port-initialization retry attempts rather than the number of
Set-Configuration attempts. Furthermore, the USE_NEW_SCHEME macro and
use_new_scheme() function are written in a very confusing manner,
making it almost impossible to figure out exactly what they do or
check that they are correct.
This patch renames SET_CONFIG_TRIES to PORT_INIT_TRIES, removes
USE_NEW_SCHEME entirely, and rewrites use_new_scheme() to be much more
transparent, with added comments explaining how it works. The patch
also pulls the single call site of use_new_scheme() out from the
Get-Descriptor retry loop (where it returns the same value each time)
and renames the local variable used to store the result.
The overall effect is a minor cleanup. However, there is one
functional change: If the "use_both_schemes" module parameter isn't
set (by default it is set), the existing code does only two retry
iterations. After this patch it will always perform four, regardless
of the parameter's value.
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Link: https://lore.kernel.org/r/20200928152050.GA134701@rowland.harvard.edu
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
This reverts commit d6a4992495.
Control messages are needed in contexts when memory allocations
are restricted, such as handling device resets and runtime PM.
For this reason the control message API internally uses GFP_NOIO.
This is a band aid introduced because when we recognized the issue,
the call chains were highly convoluted. Continuing this trend
is not a good idea.
So I am shooting the whole kennel here.
Signed-off-by: Oliver Neukum <oneukum@suse.com>
Link: https://lore.kernel.org/r/20200923134348.23862-2-oneukum@suse.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Commit bd0e6c9614 ("usb: hub: try old enumeration scheme first for
high speed devices") changed the way the hub driver enumerates
high-speed devices. Instead of using the "new" enumeration scheme
first and switching to the "old" scheme if that doesn't work, we start
with the "old" scheme. In theory this is better because the "old"
scheme is slightly faster -- it involves resetting the device only
once instead of twice.
However, for a long time Windows used only the "new" scheme. Zeng Tao
said that Windows 8 and later use the "old" scheme for high-speed
devices, but apparently there are some devices that don't like it.
William Bader reports that the Ricoh webcam built into his Sony Vaio
laptop not only doesn't enumerate under the "old" scheme, it gets hung
up so badly that it won't then enumerate under the "new" scheme! Only
a cold reset will fix it.
Therefore we will revert the commit and go back to trying the "new"
scheme first for high-speed devices.
Reported-and-tested-by: William Bader <williambader@hotmail.com>
Ref: https://bugzilla.kernel.org/show_bug.cgi?id=207219
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Fixes: bd0e6c9614 ("usb: hub: try old enumeration scheme first for high speed devices")
CC: Zeng Tao <prime.zeng@hisilicon.com>
CC: <stable@vger.kernel.org>
Link: https://lore.kernel.org/r/Pine.LNX.4.44L0.2004221611230.11262-100000@iolanthe.rowland.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Commit 8099f58f1e ("USB: hub: Don't record a connect-change event
during reset-resume") wasn't very well conceived. The problem it
tried to fix was that if a connect-change event occurred while the
system was asleep (such as a device disconnecting itself from the bus
when it is suspended and then reconnecting when it resumes)
requiring a reset-resume during the system wakeup transition, the hub
port's change_bit entry would remain set afterward. This would cause
the hub driver to believe another connect-change event had occurred
after the reset-resume, which was wrong and would lead the driver to
send unnecessary requests to the device (which could interfere with a
firmware update).
The commit tried to fix this by not setting the change_bit during the
wakeup. But this was the wrong thing to do; it means that when a
device is unplugged while the system is asleep, the hub driver doesn't
realize anything has happened: The change_bit flag which would tell it
to handle the disconnect event is clear.
The commit needs to be reverted and the problem fixed in a different
way. Fortunately an alternative solution was noted in the commit's
Changelog: We can continue to set the change_bit entry in
hub_activate() but then clear it when a reset-resume occurs. That way
the the hub driver will see the change_bit when a device is
disconnected but won't see it when the device is still present.
That's what this patch does.
Reported-and-tested-by: Peter Chen <peter.chen@nxp.com>
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Fixes: 8099f58f1e ("USB: hub: Don't record a connect-change event during reset-resume")
Tested-by: Paul Zimmerman <pauldzim@gmail.com>
CC: <stable@vger.kernel.org>
Link: https://lore.kernel.org/r/Pine.LNX.4.44L0.2004221602480.11262-100000@iolanthe.rowland.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Address below Coverity complaint (Feb 25, 2020, 8:06 AM CET):
*** CID 1458999: Error handling issues (CHECKED_RETURN)
/drivers/usb/core/hub.c: 1869 in hub_probe()
1863
1864 if (id->driver_info & HUB_QUIRK_CHECK_PORT_AUTOSUSPEND)
1865 hub->quirk_check_port_auto_suspend = 1;
1866
1867 if (id->driver_info & HUB_QUIRK_DISABLE_AUTOSUSPEND) {
1868 hub->quirk_disable_autosuspend = 1;
>>> CID 1458999: Error handling issues (CHECKED_RETURN)
>>> Calling "usb_autopm_get_interface" without checking return value (as is done elsewhere 97 out of 111 times).
1869 usb_autopm_get_interface(intf);
1870 }
1871
1872 if (hub_configure(hub, &desc->endpoint[0].desc) >= 0)
1873 return 0;
1874
Rather than checking the return value of 'usb_autopm_get_interface()',
switch to the usb_autopm_get_interface_no_resume() API, as per:
On Tue, Feb 25, 2020 at 10:32:32AM -0500, Alan Stern wrote:
------ 8< ------
> This change (i.e. 'ret = usb_autopm_get_interface') is not necessary,
> because the resume operation cannot fail at this point (interfaces
> are always powered-up during probe). A better solution would be to
> call usb_autopm_get_interface_no_resume() instead.
------ 8< ------
Fixes: 1208f9e1d7 ("USB: hub: Fix the broken detection of USB3 device in SMSC hub")
Cc: Hardik Gajjar <hgajjar@de.adit-jv.com>
Cc: stable@vger.kernel.org # v4.14+
Reported-by: scan-admin@coverity.com
Suggested-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Link: https://lore.kernel.org/r/20200226175036.14946-1-erosca@de.adit-jv.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Paul Zimmerman reports that his USB Bluetooth adapter sometimes
crashes following system resume, when it receives a
Get-Device-Descriptor request while it is busy doing something else.
Such a request was added by commit a4f55d8b8c ("usb: hub: Check
device descriptor before resusciation"). It gets sent when the hub
driver's work thread checks whether a connect-change event on an
enabled port really indicates a new device has been connected, as
opposed to an old device momentarily disconnecting and then
reconnecting (which can happen with xHCI host controllers, since they
automatically enable connected ports).
The same kind of thing occurs when a port's power session is lost
during system suspend. When the system wakes up it sees a
connect-change event on the port, and if the child device's
persist_enabled flag was set then hub_activate() sets the device's
reset_resume flag as well as the port's bit in hub->change_bits. The
reset-resume code then takes responsibility for checking that the same
device is still attached to the port, and it does this as part of the
device's resume pathway. By the time the hub driver's work thread
starts up again, the device has already been fully reinitialized and
is busy doing its own thing. There's no need for the work thread to
do the same check a second time, and in fact this unnecessary check is
what caused the problem that Paul observed.
Note that performing the unnecessary check is not actually a bug.
Devices are supposed to be able to send descriptors back to the host
even when they are busy doing something else. The underlying cause of
Paul's problem lies in his Bluetooth adapter. Nevertheless, we
shouldn't perform the same check twice in a row -- and as a nice side
benefit, removing the extra check allows the Bluetooth adapter to work
more reliably.
The work thread performs its check when it sees that the port's bit is
set in hub->change_bits. In this situation that bit is interpreted as
though a connect-change event had occurred on the port _after_ the
reset-resume, which is not what actually happened.
One possible fix would be to make the reset-resume code clear the
port's bit in hub->change_bits. But it seems simpler to just avoid
setting the bit during hub_activate() in the first place. That's what
this patch does.
(Proving that the patch is correct when CONFIG_PM is disabled requires
a little thought. In that setting hub_activate() will be called only
for initialization and resets, since there won't be any resumes or
reset-resumes. During initialization and hub resets the hub doesn't
have any child devices, and so this code path never gets executed.)
Reported-and-tested-by: Paul Zimmerman <pauldzim@gmail.com>
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Link: https://marc.info/?t=157949360700001&r=1&w=2
CC: David Heinzelmann <heinzelmann.david@gmail.com>
CC: <stable@vger.kernel.org>
Link: https://lore.kernel.org/r/Pine.LNX.4.44L0.2001311037460.1577-100000@iolanthe.rowland.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Renesas R-Car H3ULCB + Kingfisher Infotainment Board is either not able
to detect the USB3.0 mass storage devices or is detecting those as
USB2.0 high speed devices.
The explanation given by Renesas is that, due to a HW issue, the XHCI
driver does not wake up after going to sleep on connecting a USB3.0
device.
In order to mitigate that, disable the auto-suspend feature
specifically for SMSC hubs from hub_probe() function, as a quirk.
Renesas Kingfisher Infotainment Board has two USB3.0 ports (CN2) which
are connected via USB5534B 4-port SuperSpeed/Hi-Speed, low-power,
configurable hub controller.
[1] SanDisk USB 3.0 device detected as USB-2.0 before the patch
[ 74.036390] usb 5-1.1: new high-speed USB device number 4 using xhci-hcd
[ 74.061598] usb 5-1.1: New USB device found, idVendor=0781, idProduct=5581, bcdDevice= 1.00
[ 74.069976] usb 5-1.1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[ 74.077303] usb 5-1.1: Product: Ultra
[ 74.080980] usb 5-1.1: Manufacturer: SanDisk
[ 74.085263] usb 5-1.1: SerialNumber: 4C530001110208116550
[2] SanDisk USB 3.0 device detected as USB-3.0 after the patch
[ 34.565078] usb 6-1.1: new SuperSpeed Gen 1 USB device number 3 using xhci-hcd
[ 34.588719] usb 6-1.1: New USB device found, idVendor=0781, idProduct=5581, bcdDevice= 1.00
[ 34.597098] usb 6-1.1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[ 34.604430] usb 6-1.1: Product: Ultra
[ 34.608110] usb 6-1.1: Manufacturer: SanDisk
[ 34.612397] usb 6-1.1: SerialNumber: 4C530001110208116550
Suggested-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Hardik Gajjar <hgajjar@de.adit-jv.com>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Tested-by: Eugeniu Rosca <erosca@de.adit-jv.com>
Cc: stable <stable@vger.kernel.org>
Link: https://lore.kernel.org/r/1580989763-32291-1-git-send-email-hgajjar@de.adit-jv.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
If hub_activate() is called before D+ has stabilized after remote
wakeup, the following situation might occur:
__ ___________________
/ \ /
D+ __/ \__/
Hub _______________________________
| ^ ^ ^
| | | |
Host _____v__|___|___________|______
| | | |
| | | \-- Interrupt Transfer (*3)
| | \-- ClearPortFeature (*2)
| \-- GetPortStatus (*1)
\-- Host detects remote wakeup
- D+ goes high, Host starts running by remote wakeup
- D+ is not stable, goes low
- Host requests GetPortStatus at (*1) and gets the following hub status:
- Current Connect Status bit is 0
- Connect Status Change bit is 1
- D+ stabilizes, goes high
- Host requests ClearPortFeature and thus Connect Status Change bit is
cleared at (*2)
- After waiting 100 ms, Host starts the Interrupt Transfer at (*3)
- Since the Connect Status Change bit is 0, Hub returns NAK.
In this case, port_event() is not called in hub_event() and Host cannot
recognize device. To solve this issue, flag change_bits even if only
Connect Status Change bit is 1 when got in the first GetPortStatus.
This issue occurs rarely because it only if D+ changes during a very
short time between GetPortStatus and ClearPortFeature. However, it is
fatal if it occurs in embedded system.
Signed-off-by: Keiya Nobuta <nobuta.keiya@fujitsu.com>
Cc: stable <stable@vger.kernel.org>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Link: https://lore.kernel.org/r/20200109051448.28150-1-nobuta.keiya@fujitsu.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
On Dell WD15 dock, sometimes USB ethernet cannot be detected after plugging
cable to the ethernet port, the hub and roothub get runtime resumed and
runtime suspended immediately:
...
[ 433.315169] xhci_hcd 0000:3a:00.0: hcd_pci_runtime_resume: 0
[ 433.315204] usb usb4: usb auto-resume
[ 433.315226] hub 4-0:1.0: hub_resume
[ 433.315239] xhci_hcd 0000:3a:00.0: Get port status 4-1 read: 0x10202e2, return 0x10343
[ 433.315264] usb usb4-port1: status 0343 change 0001
[ 433.315279] xhci_hcd 0000:3a:00.0: clear port1 connect change, portsc: 0x10002e2
[ 433.315293] xhci_hcd 0000:3a:00.0: Get port status 4-2 read: 0x2a0, return 0x2a0
[ 433.317012] xhci_hcd 0000:3a:00.0: xhci_hub_status_data: stopping port polling.
[ 433.422282] xhci_hcd 0000:3a:00.0: Get port status 4-1 read: 0x10002e2, return 0x343
[ 433.422307] usb usb4-port1: do warm reset
[ 433.422311] usb 4-1: device reset not allowed in state 8
[ 433.422339] hub 4-0:1.0: state 7 ports 2 chg 0002 evt 0000
[ 433.422346] xhci_hcd 0000:3a:00.0: Get port status 4-1 read: 0x10002e2, return 0x343
[ 433.422356] usb usb4-port1: do warm reset
[ 433.422358] usb 4-1: device reset not allowed in state 8
[ 433.422428] xhci_hcd 0000:3a:00.0: set port remote wake mask, actual port 0 status = 0xf0002e2
[ 433.422455] xhci_hcd 0000:3a:00.0: set port remote wake mask, actual port 1 status = 0xe0002a0
[ 433.422465] hub 4-0:1.0: hub_suspend
[ 433.422475] usb usb4: bus auto-suspend, wakeup 1
[ 433.426161] xhci_hcd 0000:3a:00.0: xhci_hub_status_data: stopping port polling.
[ 433.466209] xhci_hcd 0000:3a:00.0: port 0 polling in bus suspend, waiting
[ 433.510204] xhci_hcd 0000:3a:00.0: port 0 polling in bus suspend, waiting
[ 433.554051] xhci_hcd 0000:3a:00.0: port 0 polling in bus suspend, waiting
[ 433.598235] xhci_hcd 0000:3a:00.0: port 0 polling in bus suspend, waiting
[ 433.642154] xhci_hcd 0000:3a:00.0: port 0 polling in bus suspend, waiting
[ 433.686204] xhci_hcd 0000:3a:00.0: port 0 polling in bus suspend, waiting
[ 433.730205] xhci_hcd 0000:3a:00.0: port 0 polling in bus suspend, waiting
[ 433.774203] xhci_hcd 0000:3a:00.0: port 0 polling in bus suspend, waiting
[ 433.818207] xhci_hcd 0000:3a:00.0: port 0 polling in bus suspend, waiting
[ 433.862040] xhci_hcd 0000:3a:00.0: port 0 polling in bus suspend, waiting
[ 433.862053] xhci_hcd 0000:3a:00.0: xhci_hub_status_data: stopping port polling.
[ 433.862077] xhci_hcd 0000:3a:00.0: xhci_suspend: stopping port polling.
[ 433.862096] xhci_hcd 0000:3a:00.0: // Setting command ring address to 0x8578fc001
[ 433.862312] xhci_hcd 0000:3a:00.0: hcd_pci_runtime_suspend: 0
[ 433.862445] xhci_hcd 0000:3a:00.0: PME# enabled
[ 433.902376] xhci_hcd 0000:3a:00.0: restoring config space at offset 0xc (was 0x0, writing 0x20)
[ 433.902395] xhci_hcd 0000:3a:00.0: restoring config space at offset 0x4 (was 0x100000, writing 0x100403)
[ 433.902490] xhci_hcd 0000:3a:00.0: PME# disabled
[ 433.902504] xhci_hcd 0000:3a:00.0: enabling bus mastering
[ 433.902547] xhci_hcd 0000:3a:00.0: // Setting command ring address to 0x8578fc001
[ 433.902649] pcieport 0000:00:1b.0: PME: Spurious native interrupt!
[ 433.902839] xhci_hcd 0000:3a:00.0: Port change event, 4-1, id 3, portsc: 0xb0202e2
[ 433.902842] xhci_hcd 0000:3a:00.0: resume root hub
[ 433.902845] xhci_hcd 0000:3a:00.0: handle_port_status: starting port polling.
[ 433.902877] xhci_hcd 0000:3a:00.0: xhci_resume: starting port polling.
[ 433.902889] xhci_hcd 0000:3a:00.0: xhci_hub_status_data: stopping port polling.
[ 433.902891] xhci_hcd 0000:3a:00.0: hcd_pci_runtime_resume: 0
[ 433.902919] usb usb4: usb wakeup-resume
[ 433.902942] usb usb4: usb auto-resume
[ 433.902966] hub 4-0:1.0: hub_resume
...
As Mathias pointed out, the hub enters Cold Attach Status state and
requires a warm reset. However usb_reset_device() bails out early when
the device is in suspended state, as its callers port_event() and
hub_event() don't always resume the device.
Since there's nothing wrong to reset a suspended device, allow
usb_reset_device() to do so to solve the issue.
Signed-off-by: Kai-Heng Feng <kai.heng.feng@canonical.com>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Cc: stable <stable@vger.kernel.org>
Link: https://lore.kernel.org/r/20191106062710.29880-1-kai.heng.feng@canonical.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
If a device connected to an xHCI host controller disconnects from the USB bus
and then reconnects, e.g. triggered by a firmware update, then the host
controller automatically activates the connection and the port is enabled. The
implementation of hub_port_connect_change() assumes that if the port is
enabled then nothing has changed. There is no check if the USB descriptors
have changed. As a result, the kernel's internal copy of the descriptors ends
up being incorrect and the device doesn't work properly anymore.
The solution to the problem is for hub_port_connect_change() always to
check whether the device's descriptors have changed before resuscitating
an enabled port.
Signed-off-by: David Heinzelmann <heinzelmann.david@gmail.com>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Link: https://lore.kernel.org/r/20191009044647.24536-1-heinzelmann.david@gmail.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
With Link Power Management (LPM) enabled USB3 links transition to low
power U1/U2 link states from U0 state automatically.
Current hub code detects USB3 remote wakeups by checking if the software
state still shows suspended, but the link has transitioned from suspended
U3 to enabled U0 state.
As it takes some time before the hub thread reads the port link state
after a USB3 wake notification, the link may have transitioned from U0
to U1/U2, and wake is not detected by hub code.
Fix this by handling U1/U2 states in the same way as U0 in USB3 wakeup
handling
This patch should be added to stable kernels since 4.13 where LPM was
kept enabled during suspend/resume
Cc: <stable@vger.kernel.org> # v4.13+
Signed-off-by: Lee, Chiasheng <chiasheng.lee@intel.com>
Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The Clear_TT_Buffer request sent to the hub includes the address of
the LS/FS child device in wValue field. usb_hub_clear_tt_buffer()
uses udev->devnum to set the address wValue. This won't work for
devices connected to xHC.
For other host controllers udev->devnum is the same as the address of
the usb device, chosen and set by usb core. With xHC the controller
hardware assigns the address, and won't be the same as devnum.
Here we add devaddr in "struct usb_device" for
usb_hub_clear_tt_buffer() to use.
Signed-off-by: Jim Lin <jilin@nvidia.com>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
If the device rejects the control transfer to enable device-initiated
U1/U2 entry, then the device will not initiate U1/U2 transition. To
improve the performance, the downstream port should not initate
transition to U1/U2 to avoid the delay from the device link command
response (no packet can be transmitted while waiting for a response from
the device). If the device has some quirks and does not implement U1/U2,
it may reject all the link state change requests, and the downstream
port may resend and flood the bus with more requests. This will affect
the device performance even further. This patch disables the
hub-initated U1/U2 if the device-initiated U1/U2 entry fails.
Reference: USB 3.2 spec 7.2.4.2.3
Signed-off-by: Thinh Nguyen <thinhn@synopsys.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
SET_FEATURE(U1/U2_ENABLE) and CLEAR_FEATURE(U1/U2) only apply while the
device is in configured state. Add proper check in usb_disable_lpm() and
usb_enable_lpm() for enabling/disabling device-initiated U1/U2.
Signed-off-by: Thinh Nguyen <thinhn@synopsys.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Felipe writes:
USB: changes for v5.2 merge window
With a total of 50 non-merge commits, this is not a large pull
request. Most of the changes are, again, in dwc2 (37%) and dwc3 (32%)
with the rest of it scattered among other UDCs, function drivers and
device-tree bindings.
No really big feature this time around apart from support to Amlogic
being added to both dwc3 and dwc2 drivers.
* tag 'usb-for-v5.2' of git://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb: (50 commits)
usb: dwc3: Rename DWC3_DCTL_LPM_ERRATA
usb: dwc3: Fix default lpm_nyet_threshold value
usb: dwc3: debug: Print GET_STATUS(device) tracepoint
usb: dwc3: Do core validation early on probe
usb: dwc3: gadget: Set lpm_capable
usb: gadget: atmel: tie wake lock to running clock
usb: gadget: atmel: support USB suspend
usb: gadget: atmel_usba_udc: simplify setting of interrupt-enabled mask
dwc2: gadget: Fix completed transfer size calculation in DDMA
usb: dwc2: Set lpm mode parameters depend on HW configuration
usb: dwc2: Fix channel disable flow
usb: dwc2: Set actual frame number for completed ISOC transfer
usb: gadget: do not use __constant_cpu_to_le16
usb: dwc2: gadget: Increase descriptors count for ISOC's
usb: introduce usb_ep_type_string() function
usb: dwc3: move synchronize_irq() out of the spinlock protected block
usb: dwc3: Free resource immediately after use
usb: dwc3: of-simple: Convert to bulk clk API
usb: dwc2: Delayed status support
usb: gadget: udc: lpc32xx: rework interrupt handling
...
