#
20836c95 |
| 02-Jul-2024 |
WangYuli <wangyuli@uniontech.com> |
USB: Add USB_QUIRK_NO_SET_INTF quirk for START BP-850k
commit 3859e85de30815a20bce7db712ce3d94d40a682d upstream.
START BP-850K is a dot matrix printer that crashes when it receives a Set-Interface
USB: Add USB_QUIRK_NO_SET_INTF quirk for START BP-850k
commit 3859e85de30815a20bce7db712ce3d94d40a682d upstream.
START BP-850K is a dot matrix printer that crashes when it receives a Set-Interface request and needs USB_QUIRK_NO_SET_INTF to work properly.
Cc: stable <stable@kernel.org> Signed-off-by: jinxiaobo <jinxiaobo@uniontech.com> Signed-off-by: WangYuli <wangyuli@uniontech.com> Link: https://lore.kernel.org/r/202E4B2BD0F0FEA4+20240702154408.631201-1-wangyuli@uniontech.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
show more ...
|
#
3adcbec4 |
| 27-Oct-2023 |
Hardik Gajjar <hgajjar@de.adit-jv.com> |
usb: new quirk to reduce the SET_ADDRESS request timeout
[ Upstream commit 5a1ccf0c72cf917ff3ccc131d1bb8d19338ffe52 ]
This patch introduces a new USB quirk, USB_QUIRK_SHORT_SET_ADDRESS_REQ_TIMEOUT,
usb: new quirk to reduce the SET_ADDRESS request timeout
[ 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>
show more ...
|
#
9dc162e2 |
| 24-Jul-2023 |
Łukasz Bartosik <lb@semihalf.com> |
USB: quirks: add quirk for Focusrite Scarlett
The Focusrite Scarlett audio device does not behave correctly during resumes. Below is what happens during every resume (captured with Beagle 5000):
<S
USB: quirks: add quirk for Focusrite Scarlett
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>
show more ...
|
#
303e724d |
| 08-Feb-2023 |
Mark Pearson <mpearson-lenovo@squebb.ca> |
usb: core: add quirk for Alcor Link AK9563 smartcard reader
The Alcor Link AK9563 smartcard reader used on some Lenovo platforms doesn't work. If LPM is enabled the reader will provide an invalid us
usb: core: add quirk for Alcor Link AK9563 smartcard reader
The Alcor Link AK9563 smartcard reader used on some Lenovo platforms doesn't work. If LPM is enabled the reader will provide an invalid usb config descriptor. Added quirk to disable LPM.
Verified fix on Lenovo P16 G1 and T14 G3
Tested-by: Miroslav Zatko <mzatko@mirexoft.com> Tested-by: Dennis Wassenberg <dennis.wassenberg@secunet.com> Cc: stable@vger.kernel.org Signed-off-by: Dennis Wassenberg <dennis.wassenberg@secunet.com> Signed-off-by: Mark Pearson <mpearson-lenovo@squebb.ca> Link: https://lore.kernel.org/r/20230208181223.1092654-1-mpearson-lenovo@squebb.ca Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
show more ...
|
#
181135bb |
| 09-Nov-2022 |
Nicolas Dumazet <ndumazet@google.com> |
usb: add NO_LPM quirk for Realforce 87U Keyboard
Before adding this quirk, this (mechanical keyboard) device would not be recognized, logging:
new full-speed USB device number 56 using xhci_hcd
usb: add NO_LPM quirk for Realforce 87U Keyboard
Before adding this quirk, this (mechanical keyboard) device would not be recognized, logging:
new full-speed USB device number 56 using xhci_hcd unable to read config index 0 descriptor/start: -32 chopping to 0 config(s)
It would take dozens of plugging/unpuggling cycles for the keyboard to be recognized. Keyboard seems to simply work after applying this quirk.
This issue had been reported by users in two places already ([1], [2]) but nobody tried upstreaming a patch yet. After testing I believe their suggested fix (DELAY_INIT + NO_LPM + DEVICE_QUALIFIER) was probably a little overkill. I assume this particular combination was tested because it had been previously suggested in [3], but only NO_LPM seems sufficient for this device.
[1]: https://qiita.com/float168/items/fed43d540c8e2201b543 [2]: https://blog.kostic.dev/posts/making-the-realforce-87ub-work-with-usb30-on-Ubuntu/ [3]: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1678477
Cc: stable@vger.kernel.org Signed-off-by: Nicolas Dumazet <ndumazet@google.com> Link: https://lore.kernel.org/r/20221109122946.706036-1-ndumazet@google.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
show more ...
|
#
37d49519 |
| 27-Sep-2022 |
Jean-Francois Le Fillatre <jflf_kernel@gmx.com> |
usb: add quirks for Lenovo OneLink+ Dock
The Lenovo OneLink+ Dock contains two VL812 USB3.0 controllers: 17ef:1018 upstream 17ef:1019 downstream
These hubs suffer from two separate problems:
1) Af
usb: add quirks for Lenovo OneLink+ Dock
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>
show more ...
|
#
fc4ade55 |
| 19-Sep-2022 |
Hannu Hartikainen <hannu@hrtk.in> |
USB: add RESET_RESUME quirk for NVIDIA Jetson devices in RCM
NVIDIA Jetson devices in Force Recovery mode (RCM) do not support suspending, ie. flashing fails if the device has been suspended. The de
USB: add RESET_RESUME quirk for NVIDIA Jetson devices in RCM
NVIDIA Jetson devices in Force Recovery mode (RCM) do not support suspending, ie. flashing fails if the device has been suspended. The devices are still visible in lsusb and seem to work otherwise, making the issue hard to debug. This has been discovered in various forum posts, eg. [1].
The patch has been tested on NVIDIA Jetson AGX Xavier, but I'm adding all the Jetson models listed in [2] on the assumption that they all behave similarly.
[1]: https://forums.developer.nvidia.com/t/flashing-not-working/72365 [2]: https://docs.nvidia.com/jetson/archives/l4t-archived/l4t-3271/index.html#page/Tegra%20Linux%20Driver%20Package%20Development%20Guide/quick_start.html
Signed-off-by: Hannu Hartikainen <hannu@hrtk.in> Cc: stable <stable@kernel.org> # after 6.1-rc3 Link: https://lore.kernel.org/r/20220919171610.30484-1-hannu@hrtk.in Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
show more ...
|
#
97fa5887 |
| 20-May-2022 |
Monish Kumar R <monish.kumar.r@intel.com> |
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:
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>
show more ...
|
#
ec547af8 |
| 14-Apr-2022 |
Oliver Neukum <oneukum@suse.com> |
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.kerne
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>
show more ...
|
#
2a7ccf6b |
| 14-Apr-2022 |
Oliver Neukum <oneukum@suse.com> |
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.kern
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>
show more ...
|
#
0ad3bd56 |
| 13-Dec-2021 |
Jimmy Wang <wangjm221@gmail.com> |
USB: NO_LPM quirk Lenovo USB-C to Ethernet Adapher(RTL8153-04)
This device doesn't work well with LPM, losing connectivity intermittently. Disable LPM to resolve the issue.
Reviewed-by: <markpearso
USB: NO_LPM quirk Lenovo USB-C to Ethernet Adapher(RTL8153-04)
This device doesn't work well with LPM, losing connectivity intermittently. Disable LPM to resolve the issue.
Reviewed-by: <markpearson@lenovo.com> Signed-off-by: Jimmy Wang <wangjm221@gmail.com> Cc: stable <stable@vger.kernel.org> Link: https://lore.kernel.org/r/20211214012652.4898-1-wangjm221@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
show more ...
|
#
49989adc |
| 27-Nov-2021 |
Ole Ernst <olebowle@gmx.com> |
USB: NO_LPM quirk Lenovo Powered USB-C Travel Hub
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
USB: NO_LPM quirk Lenovo Powered USB-C Travel Hub
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>
show more ...
|
#
f3a1a937 |
| 21-Jul-2021 |
Vincent Palatin <vpalatin@chromium.org> |
Revert "USB: quirks: ignore remote wake-up on Fibocom L850-GL LTE modem"
This reverts commit 0bd860493f81eb2a46173f6f5e44cc38331c8dbd.
While the patch was working as stated,ie preventing the L850-G
Revert "USB: quirks: ignore remote wake-up on Fibocom L850-GL LTE modem"
This reverts commit 0bd860493f81eb2a46173f6f5e44cc38331c8dbd.
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: 0bd860493f81 ("USB: quirks: ignore remote wake-up on Fibocom L850-GL LTE modem") Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
show more ...
|
#
c5c7489d |
| 13-May-2021 |
Chris Chiu <chris.chiu@canonical.com> |
Revert "USB: Add reset-resume quirk for WD19's Realtek Hub"
This reverts commit ca91fd8c7643 ("USB: Add reset-resume quirk for WD19's Realtek Hub"). The previous patch in the series now handles the
Revert "USB: Add reset-resume quirk for WD19's Realtek Hub"
This reverts commit ca91fd8c7643 ("USB: Add reset-resume quirk for WD19's Realtek Hub"). The previous patch in the series now handles the problematic hubs by checking the port status and handling it accordingly when PORT_SUSPEND timeout occurs. We don't need to use reset-resume all the time.
Acked-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Chris Chiu <chris.chiu@canonical.com> Link: https://lore.kernel.org/r/20210514045405.5261-3-chris.chiu@canonical.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
show more ...
|
#
ca91fd8c |
| 20-Apr-2021 |
Chris Chiu <chris.chiu@canonical.com> |
USB: Add reset-resume quirk for WD19's Realtek Hub
Realtek Hub (0bda:5487) in Dell Dock WD19 sometimes fails to work after the system resumes from suspend with remote wakeup enabled device connected
USB: Add reset-resume quirk for WD19's Realtek Hub
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>
show more ...
|
#
8f23fe35 |
| 12-Apr-2021 |
Kai-Heng Feng <kai.heng.feng@canonical.com> |
USB: Add LPM quirk for Lenovo ThinkPad USB-C Dock Gen2 Ethernet
This is another branded 8153 device that doesn't work well with LPM enabled: [ 400.597506] r8152 5-1.1:1.0 enx482ae3a2a6f0: Tx status
USB: Add LPM quirk for Lenovo ThinkPad USB-C Dock Gen2 Ethernet
This is another branded 8153 device that doesn't work well with LPM enabled: [ 400.597506] r8152 5-1.1:1.0 enx482ae3a2a6f0: Tx status -71
So disable LPM to resolve the issue.
Signed-off-by: Kai-Heng Feng <kai.heng.feng@canonical.com> BugLink: https://bugs.launchpad.net/bugs/1922651 Link: https://lore.kernel.org/r/20210412135455.791971-1-kai.heng.feng@canonical.com Cc: stable <stable@vger.kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
show more ...
|
#
0bd86049 |
| 19-Mar-2021 |
Vincent Palatin <vpalatin@chromium.org> |
USB: quirks: ignore remote wake-up on Fibocom L850-GL LTE modem
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
USB: quirks: ignore remote wake-up on Fibocom L850-GL LTE modem
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>
show more ...
|
#
1ebe718b |
| 10-Feb-2021 |
Stefan Ursella <stefan.ursella@wolfvision.net> |
usb: quirks: add quirk to start video capture on ELMO L-12F document camera reliable
Without this quirk starting a video capture from the device often fails with
kernel: uvcvideo: Failed to set UVC
usb: quirks: add quirk to start video capture on ELMO L-12F document camera reliable
Without this quirk starting a video capture from the device often fails with
kernel: uvcvideo: Failed to set UVC probe control : -110 (exp. 34).
Signed-off-by: Stefan Ursella <stefan.ursella@wolfvision.net> Link: https://lore.kernel.org/r/20210210140713.18711-1-stefan.ursella@wolfvision.net Cc: stable <stable@vger.kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
show more ...
|
#
43861d29 |
| 10-Feb-2021 |
Johan Hovold <johan@kernel.org> |
USB: quirks: sort quirk entries
Move the last entry to its proper place to maintain the VID/PID sort order.
Cc: stable@vger.kernel.org Signed-off-by: Johan Hovold <johan@kernel.org> Link: https://l
USB: quirks: sort quirk entries
Move the last entry to its proper place to maintain the VID/PID sort order.
Cc: stable@vger.kernel.org Signed-off-by: Johan Hovold <johan@kernel.org> Link: https://lore.kernel.org/r/20210210111746.13360-1-johan@kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
show more ...
|
#
08a02f95 |
| 07-Dec-2020 |
Oliver Neukum <oneukum@suse.com> |
USB: add RESET_RESUME quirk for Snapscan 1212
I got reports that some models of this old scanner need this when using runtime PM.
Signed-off-by: Oliver Neukum <oneukum@suse.com> Cc: stable <stable@
USB: add RESET_RESUME quirk for Snapscan 1212
I got reports that some models of this old scanner need this when using runtime PM.
Signed-off-by: Oliver Neukum <oneukum@suse.com> Cc: stable <stable@vger.kernel.org> Link: https://lore.kernel.org/r/20201207130323.23857-1-oneukum@suse.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
show more ...
|
#
184eead0 |
| 19-Nov-2020 |
Alan Stern <stern@rowland.harvard.edu> |
USB: core: Fix regression in Hercules audio card
Commit 3e4f8e21c4f2 ("USB: core: fix check for duplicate endpoints") aimed to make the USB stack more reliable by detecting and skipping over endpoin
USB: core: Fix regression in Hercules audio card
Commit 3e4f8e21c4f2 ("USB: core: fix check for duplicate endpoints") aimed to make the USB stack more reliable by detecting and skipping over endpoints that are duplicated between interfaces. This caused a regression for a Hercules audio card (reported as Bugzilla #208357), which contains such non-compliant duplications. Although the duplications are harmless, skipping the valid endpoints prevented the device from working.
This patch fixes the regression by adding ENDPOINT_IGNORE quirks for the Hercules card, telling the kernel to ignore the invalid duplicate endpoints and thereby allowing the valid endpoints to be used as intended.
Fixes: 3e4f8e21c4f2 ("USB: core: fix check for duplicate endpoints") CC: <stable@vger.kernel.org> Reported-by: Alexander Chalikiopoulos <bugzilla.kernel.org@mrtoasted.com> Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Link: https://lore.kernel.org/r/20201119170040.GA576844@rowland.harvard.edu Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
show more ...
|
#
9ca57518 |
| 18-Nov-2020 |
penghao <penghao@uniontech.com> |
USB: quirks: Add USB_QUIRK_DISCONNECT_SUSPEND quirk for Lenovo A630Z TIO built-in usb-audio card
Add a USB_QUIRK_DISCONNECT_SUSPEND quirk for the Lenovo TIO built-in usb-audio. when A630Z going into
USB: quirks: Add USB_QUIRK_DISCONNECT_SUSPEND quirk for Lenovo A630Z TIO built-in usb-audio card
Add a USB_QUIRK_DISCONNECT_SUSPEND quirk for the Lenovo TIO built-in usb-audio. when A630Z going into S3,the system immediately wakeup 7-8 seconds later by usb-audio disconnect interrupt to avoids the issue. eg dmesg: .... [ 626.974091 ] usb 7-1.1: USB disconnect, device number 3 .... .... [ 1774.486691] usb 7-1.1: new full-speed USB device number 5 using xhci_hcd [ 1774.947742] usb 7-1.1: New USB device found, idVendor=17ef, idProduct=a012, bcdDevice= 0.55 [ 1774.956588] usb 7-1.1: New USB device strings: Mfr=1, Product=2, SerialNumber=3 [ 1774.964339] usb 7-1.1: Product: Thinkcentre TIO24Gen3 for USB-audio [ 1774.970999] usb 7-1.1: Manufacturer: Lenovo [ 1774.975447] usb 7-1.1: SerialNumber: 000000000000 [ 1775.048590] usb 7-1.1: 2:1: cannot get freq at ep 0x1 ....... Seeking a better fix, we've tried a lot of things, including: - Check that the device's power/wakeup is disabled - Check that remote wakeup is off at the USB level - All the quirks in drivers/usb/core/quirks.c e.g. USB_QUIRK_RESET_RESUME, USB_QUIRK_RESET, USB_QUIRK_IGNORE_REMOTE_WAKEUP, USB_QUIRK_NO_LPM.
but none of that makes any difference.
There are no errors in the logs showing any suspend/resume-related issues. When the system wakes up due to the modem, log-wise it appears to be a normal resume.
Introduce a quirk to disable the port during suspend when the modem is detected.
Signed-off-by: penghao <penghao@uniontech.com> Link: https://lore.kernel.org/r/20201118123039.11696-1-penghao@uniontech.com Cc: stable <stable@vger.kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
show more ...
|
#
afaa2e74 |
| 02-Nov-2020 |
Alan Stern <stern@rowland.harvard.edu> |
USB: Add NO_LPM quirk for Kingston flash drive
In Bugzilla #208257, Julien Humbert reports that a 32-GB Kingston flash drive spontaneously disconnects and reconnects, over and over. Testing revealed
USB: Add NO_LPM quirk for Kingston flash drive
In Bugzilla #208257, Julien Humbert reports that a 32-GB Kingston flash drive spontaneously disconnects and reconnects, over and over. Testing revealed that disabling Link Power Management for the drive fixed the problem.
This patch adds a quirk entry for that drive to turn off LPM permanently.
CC: Hans de Goede <jwrdegoede@fedoraproject.org> CC: <stable@vger.kernel.org> Reported-and-tested-by: Julien Humbert <julroy67@gmail.com> Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Link: https://lore.kernel.org/r/20201102145821.GA1478741@rowland.harvard.edu Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
show more ...
|
#
bcea6daf |
| 06-Sep-2020 |
Penghao <penghao@uniontech.com> |
USB: quirks: Add USB_QUIRK_IGNORE_REMOTE_WAKEUP quirk for BYD zhaoxin notebook
Add a USB_QUIRK_IGNORE_REMOTE_WAKEUP quirk for the BYD zhaoxin notebook. This notebook come with usb touchpad. And we w
USB: quirks: Add USB_QUIRK_IGNORE_REMOTE_WAKEUP quirk for BYD zhaoxin notebook
Add a USB_QUIRK_IGNORE_REMOTE_WAKEUP quirk for the BYD zhaoxin notebook. This notebook come with usb touchpad. And we would like to disable touchpad wakeup on this notebook by default.
Signed-off-by: Penghao <penghao@uniontech.com> Cc: stable <stable@vger.kernel.org> Link: https://lore.kernel.org/r/20200907023026.28189-1-penghao@uniontech.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
show more ...
|
#
068834a2 |
| 26-Aug-2020 |
Alan Stern <stern@rowland.harvard.edu> |
USB: quirks: Ignore duplicate endpoint on Sound Devices MixPre-D
The Sound Devices MixPre-D audio card suffers from the same defect as the Sound Devices USBPre2: an endpoint shared between a normal
USB: quirks: Ignore duplicate endpoint on Sound Devices MixPre-D
The Sound Devices MixPre-D audio card suffers from the same defect as the Sound Devices USBPre2: an endpoint shared between a normal audio interface and a vendor-specific interface, in violation of the USB spec. Since the USB core now treats duplicated endpoints as bugs and ignores them, the audio endpoint isn't available and the card can't be used for audio capture.
Along the same lines as commit bdd1b147b802 ("USB: quirks: blacklist duplicate ep on Sound Devices USBPre2"), this patch adds a quirks entry saying to ignore ep5in for interface 1, leaving it available for use with standard audio interface 2.
Reported-and-tested-by: Jean-Christophe Barnoud <jcbarnoud@gmail.com> Signed-off-by: Alan Stern <stern@rowland.harvard.edu> CC: <stable@vger.kernel.org> Fixes: 3e4f8e21c4f2 ("USB: core: fix check for duplicate endpoints") Link: https://lore.kernel.org/r/20200826194624.GA412633@rowland.harvard.edu Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
show more ...
|