* [PATCH v7 2/2] media: uvcvideo: add Razer Kiyo Pro to device info table
From: JP Hein @ 2026-04-10 0:28 UTC (permalink / raw)
To: Laurent Pinchart, Hans de Goede, Greg Kroah-Hartman
Cc: linux-media, linux-usb, Ricardo Ribalda, Michal Pecio, JP Hein
In-Reply-To: <20260410002831.1046407-1-jp@jphein.com>
Add a device entry for the Razer Kiyo Pro (1532:0e05) with quirks to
work around firmware bugs that crash the xHCI host controller:
UVC_QUIRK_CTRL_THROTTLE - rate-limit control transfers to prevent
firmware lockup under sustained load
UVC_QUIRK_DISABLE_AUTOSUSPEND - prevent runtime suspend
UVC_QUIRK_NO_RESET_RESUME - skip post-reset reinitialization
The firmware (v1.5.0.1) has two failure modes: it stalls endpoints
under rapid control transfers (~25 without delay), and it fails to
reinitialize properly after USB power state transitions. Both can
cascade into xHCI controller death, disconnecting all USB devices on
the bus.
Bug reproduced on two separate Kiyo Pro units running simultaneously,
confirming the issue is not unit-specific.
lsusb -vv:
Bus 002 Device 002: ID 1532:0e05 Razer USA, Ltd Razer Kiyo Pro
Device Descriptor:
bLength 18
bDescriptorType 1
bcdUSB 3.20
bDeviceClass 239 Miscellaneous Device
bDeviceSubClass 2 [unknown]
bDeviceProtocol 1 Interface Association
bMaxPacketSize0 9
idVendor 0x1532 Razer USA, Ltd
idProduct 0x0e05 Razer Kiyo Pro
bcdDevice 8.21
iManufacturer 1 Razer Inc
iProduct 2 Razer Kiyo Pro
iSerial 0
bNumConfigurations 1
Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength 0x05b4
bNumInterfaces 4
bConfigurationValue 1
iConfiguration 0
bmAttributes 0x80
(Bus Powered)
MaxPower 896mA
Interface Association:
bLength 8
bDescriptorType 11
bFirstInterface 0
bInterfaceCount 2
bFunctionClass 14 Video
bFunctionSubClass 3 Video Interface Collection
bFunctionProtocol 0
iFunction 0
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 0
bAlternateSetting 0
bNumEndpoints 1
bInterfaceClass 14 Video
bInterfaceSubClass 1 Video Control
bInterfaceProtocol 0
iInterface 0
VideoControl Interface Descriptor:
bLength 13
bDescriptorType 36
bDescriptorSubtype 1 (HEADER)
bcdUVC 1.00
wTotalLength 0x0069
dwClockFrequency 30.000000MHz
bInCollection 1
baInterfaceNr( 0) 1
VideoControl Interface Descriptor:
bLength 9
bDescriptorType 36
bDescriptorSubtype 3 (OUTPUT_TERMINAL)
bTerminalID 4
wTerminalType 0x0101 USB Streaming
bAssocTerminal 0
bSourceID 2
iTerminal 0
VideoControl Interface Descriptor:
bLength 27
bDescriptorType 36
bDescriptorSubtype 6 (EXTENSION_UNIT)
bUnitID 2
guidExtensionCode {2c49d16a-32b8-4485-3ea8-643a152362f2}
bNumControls 6
bNrInPins 1
baSourceID( 0) 6
bControlSize 2
bmControls( 0) 0x3f
bmControls( 1) 0x00
iExtension 0
VideoControl Interface Descriptor:
bLength 27
bDescriptorType 36
bDescriptorSubtype 6 (EXTENSION_UNIT)
bUnitID 6
guidExtensionCode {23e49ed0-1178-4f31-ae52-d2fb8a8d3b48}
bNumControls 5
bNrInPins 1
baSourceID( 0) 3
bControlSize 2
bmControls( 0) 0xff
bmControls( 1) 0x7f
iExtension 0
VideoControl Interface Descriptor:
bLength 18
bDescriptorType 36
bDescriptorSubtype 2 (INPUT_TERMINAL)
bTerminalID 1
wTerminalType 0x0201 Camera Sensor
bAssocTerminal 0
iTerminal 0
wObjectiveFocalLengthMin 0
wObjectiveFocalLengthMax 0
wOcularFocalLength 0
bControlSize 3
bmControls 0x00020a2e
Auto-Exposure Mode
Auto-Exposure Priority
Exposure Time (Absolute)
Focus (Absolute)
Zoom (Absolute)
PanTilt (Absolute)
Focus, Auto
VideoControl Interface Descriptor:
bLength 11
bDescriptorType 36
bDescriptorSubtype 5 (PROCESSING_UNIT)
Warning: Descriptor too short
bUnitID 3
bSourceID 1
wMaxMultiplier 0
bControlSize 2
bmControls 0x0000175b
Brightness
Contrast
Saturation
Sharpness
White Balance Temperature
Backlight Compensation
Gain
Power Line Frequency
White Balance Temperature, Auto
iProcessing 0
bmVideoStandards 0xff
None
NTSC - 525/60
PAL - 625/50
SECAM - 625/50
NTSC - 625/50
PAL - 525/60
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x85 EP 5 IN
bmAttributes 3
Transfer Type Interrupt
Synch Type None
Usage Type Data
wMaxPacketSize 0x0040 1x 64 bytes
bInterval 8
bMaxBurst 0
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 1
bAlternateSetting 0
bNumEndpoints 0
bInterfaceClass 14 Video
bInterfaceSubClass 2 Video Streaming
bInterfaceProtocol 0
iInterface 0
VideoStreaming Interface Descriptor:
bLength 17
bDescriptorType 36
bDescriptorSubtype 1 (INPUT_HEADER)
bNumFormats 4
wTotalLength 0x03e6
bEndpointAddress 0x81 EP 1 IN
bmInfo 0
bTerminalLink 4
bStillCaptureMethod 0
bTriggerSupport 0
bTriggerUsage 0
bControlSize 1
bmaControls( 0) 0
bmaControls( 1) 0
bmaControls( 2) 0
bmaControls( 3) 0
VideoStreaming Interface Descriptor:
bLength 27
bDescriptorType 36
bDescriptorSubtype 4 (FORMAT_UNCOMPRESSED)
bFormatIndex 1
bNumFrameDescriptors 4
guidFormat {32595559-0000-0010-8000-00aa00389b71}
bBitsPerPixel 16
bDefaultFrameIndex 1
bAspectRatioX 0
bAspectRatioY 0
bmInterlaceFlags 0x00
Interlaced stream or variable: No
Fields per frame: 2 fields
Field 1 first: No
Field pattern: Field 1 only
bCopyProtect 0
VideoStreaming Interface Descriptor:
bLength 54
bDescriptorType 36
bDescriptorSubtype 5 (FRAME_UNCOMPRESSED)
bFrameIndex 1
bmCapabilities 0x00
Still image unsupported
wWidth 640
wHeight 480
dwMinBitRate 294912000
dwMaxBitRate 294912000
dwMaxVideoFrameBufferSize 614400
dwDefaultFrameInterval 166666
bFrameIntervalType 7
dwFrameInterval( 0) 166666
dwFrameInterval( 1) 333333
dwFrameInterval( 2) 416666
dwFrameInterval( 3) 500000
dwFrameInterval( 4) 666666
dwFrameInterval( 5) 1000000
dwFrameInterval( 6) 2000000
VideoStreaming Interface Descriptor:
bLength 54
bDescriptorType 36
bDescriptorSubtype 5 (FRAME_UNCOMPRESSED)
bFrameIndex 7
bmCapabilities 0x00
Still image unsupported
wWidth 640
wHeight 360
dwMinBitRate 221184000
dwMaxBitRate 221184000
dwMaxVideoFrameBufferSize 460800
dwDefaultFrameInterval 166666
bFrameIntervalType 7
dwFrameInterval( 0) 166666
dwFrameInterval( 1) 333333
dwFrameInterval( 2) 416666
dwFrameInterval( 3) 500000
dwFrameInterval( 4) 666666
dwFrameInterval( 5) 1000000
dwFrameInterval( 6) 2000000
VideoStreaming Interface Descriptor:
bLength 54
bDescriptorType 36
bDescriptorSubtype 5 (FRAME_UNCOMPRESSED)
bFrameIndex 11
bmCapabilities 0x00
Still image unsupported
wWidth 1280
wHeight 720
dwMinBitRate 884736000
dwMaxBitRate 884736000
dwMaxVideoFrameBufferSize 1843200
dwDefaultFrameInterval 166666
bFrameIntervalType 7
dwFrameInterval( 0) 166666
dwFrameInterval( 1) 333333
dwFrameInterval( 2) 416666
dwFrameInterval( 3) 500000
dwFrameInterval( 4) 666666
dwFrameInterval( 5) 1000000
dwFrameInterval( 6) 2000000
VideoStreaming Interface Descriptor:
bLength 54
bDescriptorType 36
bDescriptorSubtype 5 (FRAME_UNCOMPRESSED)
bFrameIndex 13
bmCapabilities 0x00
Still image unsupported
wWidth 1920
wHeight 1080
dwMinBitRate 1990656000
dwMaxBitRate 1990656000
dwMaxVideoFrameBufferSize 4147200
dwDefaultFrameInterval 166666
bFrameIntervalType 7
dwFrameInterval( 0) 166666
dwFrameInterval( 1) 333333
dwFrameInterval( 2) 416666
dwFrameInterval( 3) 500000
dwFrameInterval( 4) 666666
dwFrameInterval( 5) 1000000
dwFrameInterval( 6) 2000000
VideoStreaming Interface Descriptor:
bLength 6
bDescriptorType 36
bDescriptorSubtype 13 (COLORFORMAT)
bColorPrimaries 1 (BT.709,sRGB)
bTransferCharacteristics 1 (BT.709)
bMatrixCoefficients 4 (SMPTE 170M (BT.601))
VideoStreaming Interface Descriptor:
bLength 11
bDescriptorType 36
bDescriptorSubtype 6 (FORMAT_MJPEG)
bFormatIndex 2
bNumFrameDescriptors 4
bFlags 0
Fixed-size samples: No
bDefaultFrameIndex 1
bAspectRatioX 0
bAspectRatioY 0
bmInterlaceFlags 0x00
Interlaced stream or variable: No
Fields per frame: 1 fields
Field 1 first: No
Field pattern: Field 1 only
bCopyProtect 0
VideoStreaming Interface Descriptor:
bLength 54
bDescriptorType 36
bDescriptorSubtype 7 (FRAME_MJPEG)
bFrameIndex 1
bmCapabilities 0x00
Still image unsupported
wWidth 640
wHeight 480
dwMinBitRate 294912000
dwMaxBitRate 294912000
dwMaxVideoFrameBufferSize 614400
dwDefaultFrameInterval 166666
bFrameIntervalType 7
dwFrameInterval( 0) 166666
dwFrameInterval( 1) 333333
dwFrameInterval( 2) 416666
dwFrameInterval( 3) 500000
dwFrameInterval( 4) 666666
dwFrameInterval( 5) 1000000
dwFrameInterval( 6) 2000000
VideoStreaming Interface Descriptor:
bLength 54
bDescriptorType 36
bDescriptorSubtype 7 (FRAME_MJPEG)
bFrameIndex 7
bmCapabilities 0x00
Still image unsupported
wWidth 640
wHeight 360
dwMinBitRate 221184000
dwMaxBitRate 221184000
dwMaxVideoFrameBufferSize 460800
dwDefaultFrameInterval 166666
bFrameIntervalType 7
dwFrameInterval( 0) 166666
dwFrameInterval( 1) 333333
dwFrameInterval( 2) 416666
dwFrameInterval( 3) 500000
dwFrameInterval( 4) 666666
dwFrameInterval( 5) 1000000
dwFrameInterval( 6) 2000000
VideoStreaming Interface Descriptor:
bLength 54
bDescriptorType 36
bDescriptorSubtype 7 (FRAME_MJPEG)
bFrameIndex 11
bmCapabilities 0x00
Still image unsupported
wWidth 1280
wHeight 720
dwMinBitRate 884736000
dwMaxBitRate 884736000
dwMaxVideoFrameBufferSize 1843200
dwDefaultFrameInterval 166666
bFrameIntervalType 7
dwFrameInterval( 0) 166666
dwFrameInterval( 1) 333333
dwFrameInterval( 2) 416666
dwFrameInterval( 3) 500000
dwFrameInterval( 4) 666666
dwFrameInterval( 5) 1000000
dwFrameInterval( 6) 2000000
VideoStreaming Interface Descriptor:
bLength 54
bDescriptorType 36
bDescriptorSubtype 7 (FRAME_MJPEG)
bFrameIndex 13
bmCapabilities 0x00
Still image unsupported
wWidth 1920
wHeight 1080
dwMinBitRate 1990656000
dwMaxBitRate 1990656000
dwMaxVideoFrameBufferSize 4147200
dwDefaultFrameInterval 166666
bFrameIntervalType 7
dwFrameInterval( 0) 166666
dwFrameInterval( 1) 333333
dwFrameInterval( 2) 416666
dwFrameInterval( 3) 500000
dwFrameInterval( 4) 666666
dwFrameInterval( 5) 1000000
dwFrameInterval( 6) 2000000
VideoStreaming Interface Descriptor:
bLength 6
bDescriptorType 36
bDescriptorSubtype 13 (COLORFORMAT)
bColorPrimaries 1 (BT.709,sRGB)
bTransferCharacteristics 1 (BT.709)
bMatrixCoefficients 4 (SMPTE 170M (BT.601))
VideoStreaming Interface Descriptor:
bLength 28
bDescriptorType 36
bDescriptorSubtype 16 (FORMAT_FRAME_BASED)
bFormatIndex 3
bNumFrameDescriptors 4
guidFormat {34363248-0000-0010-8000-00aa00389b71}
bBitsPerPixel 16
bDefaultFrameIndex 1
bAspectRatioX 0
bAspectRatioY 0
bmInterlaceFlags 0x00
Interlaced stream or variable: No
Fields per frame: 2 fields
Field 1 first: No
Field pattern: Field 1 only
bCopyProtect 0
bVariableSize 1
VideoStreaming Interface Descriptor:
bLength 54
bDescriptorType 36
bDescriptorSubtype 17 (FRAME_FRAME_BASED)
bFrameIndex 1
bmCapabilities 0x00
Still image unsupported
wWidth 640
wHeight 480
dwMinBitRate 251658240
dwMaxBitRate 503316480
dwDefaultFrameInterval 166666
bFrameIntervalType 7
dwBytesPerLine 0
dwFrameInterval( 0) 166666
dwFrameInterval( 1) 333333
dwFrameInterval( 2) 416666
dwFrameInterval( 3) 500000
dwFrameInterval( 4) 666666
dwFrameInterval( 5) 1000000
dwFrameInterval( 6) 2000000
VideoStreaming Interface Descriptor:
bLength 54
bDescriptorType 36
bDescriptorSubtype 17 (FRAME_FRAME_BASED)
bFrameIndex 9
bmCapabilities 0x00
Still image unsupported
wWidth 640
wHeight 360
dwMinBitRate 251658240
dwMaxBitRate 503316480
dwDefaultFrameInterval 166666
bFrameIntervalType 7
dwBytesPerLine 0
dwFrameInterval( 0) 166666
dwFrameInterval( 1) 333333
dwFrameInterval( 2) 416666
dwFrameInterval( 3) 500000
dwFrameInterval( 4) 666666
dwFrameInterval( 5) 1000000
dwFrameInterval( 6) 2000000
VideoStreaming Interface Descriptor:
bLength 54
bDescriptorType 36
bDescriptorSubtype 17 (FRAME_FRAME_BASED)
bFrameIndex 15
bmCapabilities 0x00
Still image unsupported
wWidth 1280
wHeight 720
dwMinBitRate 251658240
dwMaxBitRate 503316480
dwDefaultFrameInterval 166666
bFrameIntervalType 7
dwBytesPerLine 0
dwFrameInterval( 0) 166666
dwFrameInterval( 1) 333333
dwFrameInterval( 2) 416666
dwFrameInterval( 3) 500000
dwFrameInterval( 4) 666666
dwFrameInterval( 5) 1000000
dwFrameInterval( 6) 2000000
VideoStreaming Interface Descriptor:
bLength 54
bDescriptorType 36
bDescriptorSubtype 17 (FRAME_FRAME_BASED)
bFrameIndex 17
bmCapabilities 0x00
Still image unsupported
wWidth 1920
wHeight 1080
dwMinBitRate 251658240
dwMaxBitRate 503316480
dwDefaultFrameInterval 166666
bFrameIntervalType 7
dwBytesPerLine 0
dwFrameInterval( 0) 166666
dwFrameInterval( 1) 333333
dwFrameInterval( 2) 416666
dwFrameInterval( 3) 500000
dwFrameInterval( 4) 666666
dwFrameInterval( 5) 1000000
dwFrameInterval( 6) 2000000
VideoStreaming Interface Descriptor:
bLength 6
bDescriptorType 36
bDescriptorSubtype 13 (COLORFORMAT)
bColorPrimaries 1 (BT.709,sRGB)
bTransferCharacteristics 1 (BT.709)
bMatrixCoefficients 4 (SMPTE 170M (BT.601))
VideoStreaming Interface Descriptor:
bLength 27
bDescriptorType 36
bDescriptorSubtype 4 (FORMAT_UNCOMPRESSED)
bFormatIndex 4
bNumFrameDescriptors 4
guidFormat {3231564e-0000-0010-8000-00aa00389b71}
bBitsPerPixel 12
bDefaultFrameIndex 1
bAspectRatioX 0
bAspectRatioY 0
bmInterlaceFlags 0x00
Interlaced stream or variable: No
Fields per frame: 2 fields
Field 1 first: No
Field pattern: Field 1 only
bCopyProtect 0
VideoStreaming Interface Descriptor:
bLength 54
bDescriptorType 36
bDescriptorSubtype 5 (FRAME_UNCOMPRESSED)
bFrameIndex 1
bmCapabilities 0x00
Still image unsupported
wWidth 640
wHeight 480
dwMinBitRate 221184000
dwMaxBitRate 221184000
dwMaxVideoFrameBufferSize 460800
dwDefaultFrameInterval 166666
bFrameIntervalType 7
dwFrameInterval( 0) 166666
dwFrameInterval( 1) 333333
dwFrameInterval( 2) 416666
dwFrameInterval( 3) 500000
dwFrameInterval( 4) 666666
dwFrameInterval( 5) 1000000
dwFrameInterval( 6) 2000000
VideoStreaming Interface Descriptor:
bLength 54
bDescriptorType 36
bDescriptorSubtype 5 (FRAME_UNCOMPRESSED)
bFrameIndex 2
bmCapabilities 0x00
Still image unsupported
wWidth 640
wHeight 360
dwMinBitRate 165888000
dwMaxBitRate 165888000
dwMaxVideoFrameBufferSize 345600
dwDefaultFrameInterval 166666
bFrameIntervalType 7
dwFrameInterval( 0) 166666
dwFrameInterval( 1) 333333
dwFrameInterval( 2) 416666
dwFrameInterval( 3) 500000
dwFrameInterval( 4) 666666
dwFrameInterval( 5) 1000000
dwFrameInterval( 6) 2000000
VideoStreaming Interface Descriptor:
bLength 54
bDescriptorType 36
bDescriptorSubtype 5 (FRAME_UNCOMPRESSED)
bFrameIndex 3
bmCapabilities 0x00
Still image unsupported
wWidth 1280
wHeight 720
dwMinBitRate 663552000
dwMaxBitRate 663552000
dwMaxVideoFrameBufferSize 1382400
dwDefaultFrameInterval 166666
bFrameIntervalType 7
dwFrameInterval( 0) 166666
dwFrameInterval( 1) 333333
dwFrameInterval( 2) 416666
dwFrameInterval( 3) 500000
dwFrameInterval( 4) 666666
dwFrameInterval( 5) 1000000
dwFrameInterval( 6) 2000000
VideoStreaming Interface Descriptor:
bLength 54
bDescriptorType 36
bDescriptorSubtype 5 (FRAME_UNCOMPRESSED)
bFrameIndex 4
bmCapabilities 0x00
Still image unsupported
wWidth 1920
wHeight 1080
dwMinBitRate 1492992000
dwMaxBitRate 1492992000
dwMaxVideoFrameBufferSize 3110400
dwDefaultFrameInterval 166666
bFrameIntervalType 7
dwFrameInterval( 0) 166666
dwFrameInterval( 1) 333333
dwFrameInterval( 2) 416666
dwFrameInterval( 3) 500000
dwFrameInterval( 4) 666666
dwFrameInterval( 5) 1000000
dwFrameInterval( 6) 2000000
VideoStreaming Interface Descriptor:
bLength 6
bDescriptorType 36
bDescriptorSubtype 13 (COLORFORMAT)
bColorPrimaries 1 (BT.709,sRGB)
bTransferCharacteristics 1 (BT.709)
bMatrixCoefficients 4 (SMPTE 170M (BT.601))
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 1
bAlternateSetting 1
bNumEndpoints 1
bInterfaceClass 14 Video
bInterfaceSubClass 2 Video Streaming
bInterfaceProtocol 0
iInterface 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x81 EP 1 IN
bmAttributes 5
Transfer Type Isochronous
Synch Type Asynchronous
Usage Type Data
wMaxPacketSize 0x0400 1x 1024 bytes
bInterval 1
bMaxBurst 0
Mult 2
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 1
bAlternateSetting 2
bNumEndpoints 1
bInterfaceClass 14 Video
bInterfaceSubClass 2 Video Streaming
bInterfaceProtocol 0
iInterface 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x81 EP 1 IN
bmAttributes 5
Transfer Type Isochronous
Synch Type Asynchronous
Usage Type Data
wMaxPacketSize 0x0400 1x 1024 bytes
bInterval 1
bMaxBurst 10
Mult 2
Interface Association:
bLength 8
bDescriptorType 11
bFirstInterface 2
bInterfaceCount 2
bFunctionClass 1 Audio
bFunctionSubClass 2 Streaming
bFunctionProtocol 0
iFunction 0
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 2
bAlternateSetting 0
bNumEndpoints 0
bInterfaceClass 1 Audio
bInterfaceSubClass 1 Control Device
bInterfaceProtocol 0
iInterface 0
AudioControl Interface Descriptor:
bLength 9
bDescriptorType 36
bDescriptorSubtype 1 (HEADER)
bcdADC 1.00
wTotalLength 0x0026
bInCollection 1
baInterfaceNr(0) 3
AudioControl Interface Descriptor:
bLength 12
bDescriptorType 36
bDescriptorSubtype 2 (INPUT_TERMINAL)
bTerminalID 1
wTerminalType 0x0201 Microphone
bAssocTerminal 0
bNrChannels 2
wChannelConfig 0x0003
Left Front (L)
Right Front (R)
iChannelNames 0
iTerminal 0
AudioControl Interface Descriptor:
bLength 9
bDescriptorType 36
bDescriptorSubtype 3 (OUTPUT_TERMINAL)
bTerminalID 3
wTerminalType 0x0101 USB Streaming
bAssocTerminal 0
bSourceID 5
iTerminal 0
AudioControl Interface Descriptor:
bLength 8
bDescriptorType 36
bDescriptorSubtype 6 (FEATURE_UNIT)
bUnitID 5
bSourceID 1
bControlSize 1
bmaControls(0) 0x03
Mute Control
Volume Control
iFeature 0
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 3
bAlternateSetting 0
bNumEndpoints 0
bInterfaceClass 1 Audio
bInterfaceSubClass 2 Streaming
bInterfaceProtocol 0
iInterface 0
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 3
bAlternateSetting 1
bNumEndpoints 1
bInterfaceClass 1 Audio
bInterfaceSubClass 2 Streaming
bInterfaceProtocol 0
iInterface 0
AudioStreaming Interface Descriptor:
bLength 7
bDescriptorType 36
bDescriptorSubtype 1 (AS_GENERAL)
bTerminalLink 3
bDelay 2 frames
wFormatTag 0x0001 PCM
AudioStreaming Interface Descriptor:
bLength 11
bDescriptorType 36
bDescriptorSubtype 2 (FORMAT_TYPE)
bFormatType 1 (FORMAT_TYPE_I)
bNrChannels 2
bSubframeSize 2
bBitResolution 16
bSamFreqType 1 Discrete
tSamFreq[ 0] 48000
Endpoint Descriptor:
bLength 9
bDescriptorType 5
bEndpointAddress 0x82 EP 2 IN
bmAttributes 5
Transfer Type Isochronous
Synch Type Asynchronous
Usage Type Data
wMaxPacketSize 0x00c4 1x 196 bytes
bInterval 4
bRefresh 0
bSynchAddress 0
bMaxBurst 0
AudioStreaming Endpoint Descriptor:
bLength 7
bDescriptorType 37
bDescriptorSubtype 1 (EP_GENERAL)
bmAttributes 0x01
Sampling Frequency
bLockDelayUnits 0 Undefined
wLockDelay 0x0000
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 3
bAlternateSetting 2
bNumEndpoints 1
bInterfaceClass 1 Audio
bInterfaceSubClass 2 Streaming
bInterfaceProtocol 0
iInterface 0
AudioStreaming Interface Descriptor:
bLength 7
bDescriptorType 36
bDescriptorSubtype 1 (AS_GENERAL)
bTerminalLink 3
bDelay 2 frames
wFormatTag 0x0001 PCM
AudioStreaming Interface Descriptor:
bLength 11
bDescriptorType 36
bDescriptorSubtype 2 (FORMAT_TYPE)
bFormatType 1 (FORMAT_TYPE_I)
bNrChannels 2
bSubframeSize 2
bBitResolution 16
bSamFreqType 1 Discrete
tSamFreq[ 0] 16000
Endpoint Descriptor:
bLength 9
bDescriptorType 5
bEndpointAddress 0x82 EP 2 IN
bmAttributes 5
Transfer Type Isochronous
Synch Type Asynchronous
Usage Type Data
wMaxPacketSize 0x0044 1x 68 bytes
bInterval 4
bRefresh 0
bSynchAddress 0
bMaxBurst 0
AudioStreaming Endpoint Descriptor:
bLength 7
bDescriptorType 37
bDescriptorSubtype 1 (EP_GENERAL)
bmAttributes 0x01
Sampling Frequency
bLockDelayUnits 0 Undefined
wLockDelay 0x0000
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 3
bAlternateSetting 3
bNumEndpoints 1
bInterfaceClass 1 Audio
bInterfaceSubClass 2 Streaming
bInterfaceProtocol 0
iInterface 0
AudioStreaming Interface Descriptor:
bLength 7
bDescriptorType 36
bDescriptorSubtype 1 (AS_GENERAL)
bTerminalLink 3
bDelay 2 frames
wFormatTag 0x0001 PCM
AudioStreaming Interface Descriptor:
bLength 11
bDescriptorType 36
bDescriptorSubtype 2 (FORMAT_TYPE)
bFormatType 1 (FORMAT_TYPE_I)
bNrChannels 2
bSubframeSize 2
bBitResolution 16
bSamFreqType 1 Discrete
tSamFreq[ 0] 24000
Endpoint Descriptor:
bLength 9
bDescriptorType 5
bEndpointAddress 0x82 EP 2 IN
bmAttributes 5
Transfer Type Isochronous
Synch Type Asynchronous
Usage Type Data
wMaxPacketSize 0x0064 1x 100 bytes
bInterval 4
bRefresh 0
bSynchAddress 0
bMaxBurst 0
AudioStreaming Endpoint Descriptor:
bLength 7
bDescriptorType 37
bDescriptorSubtype 1 (EP_GENERAL)
bmAttributes 0x01
Sampling Frequency
bLockDelayUnits 0 Undefined
wLockDelay 0x0000
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 3
bAlternateSetting 4
bNumEndpoints 1
bInterfaceClass 1 Audio
bInterfaceSubClass 2 Streaming
bInterfaceProtocol 0
iInterface 0
AudioStreaming Interface Descriptor:
bLength 7
bDescriptorType 36
bDescriptorSubtype 1 (AS_GENERAL)
bTerminalLink 3
bDelay 2 frames
wFormatTag 0x0001 PCM
AudioStreaming Interface Descriptor:
bLength 11
bDescriptorType 36
bDescriptorSubtype 2 (FORMAT_TYPE)
bFormatType 1 (FORMAT_TYPE_I)
bNrChannels 2
bSubframeSize 2
bBitResolution 16
bSamFreqType 1 Discrete
tSamFreq[ 0] 32000
Endpoint Descriptor:
bLength 9
bDescriptorType 5
bEndpointAddress 0x82 EP 2 IN
bmAttributes 5
Transfer Type Isochronous
Synch Type Asynchronous
Usage Type Data
wMaxPacketSize 0x0084 1x 132 bytes
bInterval 4
bRefresh 0
bSynchAddress 0
bMaxBurst 0
AudioStreaming Endpoint Descriptor:
bLength 7
bDescriptorType 37
bDescriptorSubtype 1 (EP_GENERAL)
bmAttributes 0x01
Sampling Frequency
bLockDelayUnits 0 Undefined
wLockDelay 0x0000
Binary Object Store Descriptor:
bLength 5
bDescriptorType 15
wTotalLength 0x0016
bNumDeviceCaps 2
USB 2.0 Extension Device Capability:
bLength 7
bDescriptorType 16
bDevCapabilityType 2
bmAttributes 0x00000006
BESL Link Power Management (LPM) Supported
SuperSpeed USB Device Capability:
bLength 10
bDescriptorType 16
bDevCapabilityType 3
bmAttributes 0x00
wSpeedsSupported 0x000e
Device can operate at Full Speed (12Mbps)
Device can operate at High Speed (480Mbps)
Device can operate at SuperSpeed (5Gbps)
bFunctionalitySupport 2
Lowest fully-functional device speed is High Speed (480Mbps)
bU1DevExitLat 10 micro seconds
bU2DevExitLat 256 micro seconds
Device Status: 0x0000
(Bus Powered)
Signed-off-by: JP Hein <jp@jphein.com>
---
drivers/media/usb/uvc/uvc_driver.c | 16 ++++++++++++++++
1 file changed, 16 insertions(+)
diff --git a/drivers/media/usb/uvc/uvc_driver.c b/drivers/media/usb/uvc/uvc_driver.c
index 775bede..9b6df8e 100644
--- a/drivers/media/usb/uvc/uvc_driver.c
+++ b/drivers/media/usb/uvc/uvc_driver.c
@@ -2880,6 +2880,22 @@ static const struct usb_device_id uvc_ids[] = {
.bInterfaceSubClass = 1,
.bInterfaceProtocol = 0,
.driver_info = (kernel_ulong_t)&uvc_quirk_probe_minmax },
+
+ /*
+ * Razer Kiyo Pro -- firmware crashes under rapid control transfers
+ * and on LPM/autosuspend resume, cascading into xHCI controller
+ * death that disconnects all USB devices on the bus.
+ */
+ { .match_flags = USB_DEVICE_ID_MATCH_DEVICE
+ | USB_DEVICE_ID_MATCH_INT_INFO,
+ .idVendor = 0x1532,
+ .idProduct = 0x0e05,
+ .bInterfaceClass = USB_CLASS_VIDEO,
+ .bInterfaceSubClass = 1,
+ .bInterfaceProtocol = 0,
+ .driver_info = UVC_INFO_QUIRK(UVC_QUIRK_CTRL_THROTTLE
+ | UVC_QUIRK_DISABLE_AUTOSUSPEND
+ | UVC_QUIRK_NO_RESET_RESUME) },
/* Kurokesu C1 PRO */
{ .match_flags = USB_DEVICE_ID_MATCH_DEVICE
| USB_DEVICE_ID_MATCH_INT_INFO,
--
2.43.0
^ permalink raw reply related
* [PATCH v7 1/2] media: uvcvideo: add UVC_QUIRK_CTRL_THROTTLE for fragile USB firmware
From: JP Hein @ 2026-04-10 0:28 UTC (permalink / raw)
To: Laurent Pinchart, Hans de Goede, Greg Kroah-Hartman
Cc: linux-media, linux-usb, Ricardo Ribalda, Michal Pecio, JP Hein
In-Reply-To: <20260410002831.1046407-1-jp@jphein.com>
Some UVC devices have firmware that locks up under sustained rapid
USB control transfers, crashing the xHCI host controller and taking
all USB devices on the bus with it.
The Razer Kiyo Pro (1532:0e05) is the first known example: approximately
25 rapid consecutive control transfers cause the firmware to stall an
endpoint.
Add UVC_QUIRK_CTRL_THROTTLE which rate-limits all USB control transfers
to 50ms intervals in __uvc_query_ctrl(), the lowest-level UVC control
transfer function, ensuring all callers are throttled including
uvc_set_video_ctrl() which bypasses uvc_query_ctrl().
The 50ms interval was determined experimentally: the device is stable
at this rate under sustained operation, while shorter intervals
eventually trigger the firmware bug.
Signed-off-by: JP Hein <jp@jphein.com>
---
drivers/media/usb/uvc/uvc_video.c | 20 ++++++++++++++++++++
drivers/media/usb/uvc/uvcvideo.h | 3 +++
2 files changed, 23 insertions(+)
diff --git a/drivers/media/usb/uvc/uvc_video.c b/drivers/media/usb/uvc/uvc_video.c
index a5013a7..1d1206f 100644
--- a/drivers/media/usb/uvc/uvc_video.c
+++ b/drivers/media/usb/uvc/uvc_video.c
@@ -36,6 +36,26 @@ static int __uvc_query_ctrl(struct uvc_device *dev, u8 query, u8 unit,
u8 type = USB_TYPE_CLASS | USB_RECIP_INTERFACE;
unsigned int pipe;
+ /*
+ * Rate-limit control transfers for devices with fragile firmware.
+ * The Razer Kiyo Pro locks up under sustained rapid control
+ * transfers (hundreds without delay), crashing the xHCI controller.
+ * Throttle in this low-level function to cover all callers,
+ * including uvc_set_video_ctrl() which bypasses uvc_query_ctrl().
+ */
+ if (dev->quirks & UVC_QUIRK_CTRL_THROTTLE) {
+ unsigned long min_interval = msecs_to_jiffies(50);
+
+ if (dev->last_ctrl_jiffies &&
+ time_before(jiffies,
+ dev->last_ctrl_jiffies + min_interval)) {
+ unsigned long wait = dev->last_ctrl_jiffies +
+ min_interval - jiffies;
+ msleep(jiffies_to_msecs(wait));
+ }
+ dev->last_ctrl_jiffies = jiffies;
+ }
+
pipe = (query & 0x80) ? usb_rcvctrlpipe(dev->udev, 0)
: usb_sndctrlpipe(dev->udev, 0);
type |= (query & 0x80) ? USB_DIR_IN : USB_DIR_OUT;
diff --git a/drivers/media/usb/uvc/uvcvideo.h b/drivers/media/usb/uvc/uvcvideo.h
index 757254f..31f2af5 100644
--- a/drivers/media/usb/uvc/uvcvideo.h
+++ b/drivers/media/usb/uvc/uvcvideo.h
@@ -78,6 +78,7 @@
#define UVC_QUIRK_INVALID_DEVICE_SOF 0x00010000
#define UVC_QUIRK_MJPEG_NO_EOF 0x00020000
#define UVC_QUIRK_MSXU_META 0x00040000
+#define UVC_QUIRK_CTRL_THROTTLE 0x00080000
/* Format flags */
#define UVC_FMT_FLAG_COMPRESSED 0x00000001
@@ -583,6 +584,8 @@ struct uvc_device {
struct usb_interface *intf;
unsigned long warnings;
u32 quirks;
+ /* UVC control transfer throttling (UVC_QUIRK_CTRL_THROTTLE) */
+ unsigned long last_ctrl_jiffies;
int intfnum;
char name[32];
--
2.43.0
^ permalink raw reply related
* [PATCH v7 0/2] media: uvcvideo: Add quirks to prevent Razer Kiyo Pro xHCI cascade failure
From: JP Hein @ 2026-04-10 0:28 UTC (permalink / raw)
To: Laurent Pinchart, Hans de Goede, Greg Kroah-Hartman
Cc: linux-media, linux-usb, Ricardo Ribalda, Michal Pecio, JP Hein
In-Reply-To: <20260331003806.212565-1-jp@jphein.com>
The Razer Kiyo Pro (1532:0e05) is a USB 3.0 webcam whose firmware has a
well-documented failure mode that cascades into complete xHCI host
controller death, disconnecting every USB device on the bus -- including
keyboards and mice, requiring a hard reboot.
The device has two crash triggers:
1. LPM/autosuspend resume: Device enters LPM or autosuspend, fails to
reinitialize on resume, producing EPIPE (-32) on UVC SET_CUR. The
stalled endpoint triggers an xHCI stop-endpoint timeout, and the
kernel declares the host controller dead.
2. Rapid control transfers: sustained rapid UVC control operations
(hundreds over several seconds) overwhelm the firmware.
Patch 1 of the original 3-patch series (USB_QUIRK_NO_LPM for 1532:0e05)
has been merged by Greg Kroah-Hartman and backported to stable kernels
6.1, 6.6, 6.12, 6.18, and 6.19.
This v7 series covers the remaining two UVC patches:
Patch 1/2: UVC driver -- introduce UVC_QUIRK_CTRL_THROTTLE to rate-limit
all USB control transfers (50ms minimum interval) in __uvc_query_ctrl().
Patch 2/2: UVC driver -- add Razer Kiyo Pro device table entry with
UVC_QUIRK_CTRL_THROTTLE, UVC_QUIRK_DISABLE_AUTOSUSPEND, and
UVC_QUIRK_NO_RESET_RESUME.
Changes since v6:
- Dropped the error-code query skip after EPIPE -- no longer needed
since the throttle in __uvc_query_ctrl() already rate-limits the
error-code query path (Ricardo Ribalda)
- Included full lsusb -vv output in patch 2/2 commit message
(Ricardo Ribalda)
Changes since v5:
- Moved throttle from uvc_query_ctrl() to __uvc_query_ctrl() so
all callers are covered, including uvc_set_video_ctrl() which
bypasses the higher-level function (Ricardo Ribalda)
- Throttle now applies to all query types, not just SET_CUR
(Ricardo Ribalda)
Changes since v4:
- Dropped stable CC (new quirks, not regression fixes)
- Updated cover letter with 6.17 test results
Changes since v3:
- Regenerated patches against media-committers next branch to fix
context mismatch (v3 was based on Ubuntu 6.8 source)
Tested on:
- Kernel: 6.17.0-20-generic (Ubuntu 24.04 HWE) and 6.8.0-106-generic
- Hardware: Intel Cannon Lake PCH xHCI (8086:a36d)
- Device: Two Razer Kiyo Pro units (1532:0e05), firmware 1.5.0.1
Stress test, crash evidence, and debug logs:
https://github.com/jphein/kiyo-xhci-fix
JP Hein (2):
media: uvcvideo: add UVC_QUIRK_CTRL_THROTTLE for fragile USB firmware
media: uvcvideo: add Razer Kiyo Pro to device info table
drivers/media/usb/uvc/uvc_driver.c | 16 ++++++++++++++++
drivers/media/usb/uvc/uvc_video.c | 20 ++++++++++++++++++++
drivers/media/usb/uvc/uvcvideo.h | 3 +++
3 files changed, 39 insertions(+)
--
2.43.0
^ permalink raw reply
* Re: [PATCH v5 2/3] media: uvcvideo: add UVC_QUIRK_CTRL_THROTTLE for fragile firmware
From: Jeffrey Hein @ 2026-04-10 0:24 UTC (permalink / raw)
To: Michal Pecio
Cc: Ricardo Ribalda, Alan Stern, Laurent Pinchart, Hans de Goede,
Greg Kroah-Hartman, linux-media, linux-usb, stable
In-Reply-To: <CAD5VvzBQLGDrbrds=OrOOh5ptmVjP+nyq-jRHF5dCFzw+S6iQA@mail.gmail.com>
One more thing -- you mentioned referencing an lsusb from
linux-hardware.org for an "identical(?) device". Here is the actual
lsusb -vv from our device, confirming the wBytesPerInterval mismatch
you found.
EP5 IN (interrupt) from raw SS Endpoint Companion descriptor:
Endpoint Descriptor:
bEndpointAddress 0x85 EP 5 IN
bmAttributes 3 (Interrupt)
wMaxPacketSize 0x0040 1x 64 bytes
bInterval 8
SS Endpoint Companion:
bMaxBurst 0
bmAttributes 0x00
wBytesPerInterval 8
So wBytesPerInterval (8) is indeed 8x smaller than wMaxPacketSize (64),
matching what you saw in the third-party listing.
Note that lsusb -vv does not decode wBytesPerInterval for this
endpoint -- the value above was parsed from the raw descriptor bytes
in sysfs. The full lsusb -vv (934 lines) is now in the repo:
https://github.com/jphein/kiyo-xhci-fix/blob/main/kernel-patches/crash-evidence/lsusb-vv-kiyo-pro.txt
I will follow up with the test results from your patch.
JP
^ permalink raw reply
* Re: [PATCH v5 2/3] media: uvcvideo: add UVC_QUIRK_CTRL_THROTTLE for fragile firmware
From: Jeffrey Hein @ 2026-04-10 0:01 UTC (permalink / raw)
To: Michal Pecio
Cc: Ricardo Ribalda, Alan Stern, Laurent Pinchart, Hans de Goede,
Greg Kroah-Hartman, linux-media, linux-usb, stable
In-Reply-To: <20260409221749.5e6bccab.michal.pecio@gmail.com>
Hi Michal,
Thanks for the detailed analysis.
> crash-6.17-stock-stress-20260330.log
> Empty file, not sure why included at all.
Sorry about that -- removed.
> Not sure why usb_set_interface() is called. Is this the start
> streaming case mentioned in some email? What was happening before?
Yes, this is the start-streaming path. The app (Google Meet via
browser) opens the video device, which triggers usb_set_interface()
to select the alt setting for the isochronous endpoint. The LPM
disable failure happens during that transition.
> It's suspicious that wBytesPerInterval of the endpoint is 8,
> wMaxPacket is 64 and URBs are 16 bytes.
Interesting find. I had not looked at the interrupt endpoint
descriptors closely.
> Would it be possible to repeat this test with the patch below?
Absolutely. I will apply your patch, rebuild xhci-hcd, reproduce
the crash with dynamic debug enabled (xhci_hcd +p, usbcore +p),
only the Kiyo connected, and grab dmesg via SSH during the crash.
The CI bot flagged a dts-bindings failure on v6 but all code checks
(compile, smatch, sparse, checkpatch) passed -- unrelated to the
UVC patches.
Will follow up with traces.
Thanks,
JP
On Thu, Apr 9, 2026 at 1:17 PM Michal Pecio <michal.pecio@gmail.com> wrote:
>
> On Thu, 9 Apr 2026 10:02:47 +0200, Michal Pecio wrote:
> > On Thu, 9 Apr 2026 08:45:17 +0200, Ricardo Ribalda wrote:
> > > A usb device shall not be able crash the whole USB host. I believe
> > > that you already captured some logs and the USB guys are looking
> > > into it. I'd really like to hear what they have to say after
> > > reviewing them.
> >
> > Sorry, I forgot about this bug. I will take a closer look at logs
> > later today.
>
> lsusb -v of identical(?) device is found here:
> http://linux-hardware.org/?probe=a1cd74d9ac&log=lsusb
>
> And I'm looking at the logs here:
> https://github.com/jphein/kiyo-xhci-fix/tree/main/kernel-patches/crash-evidence
>
> crash-6.17-stock-stress-20260330.log
> Empty file, not sure why included at all.
>
> crash-6.17-video-call-20260330.log
> No debug messages. At some point:
> Mar 30 10:00:52 katana kernel: usb 2-3.4: disable of device-initiated U1 failed.
> Mar 30 10:00:53 katana kernel: usb 2-3.4: Failed to set U2 timeout to 0x0,error code -110
> Mar 30 10:00:53 katana kernel: uvcvideo 2-3.4:1.1: usb_set_interface Failed to disable LPM
> Mar 30 10:00:54 katana kernel: usb 2-3.4: Failed to query (SET_CUR) UVC control 11 on unit 3: -71 (exp. 1).
> Mar 30 10:00:54 katana kernel: usb 2-3.4: Failed to query (SET_CUR) UVC control 11 on unit 3: -71 (exp. 1).
> Mar 30 10:00:54 katana kernel: usb 2-3.4: Failed to query (SET_CUR) UVC control 11 on unit 3: -71 (exp. 1).
>
> Not sure if the LPM thing is the cause or a symptom of general EP 0
> disfunction, as seen in subsequent EPROTO errors.
>
> Not sure why usb_set_interface() is called. Is this the start streaming
> case mentioned in some email? What was happening before?
>
> stall-6.17-stock-no-workarounds-20260330.log
> All sorts of repeating errors, including stall on EP1IN ("ep 2") which
> is supposedly isochronous and shouldn't. Clearly some broken state, not
> sure how things got there.
>
> stall-6.17-stress-during-call-20260330.log
> This is the most interesting one.
>
> The first slightly unusual thing is repeated unlinks on EP5IN (int),
> not sure why uvcvideo would do that, possibly result of the stess test.
> I know that such pattern alone can break ASMedia host controllers for
> no reason I understand, though this one is Intel.
>
> It's suspicious that wBytesPerInterval of the endpoint is 8, wMaxPacket
> is 64 and URBs are 16 bytes. Just in case, I attach a test patch which
> rises wBytesPerInterval to match wMaxPacketSize.
>
> The first definite anomaly is Transaction Error on EP5IN:
> Mar 30 16:59:16 katana kernel: xhci_hcd 0000:00:14.0: Transfer error for slot 18 ep 10 on endpoint
> Mar 30 16:59:16 katana kernel: xhci_hcd 0000:00:14.0: Hard-reset ep 10, slot 18
>
> Not sure why endpoint reset follows immediately without retries.
> The test patch also removes one potential reason. We might see whether
> the retries will fail, or if retrying until the transfer succeeds
> magically prevents the subsequent disaster. Perhaps the device gets
> unusually upset about sequence mismatch on this endpoint, which results
> from not clearing this halt condition properly (known problem).
>
> Five seconds later two control URBs are unlinked:
> Mar 30 16:59:21 katana kernel: xhci_hcd 0000:00:14.0: Cancel URB 00000000122aa5e2, dev 3.1, ep 0x0, starting at offset 0x11e227b40
> Mar 30 16:59:21 katana kernel: xhci_hcd 0000:00:14.0: // Ding dong!
> Mar 30 16:59:21 katana kernel: xhci_hcd 0000:00:14.0: Cancel URB 000000008a55bcd3, dev 3.1, ep 0x0, starting at offset 0x11e227b20
> Mar 30 16:59:21 katana kernel: xhci_hcd 0000:00:14.0: Not queuing Stop Endpoint on slot 18 ep 0 in state 0x44
>
> Probably timeout, i.e. things got stuck. Oddly, state 0x44 indicates
> that this control endpoint has previously halted - error or stall.
>
> Higher layers notice that things are timing out:
>
> Mar 30 16:59:21 katana kernel: usb 2-3.1: pipewire timed out on ep0out len=0/0
> Mar 30 16:59:21 katana kernel: usb 2-3.1: disable of device-initiated U1 failed.
> Mar 30 16:59:21 katana kernel: usb 2-3.1: ThreadPoolSingl timed out on ep0out len=0/1
>
> Nothing works from now. At some point the parent hub reports
> disconnection and reconnection. Still nothing works.
>
> ---
>
> Would it be possible to repeat this test with the patch below?
> It overrides the suspicious wBytesPerInterval and hopefully enables
> retries of this failed interrupt URB. We will see what happens.
>
> xhci-mem.c b/drivers/usb/host/xhci-mem.c
> index 1d50c91afd7f..17d78b4e07bf 100644
> --- a/drivers/usb/host/xhci-mem.c
> +++ b/drivers/usb/host/xhci-mem.c
> @@ -1464,6 +1464,10 @@ int xhci_endpoint_init(struct xhci_hcd *xhci,
> mult = xhci_get_endpoint_mult(xhci, udev, ep);
> max_packet = xhci_usb_endpoint_maxp(udev, ep);
> max_burst = xhci_get_endpoint_max_burst(udev, ep);
> + if (interval && max_esit_payload < max_packet) {
> + xhci_err(xhci, "max_esit_payload %d -> %d\n", max_esit_payload, max_packet);
> + max_esit_payload = max_packet;
> + }
> avg_trb_len = max_esit_payload;
>
> /* FIXME dig Mult and streams info out of ep companion desc */
> diff --git a/drivers/usb/host/xhci-ring.c b/drivers/usb/host/xhci-ring.c
> index 98ef014c8dee..e5823650850a 100644
> --- a/drivers/usb/host/xhci-ring.c
> +++ b/drivers/usb/host/xhci-ring.c
> @@ -2544,6 +2544,7 @@ static void process_bulk_intr_td(struct xhci_hcd *xhci, struct xhci_virt_ep *ep,
> td->status = 0;
> break;
> case COMP_SHORT_PACKET:
> + ep->err_count = 0;
> td->status = 0;
> break;
> case COMP_STOPPED_SHORT_PACKET:
>
>
>
>
^ permalink raw reply
* [Bug 221318] mice behind ASMedia ASM1042A via Thunderbolt 2 never produce input, most likely due to interrupt pipe idle window during enumeration
From: bugzilla-daemon @ 2026-04-09 22:29 UTC (permalink / raw)
To: linux-usb
In-Reply-To: <bug-221318-208809@https.bugzilla.kernel.org/>
https://bugzilla.kernel.org/show_bug.cgi?id=221318
--- Comment #21 from manauer.uel@gmail.com ---
I just tested at a second location. Same MacBook Pro 13" Early 2015 and same
ASMedia ASM1042A, but a different monitor (LG 34UC88-B instead of LG 34CB98-B)
and a different mouse (Logitech G403 Prodigy, 046d:c083, two interfaces both at
1ms). Same issue, same workaround fixes it.
Bus 003.Port 001: Dev 001, Class=root_hub, Driver=xhci_hcd/2p, 480M
|__ Port 001: Dev 002, If 0, Class=Hub, Driver=hub/4p, 480M
ID 043e:9a10 LG Electronics USA, Inc. 34UC88-B
|__ Port 003: Dev 003, If 0, Class=Hub, Driver=hub/4p, 480M
ID 2109:2813 VIA Labs, Inc. VL813 Hub
|__ Port 001: Dev 005, If 0, Class=Human Interface Device,
Driver=usbhid, 12M
ID 046d:c083 Logitech, Inc. G403 Prodigy Gaming Mouse
|__ Port 001: Dev 005, If 1, Class=Human Interface Device,
Driver=usbhid, 12M
ID 046d:c083 Logitech, Inc. G403 Prodigy Gaming Mouse
Interface 0: bInterfaceProtocol Mouse, EP 0x81 IN, bInterval 1
Interface 1: bInterfaceProtocol 0, EP 0x82 IN, bInterval 1
I also plugged in a no-name mouse (China Resource Semico, 1a2c:0043, one
interface at 10ms) and it works fine without any workaround. Same controller,
same hub chain. The 10ms vs 1ms pattern holds here too.
Interface 0: bInterfaceProtocol Mouse, EP 0x81 IN, bInterval 10
I also noticed that all mice work in the OpenCore bootloader, same as on macOS
and Windows. OpenCore uses the EFI USB stack, which presumably keeps the
interrupt pipe active without idle logic. This fits the theory that the problem
is not necessarily in the ASM1042A hardware alone or in usbhid alone, but in
the combination of those two.
--
You may reply to this email to add a comment.
You are receiving this mail because:
You are watching the assignee of the bug.
^ permalink raw reply
* [Bug 221340] uas driver hangs and causes usb reset
From: bugzilla-daemon @ 2026-04-09 21:43 UTC (permalink / raw)
To: linux-usb
In-Reply-To: <bug-221340-208809@https.bugzilla.kernel.org/>
https://bugzilla.kernel.org/show_bug.cgi?id=221340
--- Comment #2 from DaisyTheFoxxo@proton.me ---
Appears to be the case, yes
--
You may reply to this email to add a comment.
You are receiving this mail because:
You are watching the assignee of the bug.
^ permalink raw reply
* [Bug 221340] uas driver hangs and causes usb reset
From: bugzilla-daemon @ 2026-04-09 21:24 UTC (permalink / raw)
To: linux-usb
In-Reply-To: <bug-221340-208809@https.bugzilla.kernel.org/>
https://bugzilla.kernel.org/show_bug.cgi?id=221340
Oliver Neukum (oliver@neukum.org) changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |oliver@neukum.org
--- Comment #1 from Oliver Neukum (oliver@neukum.org) ---
Are all errors due to READ_10 and WRITE_10?
--
You may reply to this email to add a comment.
You are receiving this mail because:
You are watching the assignee of the bug.
^ permalink raw reply
* [Bug 221340] New: uas driver hangs and causes usb reset
From: bugzilla-daemon @ 2026-04-09 20:56 UTC (permalink / raw)
To: linux-usb
https://bugzilla.kernel.org/show_bug.cgi?id=221340
Bug ID: 221340
Summary: uas driver hangs and causes usb reset
Product: Drivers
Version: 2.5
Kernel Version: v6.19.11-arch1-1
Hardware: All
OS: Linux
Status: NEW
Severity: normal
Priority: P3
Component: USB
Assignee: drivers_usb@kernel-bugs.kernel.org
Reporter: DaisyTheFoxxo@proton.me
Regression: No
Created attachment 309850
--> https://bugzilla.kernel.org/attachment.cgi?id=309850&action=edit
Linux Kernel log
The driver has been isolated to uas, usb-storage driver works without issue.
Happens more often the more load there is on the drive.
I am not aware of any duplicate bug reports.
--
You may reply to this email to add a comment.
You are receiving this mail because:
You are watching the assignee of the bug.
^ permalink raw reply
* Re: [PATCH v5 2/3] media: uvcvideo: add UVC_QUIRK_CTRL_THROTTLE for fragile firmware
From: Michal Pecio @ 2026-04-09 20:17 UTC (permalink / raw)
To: Ricardo Ribalda
Cc: JP Hein, Alan Stern, Laurent Pinchart, Hans de Goede,
Greg Kroah-Hartman, linux-media, linux-usb, stable
In-Reply-To: <20260409100247.7cfb62d1.michal.pecio@gmail.com>
On Thu, 9 Apr 2026 10:02:47 +0200, Michal Pecio wrote:
> On Thu, 9 Apr 2026 08:45:17 +0200, Ricardo Ribalda wrote:
> > A usb device shall not be able crash the whole USB host. I believe
> > that you already captured some logs and the USB guys are looking
> > into it. I'd really like to hear what they have to say after
> > reviewing them.
>
> Sorry, I forgot about this bug. I will take a closer look at logs
> later today.
lsusb -v of identical(?) device is found here:
http://linux-hardware.org/?probe=a1cd74d9ac&log=lsusb
And I'm looking at the logs here:
https://github.com/jphein/kiyo-xhci-fix/tree/main/kernel-patches/crash-evidence
crash-6.17-stock-stress-20260330.log
Empty file, not sure why included at all.
crash-6.17-video-call-20260330.log
No debug messages. At some point:
Mar 30 10:00:52 katana kernel: usb 2-3.4: disable of device-initiated U1 failed.
Mar 30 10:00:53 katana kernel: usb 2-3.4: Failed to set U2 timeout to 0x0,error code -110
Mar 30 10:00:53 katana kernel: uvcvideo 2-3.4:1.1: usb_set_interface Failed to disable LPM
Mar 30 10:00:54 katana kernel: usb 2-3.4: Failed to query (SET_CUR) UVC control 11 on unit 3: -71 (exp. 1).
Mar 30 10:00:54 katana kernel: usb 2-3.4: Failed to query (SET_CUR) UVC control 11 on unit 3: -71 (exp. 1).
Mar 30 10:00:54 katana kernel: usb 2-3.4: Failed to query (SET_CUR) UVC control 11 on unit 3: -71 (exp. 1).
Not sure if the LPM thing is the cause or a symptom of general EP 0
disfunction, as seen in subsequent EPROTO errors.
Not sure why usb_set_interface() is called. Is this the start streaming
case mentioned in some email? What was happening before?
stall-6.17-stock-no-workarounds-20260330.log
All sorts of repeating errors, including stall on EP1IN ("ep 2") which
is supposedly isochronous and shouldn't. Clearly some broken state, not
sure how things got there.
stall-6.17-stress-during-call-20260330.log
This is the most interesting one.
The first slightly unusual thing is repeated unlinks on EP5IN (int),
not sure why uvcvideo would do that, possibly result of the stess test.
I know that such pattern alone can break ASMedia host controllers for
no reason I understand, though this one is Intel.
It's suspicious that wBytesPerInterval of the endpoint is 8, wMaxPacket
is 64 and URBs are 16 bytes. Just in case, I attach a test patch which
rises wBytesPerInterval to match wMaxPacketSize.
The first definite anomaly is Transaction Error on EP5IN:
Mar 30 16:59:16 katana kernel: xhci_hcd 0000:00:14.0: Transfer error for slot 18 ep 10 on endpoint
Mar 30 16:59:16 katana kernel: xhci_hcd 0000:00:14.0: Hard-reset ep 10, slot 18
Not sure why endpoint reset follows immediately without retries.
The test patch also removes one potential reason. We might see whether
the retries will fail, or if retrying until the transfer succeeds
magically prevents the subsequent disaster. Perhaps the device gets
unusually upset about sequence mismatch on this endpoint, which results
from not clearing this halt condition properly (known problem).
Five seconds later two control URBs are unlinked:
Mar 30 16:59:21 katana kernel: xhci_hcd 0000:00:14.0: Cancel URB 00000000122aa5e2, dev 3.1, ep 0x0, starting at offset 0x11e227b40
Mar 30 16:59:21 katana kernel: xhci_hcd 0000:00:14.0: // Ding dong!
Mar 30 16:59:21 katana kernel: xhci_hcd 0000:00:14.0: Cancel URB 000000008a55bcd3, dev 3.1, ep 0x0, starting at offset 0x11e227b20
Mar 30 16:59:21 katana kernel: xhci_hcd 0000:00:14.0: Not queuing Stop Endpoint on slot 18 ep 0 in state 0x44
Probably timeout, i.e. things got stuck. Oddly, state 0x44 indicates
that this control endpoint has previously halted - error or stall.
Higher layers notice that things are timing out:
Mar 30 16:59:21 katana kernel: usb 2-3.1: pipewire timed out on ep0out len=0/0
Mar 30 16:59:21 katana kernel: usb 2-3.1: disable of device-initiated U1 failed.
Mar 30 16:59:21 katana kernel: usb 2-3.1: ThreadPoolSingl timed out on ep0out len=0/1
Nothing works from now. At some point the parent hub reports
disconnection and reconnection. Still nothing works.
---
Would it be possible to repeat this test with the patch below?
It overrides the suspicious wBytesPerInterval and hopefully enables
retries of this failed interrupt URB. We will see what happens.
xhci-mem.c b/drivers/usb/host/xhci-mem.c
index 1d50c91afd7f..17d78b4e07bf 100644
--- a/drivers/usb/host/xhci-mem.c
+++ b/drivers/usb/host/xhci-mem.c
@@ -1464,6 +1464,10 @@ int xhci_endpoint_init(struct xhci_hcd *xhci,
mult = xhci_get_endpoint_mult(xhci, udev, ep);
max_packet = xhci_usb_endpoint_maxp(udev, ep);
max_burst = xhci_get_endpoint_max_burst(udev, ep);
+ if (interval && max_esit_payload < max_packet) {
+ xhci_err(xhci, "max_esit_payload %d -> %d\n", max_esit_payload, max_packet);
+ max_esit_payload = max_packet;
+ }
avg_trb_len = max_esit_payload;
/* FIXME dig Mult and streams info out of ep companion desc */
diff --git a/drivers/usb/host/xhci-ring.c b/drivers/usb/host/xhci-ring.c
index 98ef014c8dee..e5823650850a 100644
--- a/drivers/usb/host/xhci-ring.c
+++ b/drivers/usb/host/xhci-ring.c
@@ -2544,6 +2544,7 @@ static void process_bulk_intr_td(struct xhci_hcd *xhci, struct xhci_virt_ep *ep,
td->status = 0;
break;
case COMP_SHORT_PACKET:
+ ep->err_count = 0;
td->status = 0;
break;
case COMP_STOPPED_SHORT_PACKET:
^ permalink raw reply related
* Re: [PATCH 00/61] treewide: Use IS_ERR_OR_NULL over manual NULL check - refactor
From: Al Viro @ 2026-04-09 18:16 UTC (permalink / raw)
To: Philipp Hahn
Cc: amd-gfx, apparmor, bpf, ceph-devel, cocci, dm-devel, dri-devel,
gfs2, intel-gfx, intel-wired-lan, iommu, kvm, linux-arm-kernel,
linux-block, linux-bluetooth, linux-btrfs, linux-cifs, linux-clk,
linux-erofs, linux-ext4, linux-fsdevel, linux-gpio, linux-hyperv,
linux-input, linux-kernel, linux-leds, linux-media, linux-mips,
linux-mm, linux-modules, linux-mtd, linux-nfs, linux-omap,
linux-phy, linux-pm, linux-rockchip, linux-s390, linux-scsi,
linux-sctp, linux-security-module, linux-sh, linux-sound,
linux-stm32, linux-trace-kernel, linux-usb, linux-wireless,
netdev, ntfs3, samba-technical, sched-ext, target-devel,
tipc-discussion, v9fs, Julia Lawall, Nicolas Palix, Chris Mason,
David Sterba, Ilya Dryomov, Alex Markuze, Viacheslav Dubeyko,
Theodore Ts'o, Andreas Dilger, Steve French, Paulo Alcantara,
Ronnie Sahlberg, Shyam Prasad N, Tom Talpey, Bharath SM,
Eric Van Hensbergen, Latchesar Ionkov, Dominique Martinet,
Christian Schoenebeck, Gao Xiang, Chao Yu, Yue Hu, Jeffle Xu,
Sandeep Dhavale, Hongbo Li, Chunhai Guo, Miklos Szeredi,
Konstantin Komarov, Andreas Gruenbacher, Kees Cook, Tony Luck,
Guilherme G. Piccoli, Jan Kara, Phillip Lougher,
Christian Brauner, Jan Kara, Steven Rostedt, Masami Hiramatsu,
Mathieu Desnoyers, Tejun Heo, David Vernet, Andrea Righi,
Changwoo Min, Ingo Molnar, Peter Zijlstra, Juri Lelli,
Vincent Guittot, Dietmar Eggemann, Ben Segall, Mel Gorman,
Valentin Schneider, Luis Chamberlain, Petr Pavlu, Daniel Gomez,
Sami Tolvanen, Aaron Tomlin, Sylwester Nawrocki, Liam Girdwood,
Mark Brown, Jaroslav Kysela, Takashi Iwai, Max Filippov,
Paolo Bonzini, John Johansen, Paul Moore, James Morris,
Serge E. Hallyn, Andrew Morton, Alasdair Kergon, Mike Snitzer,
Mikulas Patocka, Benjamin Marzinski, David S. Miller, David Ahern,
Eric Dumazet, Jakub Kicinski, Paolo Abeni, Simon Horman,
Marcel Holtmann, Johan Hedberg, Luiz Augusto von Dentz,
Alexei Starovoitov, Daniel Borkmann, Jesper Dangaard Brouer,
John Fastabend, Stanislav Fomichev, Jamal Hadi Salim, Jiri Pirko,
Marcelo Ricardo Leitner, Xin Long, Trond Myklebust,
Anna Schumaker, Chuck Lever, Jeff Layton, NeilBrown,
Olga Kornievskaia, Dai Ngo, Jon Maloy, Johannes Berg,
Catalin Marinas, Russell King, John Crispin, Thomas Bogendoerfer,
Yoshinori Sato, Rich Felker, John Paul Adrian Glaubitz,
Andrzej Hajda, Neil Armstrong, Robert Foss, Laurent Pinchart,
Jonas Karlman, Jernej Skrabec, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, David Airlie, Simona Vetter, Zhenyu Wang,
Zhi Wang, Jani Nikula, Joonas Lahtinen, Rodrigo Vivi,
Tvrtko Ursulin, Alex Deucher, Christian König, Sandy Huang,
Heiko Stübner, Andy Yan, Igor Russkikh, Andrew Lunn,
Pavan Chebbi, Michael Chan, Potnuri Bharat Teja, Tony Nguyen,
Przemek Kitszel, Taras Chornyi, Maxime Coquelin, Alexandre Torgue,
Iyappan Subramanian, Keyur Chudgar, Quan Nguyen, Heiner Kallweit,
Marc Zyngier, Thomas Gleixner, Andrew Lunn, Gregory Clement,
Sebastian Hesselbarth, Vinod Koul, Linus Walleij, Ulf Hansson,
Heiko Carstens, Vasily Gorbik, Alexander Gordeev,
Christian Borntraeger, Sven Schnelle, Martin K. Petersen,
Eduardo Valentin, Keerthy, Rafael J. Wysocki, Daniel Lezcano,
Zhang Rui, Lukasz Luba, Alex Williamson, Mark Greer,
Miquel Raynal, Richard Weinberger, Vignesh Raghavendra,
Shuah Khan, Kieran Bingham, Mauro Carvalho Chehab, Joerg Roedel,
Will Deacon, Robin Murphy, Lee Jones, Pavel Machek, Dave Penkler,
K. Y. Srinivasan, Haiyang Zhang, Wei Liu, Dexuan Cui, Long Li,
Justin Sanders, Jens Axboe, Georgi Djakov, Michael Turquette,
Stephen Boyd, Philipp Zabel, Borislav Petkov, Dave Hansen, x86,
H. Peter Anvin, Pali Rohár, Dmitry Torokhov
In-Reply-To: <20260310-b4-is_err_or_null-v1-0-bd63b656022d@avm.de>
On Tue, Mar 10, 2026 at 12:48:26PM +0100, Philipp Hahn wrote:
> While doing some static code analysis I stumbled over a common pattern,
> where IS_ERR() is combined with a NULL check. For that there is
> IS_ERR_OR_NULL().
... and valid uses of IS_ERR_OR_NULL are rare as hen teeth.
Most of those are "I'm not sure how this function returns an
error, let's use that just in case".
Please, do not introduce more of that crap.
^ permalink raw reply
* Re: [PATCH v4] usbip: tools: add hint when no exported devices are found
From: Shuah Khan @ 2026-04-09 17:25 UTC (permalink / raw)
To: Zongmin Zhou, gregkh
Cc: i, linux-kernel, linux-usb, valentina.manea.m, Zongmin Zhou,
Shuah Khan
In-Reply-To: <20260402083204.53179-1-min_halo@163.com>
On 4/2/26 02:32, Zongmin Zhou wrote:
> From: Zongmin Zhou <zhouzongmin@kylinos.cn>
>
> When refresh_exported_devices() finds no devices, it's helpful to
> inform users about potential causes. This could be due to:
>
> 1. The usbip driver module is not loaded.
> 2. No devices have been exported yet.
>
> Add an informational message to guide users when ndevs == 0.
>
> Also update the condition in usbip_host_driver_open() and
> usbip_device_driver_open() to check both ret and ndevs == 0,
> and change err() to info().
>
> Message visibility by scenario:
> - usbipd (console mode): Show on console/serial, this allows instant
> visibility for debugging.
> - usbipd -D (daemon mode): Message logged to syslog, can keep logs for
> later traceability in production. Also can use "journalctl -f" to
> trace on console.
>
> Suggested-by: Shuah Khan <skhan@linuxfoundation.org>
> Signed-off-by: Zongmin Zhou <zhouzongmin@kylinos.cn>
> ---
> Changes in v4:
> - Printing behavior adjusted as suggested.
Reviewed-by: Shuah Khan <skhan@linuxfoundation.org>
Greg, Please pick this up.
thanks,
-- Shuah
^ permalink raw reply
* Re: [PATCH] HID: usbhid: refactor endpoint lookup
From: Jiri Kosina @ 2026-04-09 15:58 UTC (permalink / raw)
To: Johan Hovold; +Cc: Benjamin Tissoires, linux-usb, linux-input, linux-kernel
In-Reply-To: <20260330095034.1662231-1-johan@kernel.org>
On Mon, 30 Mar 2026, Johan Hovold wrote:
> Use the common USB helper for looking up interrupt-in endpoints instead
> of open coding.
Good catch, thanks Johan. Now applied to hid.git#for-7.1/core-v2.
--
Jiri Kosina
SUSE Labs
^ permalink raw reply
* Re: [PATCH] hid: usbhid: fix deadlock in hid_post_reset()
From: Jiri Kosina @ 2026-04-09 15:48 UTC (permalink / raw)
To: Oliver Neukum; +Cc: bentiss, linux-input, linux-usb
In-Reply-To: <036cb81b-ae6e-4dcd-8f97-593e754279d1@suse.com>
On Mon, 30 Mar 2026, Oliver Neukum wrote:
> > Did you find this just by code inspection, or was this reported with a
> > real device?
>
> Pure inspection. We are looking at USB error handling
> in general right now.
OK, thanks. Now queued in hid.git.
--
Jiri Kosina
SUSE Labs
^ permalink raw reply
* Re: [PATCH v1 1/2] dt-bindings: usb: dwc3: add support for StarFive JHB100
From: Conor Dooley @ 2026-04-09 15:37 UTC (permalink / raw)
To: Minda Chen
Cc: Greg Kroah-Hartman, Thinh Nguyen, Rob Herring,
Krzysztof Kozlowski, linux-usb, linux-kernel, devicetree
In-Reply-To: <20260409101227.39417-2-minda.chen@starfivetech.com>
[-- Attachment #1: Type: text/plain, Size: 75 bytes --]
Acked-by: Conor Dooley <conor.dooley@microchip.com>
pw-bot: not-applicable
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* [PATCH] drivers/usb/host: Fix spelling error 'seperate' -> 'separate'
From: Qinghua Zhao @ 2026-04-09 14:54 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, Mathias Nyman, linux-usb, Qinghua Zhao
Fix typo in comment where 'seperate' should be 'separate'.
Signed-off-by: Qinghua Zhao <zqh1630@126.com>
---
drivers/usb/host/xhci-mvebu.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/usb/host/xhci-mvebu.c b/drivers/usb/host/xhci-mvebu.c
index 257e4d799..f91c5004f 100644
--- a/drivers/usb/host/xhci-mvebu.c
+++ b/drivers/usb/host/xhci-mvebu.c
@@ -30,7 +30,7 @@ static void xhci_mvebu_mbus_config(void __iomem *base,
writel(0, base + USB3_WIN_BASE(win));
}
- /* Program each DRAM CS in a seperate window */
+ /* Program each DRAM CS in a separate window */
for (win = 0; win < dram->num_cs; win++) {
const struct mbus_dram_window *cs = &dram->cs[win];
--
2.40.1
^ permalink raw reply related
* Re: [PATCH] thunderbolt: debugfs: Don't stop reading SB registers if just one fails
From: Mika Westerberg @ 2026-04-09 14:32 UTC (permalink / raw)
To: Konrad Dybcio
Cc: Konrad Dybcio, Andreas Noever, Mika Westerberg, Yehezkel Bernat,
usb4-upstream, linux-usb, linux-kernel
In-Reply-To: <75c962d1-7ade-483b-bbc9-a6c6140fc0e9@oss.qualcomm.com>
On Thu, Apr 09, 2026 at 02:59:22PM +0200, Konrad Dybcio wrote:
> On 4/9/26 2:04 PM, Mika Westerberg wrote:
> > Hi,
> >
> > On Thu, Apr 09, 2026 at 01:22:01PM +0200, Konrad Dybcio wrote:
> >> From: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
> >>
> >> The GEN4 TxFFE register is not part of the USB4 v1.0 specification, so
> >> understandably some pre-USB4v2 retimers (like the Parade PS8830) don't
> >> seem to implement it.
> >>
> >> The immediate idea to counter this would be to introduce a version
> >> check for that specific register, but on a second thought, the current
> >> flow only returns a quiet -EIO if there's _any_ failures, without
> >> hinting at what the actual problem is.
> >
> > Please don't use _any_ emphasis in the commit messages here or in the
> > future.
>
> If I must, I shall.. other maintainers don't mind.
I do. We are professionals, let's keep the commit logs as such, not rants.
> >> To take care of both of these issues, simply print an error line for
> >> each SB register read that fails and go on with attempting to read the
> >> others.
> >>
> >> Note that this is not quite in-spec behavior ("The SB Register Space
> >> registers shall have the structure and fields described in Table 4-17.
> >> Registers not listed in Table 4-20 are undefined and shall not be
> >> used."), but it's the easiest fix that shouldn't (TM) have real-world
> >> bad side effects.
> >
> > Also drop the "(TM)" thing.
> >
> > I assume you have tested this on a hardware that supports this too, right?
>
> Hardware that exposes that register this does not exercise the altered
> code path.
Well it may happen now that previously we got -EIO from some other register
and we stopped there, now this changes and we actually continue reading so
this definitely should be tested.
> >> Fixes: 6d241fa00159 ("thunderbolt: Add sideband register access to debugfs")
> >> Signed-off-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
> >> ---
> >> drivers/thunderbolt/debugfs.c | 6 ++++--
> >> 1 file changed, 4 insertions(+), 2 deletions(-)
> >>
> >> diff --git a/drivers/thunderbolt/debugfs.c b/drivers/thunderbolt/debugfs.c
> >> index 042f6a0d0f7f..8237e1ea6d09 100644
> >> --- a/drivers/thunderbolt/debugfs.c
> >> +++ b/drivers/thunderbolt/debugfs.c
> >> @@ -2361,8 +2361,10 @@ static int sb_regs_show(struct tb_port *port, const struct sb_reg *sb_regs,
> >> memset(data, 0, sizeof(data));
> >> ret = usb4_port_sb_read(port, target, index, regs->reg, data,
> >> regs->size);
> >> - if (ret)
> >> - return ret;
> >> + if (ret) {
> >> + seq_printf(s, "0x%02x Error reading register: %d\n", regs->reg, ret);
> >
> > Why not tb_port_dgb/warn()() here instead so it goes into dmesg, not to the
> > output.
>
> Because when one reads out sys/debugfs, it's generally expected that the
> related output is provided there.
>
> If we don't want to print the retval, I can copy the message that's printed
> when switch/port capabilities readout fails, i.e.
>
> -- drivers/thunderbolt/debugfs.c : cap_show_by_dw()
> if (port)
> ret = tb_port_read(port, &data, TB_CFG_PORT, cap + offset + i, 1);
> else
> ret = tb_sw_read(sw, &data, TB_CFG_SWITCH, cap + offset + i, 1);
> if (ret) {
> seq_printf(s, "0x%04x <not accessible>\n", cap + offset + i);
> continue;
Yes this is better.
^ permalink raw reply
* Re: [PATCH] thunderbolt: debugfs: Don't stop reading SB registers if just one fails
From: Konrad Dybcio @ 2026-04-09 12:59 UTC (permalink / raw)
To: Mika Westerberg, Konrad Dybcio
Cc: Andreas Noever, Mika Westerberg, Yehezkel Bernat, usb4-upstream,
linux-usb, linux-kernel
In-Reply-To: <20260409120457.GH3552@black.igk.intel.com>
On 4/9/26 2:04 PM, Mika Westerberg wrote:
> Hi,
>
> On Thu, Apr 09, 2026 at 01:22:01PM +0200, Konrad Dybcio wrote:
>> From: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
>>
>> The GEN4 TxFFE register is not part of the USB4 v1.0 specification, so
>> understandably some pre-USB4v2 retimers (like the Parade PS8830) don't
>> seem to implement it.
>>
>> The immediate idea to counter this would be to introduce a version
>> check for that specific register, but on a second thought, the current
>> flow only returns a quiet -EIO if there's _any_ failures, without
>> hinting at what the actual problem is.
>
> Please don't use _any_ emphasis in the commit messages here or in the
> future.
If I must, I shall.. other maintainers don't mind.
>> To take care of both of these issues, simply print an error line for
>> each SB register read that fails and go on with attempting to read the
>> others.
>>
>> Note that this is not quite in-spec behavior ("The SB Register Space
>> registers shall have the structure and fields described in Table 4-17.
>> Registers not listed in Table 4-20 are undefined and shall not be
>> used."), but it's the easiest fix that shouldn't (TM) have real-world
>> bad side effects.
>
> Also drop the "(TM)" thing.
>
> I assume you have tested this on a hardware that supports this too, right?
Hardware that exposes that register this does not exercise the altered
code path.
>> Fixes: 6d241fa00159 ("thunderbolt: Add sideband register access to debugfs")
>> Signed-off-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
>> ---
>> drivers/thunderbolt/debugfs.c | 6 ++++--
>> 1 file changed, 4 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/thunderbolt/debugfs.c b/drivers/thunderbolt/debugfs.c
>> index 042f6a0d0f7f..8237e1ea6d09 100644
>> --- a/drivers/thunderbolt/debugfs.c
>> +++ b/drivers/thunderbolt/debugfs.c
>> @@ -2361,8 +2361,10 @@ static int sb_regs_show(struct tb_port *port, const struct sb_reg *sb_regs,
>> memset(data, 0, sizeof(data));
>> ret = usb4_port_sb_read(port, target, index, regs->reg, data,
>> regs->size);
>> - if (ret)
>> - return ret;
>> + if (ret) {
>> + seq_printf(s, "0x%02x Error reading register: %d\n", regs->reg, ret);
>
> Why not tb_port_dgb/warn()() here instead so it goes into dmesg, not to the
> output.
Because when one reads out sys/debugfs, it's generally expected that the
related output is provided there.
If we don't want to print the retval, I can copy the message that's printed
when switch/port capabilities readout fails, i.e.
-- drivers/thunderbolt/debugfs.c : cap_show_by_dw()
if (port)
ret = tb_port_read(port, &data, TB_CFG_PORT, cap + offset + i, 1);
else
ret = tb_sw_read(sw, &data, TB_CFG_SWITCH, cap + offset + i, 1);
if (ret) {
seq_printf(s, "0x%04x <not accessible>\n", cap + offset + i);
continue;
}
Konrad
^ permalink raw reply
* Re: [PATCH] thunderbolt: debugfs: Don't stop reading SB registers if just one fails
From: Mika Westerberg @ 2026-04-09 12:04 UTC (permalink / raw)
To: Konrad Dybcio
Cc: Andreas Noever, Mika Westerberg, Yehezkel Bernat, usb4-upstream,
linux-usb, linux-kernel, Konrad Dybcio
In-Reply-To: <20260409-topic-tbt_sb_debugfs-v1-1-131540e0cc2b@oss.qualcomm.com>
Hi,
On Thu, Apr 09, 2026 at 01:22:01PM +0200, Konrad Dybcio wrote:
> From: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
>
> The GEN4 TxFFE register is not part of the USB4 v1.0 specification, so
> understandably some pre-USB4v2 retimers (like the Parade PS8830) don't
> seem to implement it.
>
> The immediate idea to counter this would be to introduce a version
> check for that specific register, but on a second thought, the current
> flow only returns a quiet -EIO if there's _any_ failures, without
> hinting at what the actual problem is.
Please don't use _any_ emphasis in the commit messages here or in the
future.
> To take care of both of these issues, simply print an error line for
> each SB register read that fails and go on with attempting to read the
> others.
>
> Note that this is not quite in-spec behavior ("The SB Register Space
> registers shall have the structure and fields described in Table 4-17.
> Registers not listed in Table 4-20 are undefined and shall not be
> used."), but it's the easiest fix that shouldn't (TM) have real-world
> bad side effects.
Also drop the "(TM)" thing.
I assume you have tested this on a hardware that supports this too, right?
> Fixes: 6d241fa00159 ("thunderbolt: Add sideband register access to debugfs")
> Signed-off-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
> ---
> drivers/thunderbolt/debugfs.c | 6 ++++--
> 1 file changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/thunderbolt/debugfs.c b/drivers/thunderbolt/debugfs.c
> index 042f6a0d0f7f..8237e1ea6d09 100644
> --- a/drivers/thunderbolt/debugfs.c
> +++ b/drivers/thunderbolt/debugfs.c
> @@ -2361,8 +2361,10 @@ static int sb_regs_show(struct tb_port *port, const struct sb_reg *sb_regs,
> memset(data, 0, sizeof(data));
> ret = usb4_port_sb_read(port, target, index, regs->reg, data,
> regs->size);
> - if (ret)
> - return ret;
> + if (ret) {
> + seq_printf(s, "0x%02x Error reading register: %d\n", regs->reg, ret);
Why not tb_port_dgb/warn()() here instead so it goes into dmesg, not to the
output.
> + continue;
> + }
>
> seq_printf(s, "0x%02x", regs->reg);
> for (j = 0; j < regs->size; j++)
>
> ---
> base-commit: db7efce4ae23ad5e42f5f55428f529ff62b86fab
> change-id: 20260409-topic-tbt_sb_debugfs-2e500fee9706
>
> Best regards,
> --
> Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
^ permalink raw reply
* [PATCH RFT] usb: typec: mux: Mark mux/switch devices as 'PM not required'
From: Konrad Dybcio @ 2026-04-09 11:54 UTC (permalink / raw)
To: Heikki Krogerus, Greg Kroah-Hartman
Cc: linux-usb, linux-kernel, Konrad Dybcio
From: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
These are spawned as children of the device that normally represents
the chip/hw block providing Type-C functionality. They don't have PM
callbacks, so it makes no sense for them to be taken into account
there.
Signed-off-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
---
I saw no regressions, but such changes are always a little scary..
Sending as RFT
---
drivers/usb/typec/mux.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/drivers/usb/typec/mux.c b/drivers/usb/typec/mux.c
index db5e4a4c0a99..080252f202ec 100644
--- a/drivers/usb/typec/mux.c
+++ b/drivers/usb/typec/mux.c
@@ -199,6 +199,8 @@ typec_switch_register(struct device *parent,
return ERR_PTR(ret);
}
+ device_set_pm_not_required(&sw_dev->dev);
+
ret = device_add(&sw_dev->dev);
if (ret) {
dev_err(parent, "failed to register switch (%d)\n", ret);
@@ -454,6 +456,8 @@ typec_mux_register(struct device *parent, const struct typec_mux_desc *desc)
return ERR_PTR(ret);
}
+ device_set_pm_not_required(&mux_dev->dev);
+
ret = device_add(&mux_dev->dev);
if (ret) {
dev_err(parent, "failed to register mux (%d)\n", ret);
---
base-commit: db7efce4ae23ad5e42f5f55428f529ff62b86fab
change-id: 20260409-topic-usb_mux_nopm-0e52479160c6
Best regards,
--
Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
^ permalink raw reply related
* [PATCH] thunderbolt: debugfs: Don't stop reading SB registers if just one fails
From: Konrad Dybcio @ 2026-04-09 11:22 UTC (permalink / raw)
To: Andreas Noever, Mika Westerberg, Yehezkel Bernat
Cc: Mika Westerberg, usb4-upstream, linux-usb, linux-kernel,
Konrad Dybcio
From: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
The GEN4 TxFFE register is not part of the USB4 v1.0 specification, so
understandably some pre-USB4v2 retimers (like the Parade PS8830) don't
seem to implement it.
The immediate idea to counter this would be to introduce a version
check for that specific register, but on a second thought, the current
flow only returns a quiet -EIO if there's _any_ failures, without
hinting at what the actual problem is.
To take care of both of these issues, simply print an error line for
each SB register read that fails and go on with attempting to read the
others.
Note that this is not quite in-spec behavior ("The SB Register Space
registers shall have the structure and fields described in Table 4-17.
Registers not listed in Table 4-20 are undefined and shall not be
used."), but it's the easiest fix that shouldn't (TM) have real-world
bad side effects.
Fixes: 6d241fa00159 ("thunderbolt: Add sideband register access to debugfs")
Signed-off-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
---
drivers/thunderbolt/debugfs.c | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/thunderbolt/debugfs.c b/drivers/thunderbolt/debugfs.c
index 042f6a0d0f7f..8237e1ea6d09 100644
--- a/drivers/thunderbolt/debugfs.c
+++ b/drivers/thunderbolt/debugfs.c
@@ -2361,8 +2361,10 @@ static int sb_regs_show(struct tb_port *port, const struct sb_reg *sb_regs,
memset(data, 0, sizeof(data));
ret = usb4_port_sb_read(port, target, index, regs->reg, data,
regs->size);
- if (ret)
- return ret;
+ if (ret) {
+ seq_printf(s, "0x%02x Error reading register: %d\n", regs->reg, ret);
+ continue;
+ }
seq_printf(s, "0x%02x", regs->reg);
for (j = 0; j < regs->size; j++)
---
base-commit: db7efce4ae23ad5e42f5f55428f529ff62b86fab
change-id: 20260409-topic-tbt_sb_debugfs-2e500fee9706
Best regards,
--
Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
^ permalink raw reply related
* [Bug 221337] Regression: USB webcam (0bda:636e) fails to resume from suspend on 7.0.0-rc6
From: bugzilla-daemon @ 2026-04-09 11:20 UTC (permalink / raw)
To: linux-usb
In-Reply-To: <bug-221337-208809@https.bugzilla.kernel.org/>
https://bugzilla.kernel.org/show_bug.cgi?id=221337
The Linux kernel's regression tracker (Thorsten Leemhuis) (regressions@leemhuis.info) changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |regressions@leemhuis.info
--- Comment #1 from The Linux kernel's regression tracker (Thorsten Leemhuis) (regressions@leemhuis.info) ---
Could you bisect, as explained by
https://docs.kernel.org/admin-guide/verify-bugs-and-bisect-regressions.html ?
This most likely will be needed to find the people that can handle this and
verify that this is a upstream problem, too (as you afaics seem to be using a
vendor kernel).
--
You may reply to this email to add a comment.
You are receiving this mail because:
You are watching the assignee of the bug.
^ permalink raw reply
* Re: [PATCH net-next v7 2/2] r8152: Add support for the RTL8157 hardware
From: Birger Koblitz @ 2026-04-09 11:18 UTC (permalink / raw)
To: Paolo Abeni, Andrew Lunn, David S. Miller, Eric Dumazet,
Jakub Kicinski
Cc: linux-usb, netdev, linux-kernel, Chih Kai Hsu
In-Reply-To: <8b324f8c-f4f8-4e90-b5d6-9b87ec3daf2b@redhat.com>
On 09/04/2026 12:16, Paolo Abeni wrote:
> On 4/4/26 9:57 AM, Birger Koblitz wrote:
>> @@ -6534,8 +6842,11 @@ static void rtl8156_up(struct r8152 *tp)
>> ocp_word_clr_bits(tp, MCU_TYPE_PLA, PLA_MAC_PWR_CTRL3,
>> PLA_MCU_SPDWN_EN);
>>
>> - ocp_word_clr_bits(tp, MCU_TYPE_USB, USB_SPEED_OPTION,
>> - RG_PWRDN_EN | ALL_SPEED_OFF);
>> + ocp_word_clr_bits(tp, MCU_TYPE_PLA, PLA_MAC_PWR_CTRL3, PLA_MCU_SPDWN_EN);
>
> AI review notes that the above leads to 2 consecutive:
>
> ocp_word_clr_bits(tp, MCU_TYPE_PLA, PLA_MAC_PWR_CTRL3, PLA_MCU_SPDWN_EN);
>
> with slightly different formatting, likely C&P error?!?
>
> I think this is better handled with a follow-up, if needed, as I don't
> see any possible issue out of it.
>
> Other AI comments look not relevant.
Thanks a lot, Paolo!
I will follow up on this for sure, there is also the RTL8159...
I also contacted the Realtek devs, but have not heard back so far, probably needs
internal escalation...
Birger
^ permalink raw reply
* Re: [PATCH net-next v7 0/2] r8152: Add support for the RTL8157 5Gbit USB Ethernet chip
From: patchwork-bot+netdevbpf @ 2026-04-09 10:30 UTC (permalink / raw)
To: Birger Koblitz
Cc: andrew+netdev, davem, edumazet, kuba, pabeni, linux-usb, netdev,
linux-kernel, hsu.chih.kai
In-Reply-To: <20260404-rtl8157_next-v7-0-039121318f23@birger-koblitz.de>
Hello:
This series was applied to netdev/net-next.git (main)
by Paolo Abeni <pabeni@redhat.com>:
On Sat, 04 Apr 2026 09:57:41 +0200 you wrote:
> Add support for the RTL8157, which is a 5GBit USB-Ethernet adapter
> chip in the RTL815x family of chips.
>
> The RTL8157 uses a different frame descriptor format, and different
> SRAM/ADV access methods, plus offers 5GBit/s Ethernet, so support for these
> features is added in addition to chip initialization and configuration.
>
> [...]
Here is the summary with links:
- [net-next,v7,1/2] r8152: Add support for 5Gbit Link Speeds and EEE
https://git.kernel.org/netdev/net-next/c/ebe5fd2ed20a
- [net-next,v7,2/2] r8152: Add support for the RTL8157 hardware
https://git.kernel.org/netdev/net-next/c/fd3c7d080df5
You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html
^ permalink raw reply
* Re: [PATCH net-next v7 2/2] r8152: Add support for the RTL8157 hardware
From: Paolo Abeni @ 2026-04-09 10:16 UTC (permalink / raw)
To: Birger Koblitz, Andrew Lunn, David S. Miller, Eric Dumazet,
Jakub Kicinski
Cc: linux-usb, netdev, linux-kernel, Chih Kai Hsu
In-Reply-To: <20260404-rtl8157_next-v7-2-039121318f23@birger-koblitz.de>
On 4/4/26 9:57 AM, Birger Koblitz wrote:
> @@ -6534,8 +6842,11 @@ static void rtl8156_up(struct r8152 *tp)
> ocp_word_clr_bits(tp, MCU_TYPE_PLA, PLA_MAC_PWR_CTRL3,
> PLA_MCU_SPDWN_EN);
>
> - ocp_word_clr_bits(tp, MCU_TYPE_USB, USB_SPEED_OPTION,
> - RG_PWRDN_EN | ALL_SPEED_OFF);
> + ocp_word_clr_bits(tp, MCU_TYPE_PLA, PLA_MAC_PWR_CTRL3, PLA_MCU_SPDWN_EN);
AI review notes that the above leads to 2 consecutive:
ocp_word_clr_bits(tp, MCU_TYPE_PLA, PLA_MAC_PWR_CTRL3, PLA_MCU_SPDWN_EN);
with slightly different formatting, likely C&P error?!?
I think this is better handled with a follow-up, if needed, as I don't
see any possible issue out of it.
Other AI comments look not relevant.
/P
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox