| Message ID | 20230724112911.1802577-1-lb@semihalf.com (mailing list archive) |
|---|---|
| State | Accepted |
| Commit | 9dc162e22387080e2d06de708b89920c0e158c9a |
| Headers | show |
| Series | USB: quirks: add quirk for Focusrite Scarlett | expand |
diff --git a/drivers/usb/core/quirks.c b/drivers/usb/core/quirks.c index 934b3d997..15e9bd180 100644 --- a/drivers/usb/core/quirks.c +++ b/drivers/usb/core/quirks.c @@ -436,6 +436,10 @@ static const struct usb_device_id usb_quirk_list[] = { /* novation SoundControl XL */ { USB_DEVICE(0x1235, 0x0061), .driver_info = USB_QUIRK_RESET_RESUME }, + /* Focusrite Scarlett Solo USB */ + { USB_DEVICE(0x1235, 0x8211), .driver_info = + USB_QUIRK_DISCONNECT_SUSPEND }, + /* Huawei 4G LTE module */ { USB_DEVICE(0x12d1, 0x15bb), .driver_info = USB_QUIRK_DISCONNECT_SUSPEND },
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> --- drivers/usb/core/quirks.c | 4 ++++ 1 file changed, 4 insertions(+)