This reverts commit f078cc7762.
The upstream commit 991df39499 ("media: uvcvideo: Disable
autosuspend for Insta360 Link") has introduced a new quirk
"UVC_QUIRK_DISABLE_AUTOSUSPEND" for usb cameras to disable
autosuspend, so let's remove legacy autosuspend quirks.
Signed-off-by: William Wu <william.wu@rock-chips.com>
Change-Id: I572e5298fe3be62c570158cc018fd7ada59db7e1
This reverts commit f537dfe383.
The upstream commit 991df39499 ("media: uvcvideo: Disable
autosuspend for Insta360 Link") has introduced a new quirk
"UVC_QUIRK_DISABLE_AUTOSUSPEND" for usb cameras to disable
autosuspend, so let's remove legacy autosuspend quirks.
Signed-off-by: William Wu <william.wu@rock-chips.com>
Change-Id: Ibe4f168f8b2cb4b42b5a90aa2cb7e19cfad9cf7a
This reverts commit 3a4301edee.
The upstream commit 991df39499 ("media: uvcvideo: Disable
autosuspend for Insta360 Link") has introduced a new quirk
"UVC_QUIRK_DISABLE_AUTOSUSPEND" for usb cameras to disable
autosuspend, so let's remove legacy autosuspend quirks.
Signed-off-by: William Wu <william.wu@rock-chips.com>
Change-Id: I6d1db026f7e753ff9976f2ec2243cb604273251b
* commit '62646c7ab19511b8fc17078cf4b0603e550e73cd': (119202 commits)
clk: rockchip: Fix missing rkclk_cpuclk_div_setting prototype for rk3128
rtc: rk808: Explicitly include of.h for of_get_child_by_name
ASoC: rk817: Explicitly include gpio/consumer.h for devm_gpiod_get_optional
drm/rockchip: dsi2: add crtc post enable and pre disable callback
drm/rockchip: vop2: set dsc config done in crtc post enable
input: sensors: avoid -Wempty-body warning
input: sensors: accel: dmard10: Make gsensor_reset() static
ASoC: rk312x: Fix missing prototypes
arm64: dts: rockchip: rk3518: Add rockchip,video-1080p-freq for cpu opp table
soc: rockchip: system_monitor: Add support to limit cpu max freq when play 1080p video
net: phy: Convert to use sysfs_emit_at() API
drm/rockchip: dw_hdmi: Explicitly include pinctrl/consumer.h for devm_pinctrl_get
net: rfkill: bt: Explicitly include pinctrl/consumer.h for pinctrl_select_state
ASoC: codecs: rk_dsm: Explicitly include pinctrl/consumer.h for devm_pinctrl_get
spi: rockchip-slave: Explicitly include pinctrl/consumer.h for pinctrl_pm_select_sleep_state
media: rockchip: isp: Explicitly include platform_device.h
regulator: rk801: Explicitly include platform_device.h
soc: rockchip: decompress: Explicitly include of_platform.h for of_platform_device_create
soc: rockchip: thunderboot_mmc: Explicitly include of_platform.h for of_platform_device_create
soc: rockchip: thunderboot_sfc: Explicitly include of_platform.h for of_platform_device_create
...
Change-Id: I88628746fa5e58f85cf991634fe2f6355ac937e8
This is the 6.1.115 stable release
* tag 'v6.1.115': (2780 commits)
Linux 6.1.115
xfrm: validate new SA's prefixlen using SA family when sel.family is unset
arm64/uprobes: change the uprobe_opcode_t typedef to fix the sparse warning
ACPI: PRM: Clean up guid type in struct prm_handler_info
platform/x86: dell-wmi: Ignore suspend notifications
ASoC: qcom: Fix NULL Dereference in asoc_qcom_lpass_cpu_platform_probe()
net: phy: dp83822: Fix reset pin definitions
serial: protect uart_port_dtr_rts() in uart_shutdown() too
selinux: improve error checking in sel_write_load()
drm/amd/display: Disable PSR-SU on Parade 08-01 TCON too
hv_netvsc: Fix VF namespace also in synthetic NIC NETDEV_REGISTER event
xfrm: fix one more kernel-infoleak in algo dumping
LoongArch: Get correct cores_per_package for SMT systems
ALSA: hda/realtek: Add subwoofer quirk for Acer Predator G9-593
KVM: arm64: Don't eagerly teardown the vgic on init error
KVM: nSVM: Ignore nCR3[4:0] when loading PDPTEs from memory
openat2: explicitly return -E2BIG for (usize > PAGE_SIZE)
nilfs2: fix kernel bug due to missing clearing of buffer delay flag
ACPI: button: Add DMI quirk for Samsung Galaxy Book2 to fix initial lid detection issue
ACPI: PRM: Find EFI_MEMORY_RUNTIME block for PRM handler and context
...
Change-Id: Iee600c49a5c914b79141c62cda38e787e429a167
Conflicts:
arch/arm64/boot/dts/rockchip/rk356x.dtsi
drivers/gpio/gpio-rockchip.c
drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c
drivers/gpu/drm/rockchip/rockchip_drm_vop.c
drivers/gpu/drm/rockchip/rockchip_drm_vop.h
drivers/gpu/drm/rockchip/rockchip_drm_vop2.c
drivers/gpu/drm/rockchip/rockchip_vop_reg.c
drivers/media/i2c/imx335.c
drivers/pci/controller/dwc/pcie-dw-rockchip.c
drivers/spi/spi-rockchip.c
drivers/spi/spidev.c
drivers/usb/dwc3/gadget.c
drivers/usb/host/xhci.h
This is the 6.1.99 stable release
* tag 'v6.1.99': (1975 commits)
Linux 6.1.99
Revert "usb: xhci: prevent potential failure in handle_tx_event() for Transfer events without TRB"
Linux 6.1.98
nilfs2: fix incorrect inode allocation from reserved inodes
null_blk: Do not allow runt zone with zone capacity smaller then zone size
spi: cadence: Ensure data lines set to low during dummy-cycle period
nfc/nci: Add the inconsistency check between the input data length and count
kbuild: fix short log for AS in link-vmlinux.sh
nvmet: fix a possible leak when destroy a ctrl during qp establishment
platform/x86: touchscreen_dmi: Add info for the EZpad 6s Pro
platform/x86: touchscreen_dmi: Add info for GlobalSpace SolT IVW 11.6" tablet
regmap-i2c: Subtract reg size from max_write
nvme: adjust multiples of NVME_CTRL_PAGE_SIZE in offset
dma-mapping: benchmark: avoid needless copy_to_user if benchmark fails
nvme-multipath: find NUMA path only for online numa-node
ALSA: hda/realtek: Enable headset mic of JP-IK LEAP W502 with ALC897
fs/ntfs3: Mark volume as dirty if xattr is broken
i2c: pnx: Fix potential deadlock warning from del_timer_sync() call in isr
clk: mediatek: mt8183: Only enable runtime PM on mt8183-mfgcfg
clk: mediatek: clk-mtk: Register MFG notifier in mtk_clk_simple_probe()
...
Change-Id: Ibf9c2caa3bbffb7a960e82ec6c2b0b497753778c
Conflicts:
arch/arm64/boot/dts/rockchip/rk3328.dtsi
drivers/gpu/drm/rockchip/rockchip_drm_vop2.c
drivers/phy/rockchip/phy-rockchip-snps-pcie3.c
drivers/pinctrl/pinctrl-rockchip.c
drivers/usb/gadget/function/u_audio.c
include/linux/usb/quirks.h
mm/cma.c
sound/soc/rockchip/rockchip_i2s_tdm.c
[ Upstream commit 5a1ccf0c72cf917ff3ccc131d1bb8d19338ffe52 ]
This patch introduces a new USB quirk,
USB_QUIRK_SHORT_SET_ADDRESS_REQ_TIMEOUT, which modifies the timeout value
for the SET_ADDRESS request. The standard timeout for USB request/command
is 5000 ms, as recommended in the USB 3.2 specification (section 9.2.6.1).
However, certain scenarios, such as connecting devices through an APTIV
hub, can lead to timeout errors when the device enumerates as full speed
initially and later switches to high speed during chirp negotiation.
In such cases, USB analyzer logs reveal that the bus suspends for
5 seconds due to incorrect chirp parsing and resumes only after two
consecutive timeout errors trigger a hub driver reset.
Packet(54) Dir(?) Full Speed J(997.100 us) Idle( 2.850 us)
_______| Time Stamp(28 . 105 910 682)
_______|_____________________________________________________________Ch0
Packet(55) Dir(?) Full Speed J(997.118 us) Idle( 2.850 us)
_______| Time Stamp(28 . 106 910 632)
_______|_____________________________________________________________Ch0
Packet(56) Dir(?) Full Speed J(399.650 us) Idle(222.582 us)
_______| Time Stamp(28 . 107 910 600)
_______|_____________________________________________________________Ch0
Packet(57) Dir Chirp J( 23.955 ms) Idle(115.169 ms)
_______| Time Stamp(28 . 108 532 832)
_______|_____________________________________________________________Ch0
Packet(58) Dir(?) Full Speed J (Suspend)( 5.347 sec) Idle( 5.366 us)
_______| Time Stamp(28 . 247 657 600)
_______|_____________________________________________________________Ch0
This 5-second delay in device enumeration is undesirable, particularly
in automotive applications where quick enumeration is crucial
(ideally within 3 seconds).
The newly introduced quirks provide the flexibility to align with a
3-second time limit, as required in specific contexts like automotive
applications.
By reducing the SET_ADDRESS request timeout to 500 ms, the
system can respond more swiftly to errors, initiate rapid recovery, and
ensure efficient device enumeration. This change is vital for scenarios
where rapid smartphone enumeration and screen projection are essential.
To use the quirk, please write "vendor_id:product_id:p" to
/sys/bus/usb/drivers/hub/module/parameter/quirks
For example,
echo "0x2c48:0x0132:p" > /sys/bus/usb/drivers/hub/module/parameters/quirks"
Signed-off-by: Hardik Gajjar <hgajjar@de.adit-jv.com>
Reviewed-by: Alan Stern <stern@rowland.harvard.edu>
Link: https://lore.kernel.org/r/20231027152029.104363-2-hgajjar@de.adit-jv.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
This patch adds USB_QUIRK_RESET for Alcor Micro
Flash Drive (idVendor=058f, idProduct=6387) to
fix read/write issue after system resume from
deep sleep.
Change-Id: I35e0d511a80255a18eb842412ff9905c039df9bf
Signed-off-by: William Wu <william.wu@rock-chips.com>
This is the 6.1.43 stable release
* tag 'v6.1.43': (3386 commits)
Linux 6.1.43
dma-buf: fix an error pointer vs NULL bug
dma-buf: keep the signaling time of merged fences v3
test_firmware: return ENOMEM instead of ENOSPC on failed memory allocation
selftests: mptcp: sockopt: use 'iptables-legacy' if available
mptcp: ensure subflow is unhashed before cleaning the backlog
cpufreq: intel_pstate: Drop ACPI _PSS states table patching
ACPI: processor: perflib: Avoid updating frequency QoS unnecessarily
ACPI: processor: perflib: Use the "no limit" frequency QoS
drm/amd/display: Write to correct dirty_rect
drm/amd/display: perform a bounds check before filling dirty rectangles
tracing: Fix trace_event_raw_event_synth() if else statement
drm/amd/display: set per pipe dppclk to 0 when dpp is off
rbd: retrieve and check lock owner twice before blocklisting
rbd: harden get_lock_owner_info() a bit
rbd: make get_lock_owner_info() return a single locker or NULL
dm cache policy smq: ensure IO doesn't prevent cleaner policy progress
drm/i915/dpt: Use shmem for dpt objects
ceph: never send metrics if disable_send_metrics is set
PM: sleep: wakeirq: fix wake irq arming
...
Conflicts:
arch/arm/boot/dts/rk3288.dtsi
arch/arm64/boot/dts/rockchip/rk3568.dtsi
arch/arm64/boot/dts/rockchip/rk356x.dtsi
drivers/dma/pl330.c
drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
drivers/gpu/drm/rockchip/rockchip_drm_vop.c
drivers/gpu/drm/rockchip/rockchip_drm_vop2.c
drivers/mmc/core/card.h
drivers/net/ethernet/stmicro/stmmac/dwmac-rk.c
drivers/nvme/host/nvme.h
drivers/pci/controller/pcie-rockchip.c
drivers/power/supply/rk817_charger.c
drivers/tty/serial/8250/8250_port.c
drivers/usb/dwc3/gadget.c
drivers/usb/gadget/udc/core.c
drivers/usb/host/xhci.h
drivers/usb/typec/tcpm/tcpm.c
Revert commit c649bf43a2 ("net: ethernet: stmmac: dwmac-rk: rework optional clock handling").
Change-Id: Ib0117e96e04e9a15543ebb69c1a873ba44e41546
commit 9dc162e223 upstream.
The Focusrite Scarlett audio device does not behave correctly during
resumes. Below is what happens during every resume (captured with
Beagle 5000):
<Suspend>
<Resume>
<Reset>/<Chirp J>/<Tiny J>
<Reset/Target disconnected>
<High Speed>
The Scarlett disconnects and is enumerated again.
However from time to time it drops completely off the USB bus during
resume. Below is captured occurrence of such an event:
<Suspend>
<Resume>
<Reset>/<Chirp J>/<Tiny J>
<Reset>/<Chirp K>/<Tiny K>
<High Speed>
<Corrupted packet>
<Reset/Target disconnected>
To fix the condition a user has to unplug and plug the device again.
With USB_QUIRK_RESET_RESUME applied ("usbcore.quirks=1235:8211:b")
for the Scarlett audio device the issue still reproduces.
Applying USB_QUIRK_DISCONNECT_SUSPEND ("usbcore.quirks=1235:8211:m")
fixed the issue and the Scarlett audio device didn't drop off the USB
bus for ~5000 suspend/resume cycles where originally issue reproduced in
~100 or less suspend/resume cycles.
Signed-off-by: Łukasz Bartosik <lb@semihalf.com>
Cc: stable <stable@kernel.org>
Link: https://lore.kernel.org/r/20230724112911.1802577-1-lb@semihalf.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The Focusrite Scarlett audio device does not behave correctly during
resumes. Below is what happens during every resume (captured with
Beagle 5000):
<Suspend>
<Resume>
<Reset>/<Chirp J>/<Tiny J>
<Reset/Target disconnected>
<High Speed>
The Scarlett disconnects and is enumerated again.
However from time to time it drops completely off the USB bus during
resume. Below is captured occurrence of such an event:
<Suspend>
<Resume>
<Reset>/<Chirp J>/<Tiny J>
<Reset>/<Chirp K>/<Tiny K>
<High Speed>
<Corrupted packet>
<Reset/Target disconnected>
To fix the condition a user has to unplug and plug the device again.
With USB_QUIRK_RESET_RESUME applied ("usbcore.quirks=1235:8211:b")
for the Scarlett audio device the issue still reproduces.
Applying USB_QUIRK_DISCONNECT_SUSPEND ("usbcore.quirks=1235:8211:m")
fixed the issue and the Scarlett audio device didn't drop off the USB
bus for ~5000 suspend/resume cycles where originally issue reproduced in
~100 or less suspend/resume cycles.
Signed-off-by: Łukasz Bartosik <lb@semihalf.com>
Cc: stable <stable@kernel.org>
Link: https://lore.kernel.org/r/20230724112911.1802577-1-lb@semihalf.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 37d49519b4 upstream.
The Lenovo OneLink+ Dock contains two VL812 USB3.0 controllers:
17ef:1018 upstream
17ef:1019 downstream
These hubs suffer from two separate problems:
1) After the host system was suspended and woken up, the hubs appear to
be in a random state. Some downstream ports (both internal to the
built-in audio and network controllers, and external to USB sockets)
may no longer be functional. The exact list of disabled ports (if
any) changes from wakeup to wakeup. Ports remain in that state until
the dock is power-cycled, or until the laptop is rebooted.
Wakeup sources connected to the hubs (keyboard, WoL on the integrated
gigabit controller) will wake the system up from suspend, but they
may no longer work after wakeup (and in that case will no longer work
as wakeup source in a subsequent suspend-wakeup cycle).
This issue appears in the logs with messages such as:
usb 1-6.1-port4: cannot disable (err = -71)
usb 1-6-port2: cannot disable (err = -71)
usb 1-6.1: clear tt 1 (80c0) error -71
usb 1-6-port4: cannot disable (err = -71)
usb 1-6.4: PM: dpm_run_callback(): usb_dev_resume+0x0/0x10 [usbcore] returns -71
usb 1-6.4: PM: failed to resume async: error -71
usb 1-7: reset full-speed USB device number 5 using xhci_hcd
usb 1-6.1-port1: cannot reset (err = -71)
usb 1-6.1-port1: cannot reset (err = -71)
usb 1-6.1-port1: cannot reset (err = -71)
usb 1-6.1-port1: cannot reset (err = -71)
usb 1-6.1-port1: cannot reset (err = -71)
usb 1-6.1-port1: Cannot enable. Maybe the USB cable is bad?
usb 1-6.1-port1: cannot disable (err = -71)
usb 1-6.1-port1: cannot reset (err = -71)
usb 1-6.1-port1: cannot reset (err = -71)
usb 1-6.1-port1: cannot reset (err = -71)
usb 1-6.1-port1: cannot reset (err = -71)
usb 1-6.1-port1: cannot reset (err = -71)
usb 1-6.1-port1: Cannot enable. Maybe the USB cable is bad?
usb 1-6.1-port1: cannot disable (err = -71)
2) Some USB devices cannot be enumerated properly. So far I have only
seen the issue with USB 3.0 devices. The same devices work without
problem directly connected to the host system, to other systems or to
other hubs (even when those hubs are connected to the OneLink+ dock).
One very reliable reproducer is this USB 3.0 HDD enclosure:
152d:9561 JMicron Technology Corp. / JMicron USA Technology Corp. Mobius
I have seen it happen sporadically with other USB 3.0 enclosures,
with controllers from different manufacturers, all self-powered.
Typical messages in the logs:
xhci_hcd 0000:00:14.0: Timeout while waiting for setup device command
xhci_hcd 0000:00:14.0: Timeout while waiting for setup device command
usb 2-1.4: device not accepting address 6, error -62
xhci_hcd 0000:00:14.0: Timeout while waiting for setup device command
xhci_hcd 0000:00:14.0: Timeout while waiting for setup device command
usb 2-1.4: device not accepting address 7, error -62
usb 2-1-port4: attempt power cycle
xhci_hcd 0000:00:14.0: Timeout while waiting for setup device command
xhci_hcd 0000:00:14.0: Timeout while waiting for setup device command
usb 2-1.4: device not accepting address 8, error -62
xhci_hcd 0000:00:14.0: Timeout while waiting for setup device command
xhci_hcd 0000:00:14.0: Timeout while waiting for setup device command
usb 2-1.4: device not accepting address 9, error -62
usb 2-1-port4: unable to enumerate USB device
Through trial and error, I found that the USB_QUIRK_RESET_RESUME solved
the second issue. Further testing then uncovered the first issue. Test
results are summarized in this table:
=======================================================================================
Settings USB2 hotplug USB3 hotplug State after waking up
---------------------------------------------------------------------------------------
power/control=auto works fails broken
usbcore.autosuspend=-1 works works broken
OR power/control=on
power/control=auto works (1) works (1) works
and USB_QUIRK_RESET_RESUME
power/control=on works works works
and USB_QUIRK_RESET_RESUME
HUB_QUIRK_DISABLE_AUTOSUSPEND works works works
and USB_QUIRK_RESET_RESUME
=======================================================================================
In those results, the power/control settings are applied to both hubs,
both on the USB2 and USB3 side, before each test.
From those results, USB_QUIRK_RESET_RESUME is required to reset the hubs
properly after a suspend-wakeup cycle, and the hubs must not autosuspend
to work around the USB3 issue.
A secondary effect of USB_QUIRK_RESET_RESUME is to prevent the hubs'
upstream links from suspending (the downstream ports can still suspend).
This secondary effect is used in results (1). It is enough to solve the
USB3 problem.
Setting USB_QUIRK_RESET_RESUME on those hubs is the smallest patch that
solves both issues.
Prior to creating this patch, I have used the USB_QUIRK_RESET_RESUME via
the kernel command line for over a year without noticing any side
effect.
Thanks to Oliver Neukum @Suse for explanations of the operations of
USB_QUIRK_RESET_RESUME, and requesting more testing.
Signed-off-by: Jean-Francois Le Fillatre <jflf_kernel@gmx.com>
Cc: stable <stable@kernel.org>
Link: https://lore.kernel.org/r/20220927073407.5672-1-jflf_kernel@gmx.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The Lenovo OneLink+ Dock contains two VL812 USB3.0 controllers:
17ef:1018 upstream
17ef:1019 downstream
These hubs suffer from two separate problems:
1) After the host system was suspended and woken up, the hubs appear to
be in a random state. Some downstream ports (both internal to the
built-in audio and network controllers, and external to USB sockets)
may no longer be functional. The exact list of disabled ports (if
any) changes from wakeup to wakeup. Ports remain in that state until
the dock is power-cycled, or until the laptop is rebooted.
Wakeup sources connected to the hubs (keyboard, WoL on the integrated
gigabit controller) will wake the system up from suspend, but they
may no longer work after wakeup (and in that case will no longer work
as wakeup source in a subsequent suspend-wakeup cycle).
This issue appears in the logs with messages such as:
usb 1-6.1-port4: cannot disable (err = -71)
usb 1-6-port2: cannot disable (err = -71)
usb 1-6.1: clear tt 1 (80c0) error -71
usb 1-6-port4: cannot disable (err = -71)
usb 1-6.4: PM: dpm_run_callback(): usb_dev_resume+0x0/0x10 [usbcore] returns -71
usb 1-6.4: PM: failed to resume async: error -71
usb 1-7: reset full-speed USB device number 5 using xhci_hcd
usb 1-6.1-port1: cannot reset (err = -71)
usb 1-6.1-port1: cannot reset (err = -71)
usb 1-6.1-port1: cannot reset (err = -71)
usb 1-6.1-port1: cannot reset (err = -71)
usb 1-6.1-port1: cannot reset (err = -71)
usb 1-6.1-port1: Cannot enable. Maybe the USB cable is bad?
usb 1-6.1-port1: cannot disable (err = -71)
usb 1-6.1-port1: cannot reset (err = -71)
usb 1-6.1-port1: cannot reset (err = -71)
usb 1-6.1-port1: cannot reset (err = -71)
usb 1-6.1-port1: cannot reset (err = -71)
usb 1-6.1-port1: cannot reset (err = -71)
usb 1-6.1-port1: Cannot enable. Maybe the USB cable is bad?
usb 1-6.1-port1: cannot disable (err = -71)
2) Some USB devices cannot be enumerated properly. So far I have only
seen the issue with USB 3.0 devices. The same devices work without
problem directly connected to the host system, to other systems or to
other hubs (even when those hubs are connected to the OneLink+ dock).
One very reliable reproducer is this USB 3.0 HDD enclosure:
152d:9561 JMicron Technology Corp. / JMicron USA Technology Corp. Mobius
I have seen it happen sporadically with other USB 3.0 enclosures,
with controllers from different manufacturers, all self-powered.
Typical messages in the logs:
xhci_hcd 0000:00:14.0: Timeout while waiting for setup device command
xhci_hcd 0000:00:14.0: Timeout while waiting for setup device command
usb 2-1.4: device not accepting address 6, error -62
xhci_hcd 0000:00:14.0: Timeout while waiting for setup device command
xhci_hcd 0000:00:14.0: Timeout while waiting for setup device command
usb 2-1.4: device not accepting address 7, error -62
usb 2-1-port4: attempt power cycle
xhci_hcd 0000:00:14.0: Timeout while waiting for setup device command
xhci_hcd 0000:00:14.0: Timeout while waiting for setup device command
usb 2-1.4: device not accepting address 8, error -62
xhci_hcd 0000:00:14.0: Timeout while waiting for setup device command
xhci_hcd 0000:00:14.0: Timeout while waiting for setup device command
usb 2-1.4: device not accepting address 9, error -62
usb 2-1-port4: unable to enumerate USB device
Through trial and error, I found that the USB_QUIRK_RESET_RESUME solved
the second issue. Further testing then uncovered the first issue. Test
results are summarized in this table:
=======================================================================================
Settings USB2 hotplug USB3 hotplug State after waking up
---------------------------------------------------------------------------------------
power/control=auto works fails broken
usbcore.autosuspend=-1 works works broken
OR power/control=on
power/control=auto works (1) works (1) works
and USB_QUIRK_RESET_RESUME
power/control=on works works works
and USB_QUIRK_RESET_RESUME
HUB_QUIRK_DISABLE_AUTOSUSPEND works works works
and USB_QUIRK_RESET_RESUME
=======================================================================================
In those results, the power/control settings are applied to both hubs,
both on the USB2 and USB3 side, before each test.
From those results, USB_QUIRK_RESET_RESUME is required to reset the hubs
properly after a suspend-wakeup cycle, and the hubs must not autosuspend
to work around the USB3 issue.
A secondary effect of USB_QUIRK_RESET_RESUME is to prevent the hubs'
upstream links from suspending (the downstream ports can still suspend).
This secondary effect is used in results (1). It is enough to solve the
USB3 problem.
Setting USB_QUIRK_RESET_RESUME on those hubs is the smallest patch that
solves both issues.
Prior to creating this patch, I have used the USB_QUIRK_RESET_RESUME via
the kernel command line for over a year without noticing any side
effect.
Thanks to Oliver Neukum @Suse for explanations of the operations of
USB_QUIRK_RESET_RESUME, and requesting more testing.
Signed-off-by: Jean-Francois Le Fillatre <jflf_kernel@gmx.com>
Cc: stable <stable@kernel.org>
Link: https://lore.kernel.org/r/20220927073407.5672-1-jflf_kernel@gmx.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
[ Upstream commit 3d5f70949f ]
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>
Signed-off-by: Sasha Levin <sashal@kernel.org>
The Sonix webcam (idVendor=0x0c45,idProduct=0x636a)
can't support auto-suspend well on rockchip platforms.
With auto-suspend, the usb mic of the webcam fail to
start capture. So we need to disable auto-suspend for
this Sonix webcam.
Signed-off-by: William Wu <william.wu@rock-chips.com>
Change-Id: Icc59c4fe1fda78be73441dc4320d6d738d031efd
https://source.android.com/security/bulletin/2022-04-01
CVE-2021-0707
CVE-2021-39800
CVE-2021-39801 (4.9 only)
CVE-2021-39802
* tag 'ASB-2022-04-05_12-5.10': (3832 commits)
ANDROID: GKI: Update symbols to abi_gki_aarch64_oplus
ANDROID: vendor_hooks: Reduce pointless modversions CRC churn
UPSTREAM: locking/lockdep: Avoid potential access of invalid memory in lock_class
ANDROID: mm: Fix implicit declaration of function 'isolate_lru_page'
ANDROID: GKI: Update symbols to symbol list
ANDROID: GKI: Update symbols to symbol list
ANDROID: GKI: Add hook symbol to symbol list
Revert "ANDROID: dm-bow: Protect Ranges fetched and erased from the RB tree"
ANDROID: vendor_hooks: Add hooks to for free_unref_page_commit
ANDROID: vendor_hooks: Add hooks to for alloc_contig_range
ANDROID: GKI: Update symbols to symbol list
ANDROID: vendor_hooks: Add hook in shrink_node_memcgs
ANDROID: GKI: Add symbols to symbol list
FROMGIT: iommu/iova: Improve 32-bit free space estimate
ANDROID: export walk_page_range and swp_swap_info
ANDROID: vendor_hooks: export shrink_slab
ANDROID: usb: gadget: f_accessory: add compat_ioctl support
UPSTREAM: sr9700: sanity check for packet length
UPSTREAM: io_uring: return back safer resurrect
UPSTREAM: Revert "xfrm: state and policy should fail if XFRMA_IF_ID 0"
...
Change-Id: Ic61ead530b99b10ffd535a358a48fe9bb8c33fd4
Conflicts:
drivers/android/Kconfig
drivers/gpu/drm/rockchip/dw-mipi-dsi-rockchip.c
drivers/gpu/drm/rockchip/rockchip_vop_reg.c
drivers/i2c/busses/i2c-rk3x.c
drivers/media/i2c/imx258.c
drivers/net/ethernet/stmicro/stmmac/dwmac-rk.c
drivers/usb/dwc2/gadget.c
drivers/usb/gadget/function/uvc.h
lib/Kconfig.debug
LPM on the device appears to cause xHCI host controllers
to reset the usb device when run at USB 2.0 high speed,
then the device will enter suspend and unable to exit.
Change-Id: I185cfe2c01f6de20463b041bdf4dac54978f1ada
Signed-off-by: William Wu <william.wu@rock-chips.com>
https://source.android.com/security/bulletin/2021-12-01
CVE-2021-33909
CVE-2021-38204
CVE-2021-0961
* tag 'ASB-2021-12-05_12-5.10': (3010 commits)
ANDROID: workqueue: export symbol of the function wq_worker_comm()
ANDROID: GKI: Update symbols to symbol list
ANDROID: vendor_hooks: Add hooks for binder proc transaction
ANDROID: GKI: Add symbols abi for USB IP kernel modules.
ANDROID: GKI: Fix file mode on mtk abi file
UPSTREAM: erofs: fix deadlock when shrink erofs slab
ANDROID: init_task: Init android vendor and oem data
UPSTREAM: sched/core: Mitigate race cpus_share_cache()/update_top_cache_domain()
ANDROID: Update symbol list for mtk
UPSTREAM: erofs: fix unsafe pagevec reuse of hooked pclusters
UPSTREAM: erofs: remove the occupied parameter from z_erofs_pagevec_enqueue()
UPSTREAM: usb: dwc3: gadget: Fix null pointer exception
ANDROID: fips140: support "evaluation testing" builds via build.sh
FROMGIT: sched/scs: Reset task stack state in bringup_cpu()
ANDROID: dma-buf: heaps: fix dma-buf heap pool pages stat
ANDROID: ABI: Add several spi_mem related symbols
UPSTREAM: spi: spi-mem: add spi_mem_dtr_supports_op()
ANDROID: gki_defconfig: enable CONFIG_SPI_MEM
ANDROID: ABI: Add several iio related symbols
ANDROID: ABI: Update symbol list for IMX
...
Change-Id: I09cddc92fa34553b944e62cc5cbbba94a84e5437
Conflicts:
arch/arm/boot/dts/rk322x.dtsi
arch/arm64/boot/dts/rockchip/rk3399.dtsi
drivers/dma-buf/heaps/system_heap.c
drivers/gpu/drm/rockchip/dw-mipi-dsi-rockchip.c
drivers/gpu/drm/rockchip/rockchip_drm_vop.c
drivers/gpu/drm/rockchip/rockchip_lvds.c
drivers/gpu/drm/rockchip/rockchip_vop_reg.c
drivers/mtd/nand/spi/core.c
drivers/pci/controller/pcie-rockchip-host.c
drivers/soc/rockchip/Kconfig
drivers/usb/dwc3/core.c
drivers/usb/dwc3/core.h
This is another branded 8153 device that doesn't work well with LPM:
r8152 2-2.1:1.0 enp0s13f0u2u1: Stop submitting intr, status -71
Disable LPM to resolve the issue.
Signed-off-by: Ole Ernst <olebowle@gmx.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
[ Upstream commit f3a1a937f7 ]
This reverts commit 0bd860493f.
While the patch was working as stated,ie preventing the L850-GL LTE modem
from crashing on some U3 wake-ups due to a race condition between the
host wake-up and the modem-side wake-up, when using the MBIM interface,
this would force disabling the USB runtime PM on the device.
The increased power consumption is significant for LTE laptops,
and given that with decently recent modem firmwares, when the modem hits
the bug, it automatically recovers (ie it drops from the bus, but
automatically re-enumerates after less than half a second, rather than being
stuck until a power cycle as it was doing with ancient firmware), for
most people, the trade-off now seems in favor of re-enabling it by
default.
For people with access to the platform code, the bug can also be worked-around
successfully by changing the USB3 LFPM polling off-time for the XHCI
controller in the BIOS code.
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
Link: https://lore.kernel.org/r/20210721092516.2775971-1-vpalatin@chromium.org
Fixes: 0bd860493f ("USB: quirks: ignore remote wake-up on Fibocom L850-GL LTE modem")
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
This reverts commit 0bd860493f.
While the patch was working as stated,ie preventing the L850-GL LTE modem
from crashing on some U3 wake-ups due to a race condition between the
host wake-up and the modem-side wake-up, when using the MBIM interface,
this would force disabling the USB runtime PM on the device.
The increased power consumption is significant for LTE laptops,
and given that with decently recent modem firmwares, when the modem hits
the bug, it automatically recovers (ie it drops from the bus, but
automatically re-enumerates after less than half a second, rather than being
stuck until a power cycle as it was doing with ancient firmware), for
most people, the trade-off now seems in favor of re-enabling it by
default.
For people with access to the platform code, the bug can also be worked-around
successfully by changing the USB3 LFPM polling off-time for the XHCI
controller in the BIOS code.
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
Link: https://lore.kernel.org/r/20210721092516.2775971-1-vpalatin@chromium.org
Fixes: 0bd860493f ("USB: quirks: ignore remote wake-up on Fibocom L850-GL LTE modem")
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* android12-5.10: (2274 commits)
FROMGIT: mm: slub: move sysfs slab alloc/free interfaces to debugfs
ANDROID: gki - CONFIG_NET_SCH_FQ=y
ANDROID: GKI: Kconfig.gki: Add GKI_HIDDEN_ETHERNET_CONFIGS
FROMLIST: media: Kconfig: Fix DVB_CORE can't be selected as module
ANDROID: Update ABI and symbol list
Revert "net: usb: cdc_ncm: don't spew notifications"
ANDROID: Fips 140: move fips symbols entirely in own list
ANDROID: core of xt_IDLETIMER send_nl_msg support
ANDROID: start to re-add xt_IDLETIMER send_nl_msg support
ANDROID: add fips140.ko symbols to module ABI
ANDROID: inject correct HMAC digest into fips140.ko at build time
ANDROID: crypto: fips140 - perform load time integrity check
FROMLIST: crypto: shash - stop comparing function pointers to avoid breaking CFI
ANDROID: arm64: module: preserve RELA sections for FIPS140 integrity selfcheck
ANDROID: arm64: simd: omit capability check in may_use_simd()
ANDROID: kbuild: lto: permit the use of .a archives in LTO modules
ANDROID: arm64: only permit certain alternatives in the FIPS140 module
ANDROID: crypto: lib/aes - add vendor hooks for AES library routines
ANDROID: crypto: lib/sha256 - add vendor hook for sha256() routine
UPSTREAM: KVM: arm64: Mark the host stage-2 memory pools static
...
Conflicts:
drivers/mmc/core/mmc_ops.c
drivers/usb/gadget/function/f_uac1.c
drivers/usb/gadget/function/f_uac2.c
drivers/usb/gadget/function/f_uvc.c
We found that some Sonix usb cameras(e.g. idVendor=0c45,
idProduct=64ab or idProduct=64ac) can't support auto-suspend
well on rockchip platforms(e.g. rk3399).With auto-suspend,
these usb cameras MJPEG will display abnormally on all usb
controllers(DWC2/DWC3/EHCI). So we need to disable auto-
suspend for these special usb cameras.
Change-Id: I08c87cf5c9fa5ebe076b5dd3e873b74c5ec2cb83
Signed-off-by: William Wu <william.wu@rock-chips.com>
Signed-off-by: Frank Wang <frank.wang@rock-chips.com>
The commit 62b2a34a21 ("uvcvideo: add quirk for devices
with broken auto suspend") introduced quirk to workaround
an issue with some HD Cameras.
There is one more model that has the same issue - idProduct
=0x9320, so applying the same quirk as well.
Change-Id: I24e3fc1746a9d21d529bc91f52fd5822e998bd93
Signed-off-by: William Wu <william.wu@rock-chips.com>
Signed-off-by: Frank Wang <frank.wang@rock-chips.com>
We found that some usb cameras(e.g. Manufacturer: HD Camera
Manufacturer, idVendor=05a3, idProduct=9230) can't support
auto-suspend well on rockchip platforms. With auto-suspend,
these usb cameras MJPEG will display abnormally on all usb
controllers(DWC2/DWC3/EHCI). So we need to disable auto
suspend for these special usb cameras.
Change-Id: Ibf50ed77edff0012a112dc42f09e022055908829
Signed-off-by: Wu Liang feng <wulf@rock-chips.com>
Signed-off-by: Frank Wang <frank.wang@rock-chips.com>
commit ca91fd8c76 upstream.
Realtek Hub (0bda:5487) in Dell Dock WD19 sometimes fails to work
after the system resumes from suspend with remote wakeup enabled
device connected:
[ 1947.640907] hub 5-2.3:1.0: hub_ext_port_status failed (err = -71)
[ 1947.641208] usb 5-2.3-port5: cannot disable (err = -71)
[ 1947.641401] hub 5-2.3:1.0: hub_ext_port_status failed (err = -71)
[ 1947.641450] usb 5-2.3-port4: cannot reset (err = -71)
Information of this hub:
T: Bus=01 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#= 10 Spd=480 MxCh= 5
D: Ver= 2.10 Cls=09(hub ) Sub=00 Prot=02 MxPS=64 #Cfgs= 1
P: Vendor=0bda ProdID=5487 Rev= 1.47
S: Manufacturer=Dell Inc.
S: Product=Dell dock
C:* #Ifs= 1 Cfg#= 1 Atr=e0 MxPwr= 0mA
I: If#= 0 Alt= 0 #EPs= 1 Cls=09(hub ) Sub=00 Prot=01 Driver=hub
E: Ad=81(I) Atr=03(Int.) MxPS= 1 Ivl=256ms
I:* If#= 0 Alt= 1 #EPs= 1 Cls=09(hub ) Sub=00 Prot=02 Driver=hub
E: Ad=81(I) Atr=03(Int.) MxPS= 1 Ivl=256ms
The failure results from the ETIMEDOUT by chance when turning on
the suspend feature for the specified port of the hub. The port
seems to be in an unknown state so the hub_activate during resume
fails the hub_port_status, then the hub will fail to work.
The quirky hub needs the reset-resume quirk to function correctly.
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Chris Chiu <chris.chiu@canonical.com>
Cc: stable <stable@vger.kernel.org>
Link: https://lore.kernel.org/r/20210420174651.6202-1-chris.chiu@canonical.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Realtek Hub (0bda:5487) in Dell Dock WD19 sometimes fails to work
after the system resumes from suspend with remote wakeup enabled
device connected:
[ 1947.640907] hub 5-2.3:1.0: hub_ext_port_status failed (err = -71)
[ 1947.641208] usb 5-2.3-port5: cannot disable (err = -71)
[ 1947.641401] hub 5-2.3:1.0: hub_ext_port_status failed (err = -71)
[ 1947.641450] usb 5-2.3-port4: cannot reset (err = -71)
Information of this hub:
T: Bus=01 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#= 10 Spd=480 MxCh= 5
D: Ver= 2.10 Cls=09(hub ) Sub=00 Prot=02 MxPS=64 #Cfgs= 1
P: Vendor=0bda ProdID=5487 Rev= 1.47
S: Manufacturer=Dell Inc.
S: Product=Dell dock
C:* #Ifs= 1 Cfg#= 1 Atr=e0 MxPwr= 0mA
I: If#= 0 Alt= 0 #EPs= 1 Cls=09(hub ) Sub=00 Prot=01 Driver=hub
E: Ad=81(I) Atr=03(Int.) MxPS= 1 Ivl=256ms
I:* If#= 0 Alt= 1 #EPs= 1 Cls=09(hub ) Sub=00 Prot=02 Driver=hub
E: Ad=81(I) Atr=03(Int.) MxPS= 1 Ivl=256ms
The failure results from the ETIMEDOUT by chance when turning on
the suspend feature for the specified port of the hub. The port
seems to be in an unknown state so the hub_activate during resume
fails the hub_port_status, then the hub will fail to work.
The quirky hub needs the reset-resume quirk to function correctly.
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Chris Chiu <chris.chiu@canonical.com>
Cc: stable <stable@vger.kernel.org>
Link: https://lore.kernel.org/r/20210420174651.6202-1-chris.chiu@canonical.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 0bd860493f upstream.
This LTE modem (M.2 card) has a bug in its power management:
there is some kind of race condition for U3 wake-up between the host and
the device. The modem firmware sometimes crashes/locks when both events
happen at the same time and the modem fully drops off the USB bus (and
sometimes re-enumerates, sometimes just gets stuck until the next
reboot).
Tested with the modem wired to the XHCI controller on an AMD 3015Ce
platform. Without the patch, the modem dropped of the USB bus 5 times in
3 days. With the quirk, it stayed connected for a week while the
'runtime_suspended_time' counter incremented as excepted.
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
Link: https://lore.kernel.org/r/20210319124802.2315195-1-vpalatin@chromium.org
Cc: stable <stable@vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
