diff options
author | Łukasz Bartosik <lb@semihalf.com> | 2023-07-24 13:29:11 +0200 |
---|---|---|
committer | Greg Kroah-Hartman <gregkh@linuxfoundation.org> | 2023-07-25 17:41:22 +0200 |
commit | 9dc162e22387080e2d06de708b89920c0e158c9a (patch) | |
tree | 2a0cb0b128e938be58befb2719b8476933d789fc /drivers/most | |
parent | usb: xhci-mtk: set the dma max_seg_size (diff) | |
download | linux-9dc162e22387080e2d06de708b89920c0e158c9a.tar.xz linux-9dc162e22387080e2d06de708b89920c0e158c9a.zip |
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>
Diffstat (limited to 'drivers/most')
0 files changed, 0 insertions, 0 deletions