[PATCH 0/3] USB/UVC: Add quirks to prevent Razer Kiyo Pro xHCI cascade failure

[PATCH 0/3] USB/UVC: Add quirks to prevent Razer Kiyo Pro xHCI cascade failure

[JP Hein]

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: ~25 rapid consecutive UVC SET_CUR
     operations overwhelm the firmware. The standard error-code query
     (GET_CUR on UVC_VC_REQUEST_ERROR_CODE_CONTROL) amplifies the
     failure by sending a second transfer to the already-stalling device,
     pushing it into a full lockup and xHCI controller death.

This has been reported as Ubuntu Launchpad Bug #2061177 and affects
multiple kernel versions (tested on 6.5.x through 6.8.x). There are
currently no device-specific quirks for this webcam in either the USB
core quirks table or the UVC driver device table.

This series adds three patches:

Patch 1: USB core — USB_QUIRK_NO_LPM to prevent Link Power Management
  transitions that destabilize the device firmware.

Patch 2: UVC driver — introduce UVC_QUIRK_CTRL_THROTTLE to rate-limit
  SET_CUR control transfers (50ms minimum interval) and skip the
  error-code query after EPIPE errors on affected devices.

Patch 3: UVC driver — add Razer Kiyo Pro device table entry with
  UVC_QUIRK_CTRL_THROTTLE, UVC_QUIRK_DISABLE_AUTOSUSPEND, and
  UVC_QUIRK_NO_RESET_RESUME to address both crash triggers.

Together, these keep the device in a stable active state, prevent rapid
control transfer crashes, and avoid the power management transitions
that trigger the firmware bug.

Tested on:
  - Kernel: 6.8.0-106-generic (Ubuntu 24.04)
  - Hardware: Intel Cannon Lake PCH xHCI (8086:a36d)
  - Device: Razer Kiyo Pro (1532:0e05), firmware 8.21
  - Stress test: 50 rounds of rapid UVC control changes, 0 failures

JP Hein (3):
  USB: core: add NO_LPM quirk for Razer Kiyo Pro webcam
  media: uvcvideo: add UVC_QUIRK_CTRL_THROTTLE for fragile firmware
  media: uvcvideo: add quirks for Razer Kiyo Pro webcam

 drivers/media/usb/uvc/uvc_driver.c | 16 ++++++++++++++++
 drivers/media/usb/uvc/uvc_video.c  | 33 +++++++++++++++++++++++++++++++++
 drivers/media/usb/uvc/uvcvideo.h   |  3 +++
 drivers/usb/core/quirks.c          |  2 ++
 4 files changed, 54 insertions(+)

[PATCH 1/3] USB: core: add NO_LPM quirk for Razer Kiyo Pro webcam

[JP Hein]

The Razer Kiyo Pro (1532:0e05) is a USB 3.0 UVC webcam whose firmware
does not handle USB Link Power Management transitions reliably. When LPM
is active, the device can enter a state where it fails to respond to
control transfers, producing EPIPE (-32) errors on UVC probe control
SET_CUR requests. In the worst case, the stalled endpoint triggers an
xHCI stop-endpoint command that times out, causing the host controller
to be declared dead and every USB device on the bus to be disconnected.

This has been reported as Ubuntu Launchpad Bug #2061177. The failure
mode is:

  1. UVC probe control SET_CUR returns -32 (EPIPE)
  2. xHCI host not responding to stop endpoint command
  3. xHCI host controller not responding, assume dead
  4. All USB devices on the affected xHCI controller disconnect

Disabling LPM prevents the firmware from entering the problematic low-
power states that precede the stall. This is the same approach used for
other webcams with similar firmware issues (e.g., Logitech, Realtek).

Cc: stable@vger.kernel.org
Link: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2061177
Signed-off-by: JP Hein <jp@jphein.com>
---
 drivers/usb/core/quirks.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/usb/core/quirks.c b/drivers/usb/core/quirks.c
index XXXXXXX..XXXXXXX 100644
--- a/drivers/usb/core/quirks.c
+++ b/drivers/usb/core/quirks.c
@@ -493,6 +493,8 @@ static const struct usb_device_id usb_quirk_list[] = {
 	/* Razer - Razer Blade Keyboard */
 	{ USB_DEVICE(0x1532, 0x0116), .driver_info =
 			USB_QUIRK_LINEAR_UFRAME_INTR_BINTERVAL },
+	/* Razer - Razer Kiyo Pro Webcam */
+	{ USB_DEVICE(0x1532, 0x0e05), .driver_info = USB_QUIRK_NO_LPM },

 	/* Lenovo ThinkPad OneLink+ Dock twin hub controllers (VIA Labs VL812) */
 	{ USB_DEVICE(0x17ef, 0x1018), .driver_info = USB_QUIRK_RESET_RESUME },
--
2.43.0

[PATCH 2/3] media: uvcvideo: add UVC_QUIRK_CTRL_THROTTLE for fragile firmware

[JP Hein]

Some USB webcams have firmware that crashes when it receives rapid
consecutive UVC control transfers (SET_CUR). The Razer Kiyo Pro
(1532:0e05) is one such device — after approximately 25 rapid control
changes, the device stops responding to USB control transfers entirely,
triggering an xHCI stop-endpoint command timeout that causes the host
controller to be declared dead, disconnecting every USB device on the
bus.

The failure is amplified by the standard UVC error-code query: when a
SET_CUR fails with EPIPE, the driver sends a second transfer (GET_CUR
on UVC_VC_REQUEST_ERROR_CODE_CONTROL) to read the UVC error code. On a
device that is already stalling, this second transfer pushes the
firmware into a full lockup.

Introduce UVC_QUIRK_CTRL_THROTTLE (0x00080000) to address both issues:

  - Enforce a minimum 50ms interval between SET_CUR control transfers,
    preventing the rapid-fire pattern that overwhelms the firmware.
    50ms allows up to 20 control changes per second, which is sufficient
    for interactive slider adjustments while keeping the device stable.

  - Skip the UVC_VC_REQUEST_ERROR_CODE_CONTROL query after EPIPE errors
    on devices with this quirk. EPIPE is returned directly without the
    follow-up query that would amplify the failure.

The UVC control path is serialized by ctrl_mutex, so last_ctrl_set_jiffies
does not require additional locking.

Cc: stable@vger.kernel.org
Signed-off-by: JP Hein <jp@jphein.com>
---
 drivers/media/usb/uvc/uvc_video.c | 33 +++++++++++++++++++++++++++++++++
 drivers/media/usb/uvc/uvcvideo.h  |  3 +++
 2 files changed, 36 insertions(+)

diff --git a/drivers/media/usb/uvc/uvcvideo.h b/drivers/media/usb/uvc/uvcvideo.h
index XXXXXXX..XXXXXXX 100644
--- a/drivers/media/usb/uvc/uvcvideo.h
+++ b/drivers/media/usb/uvc/uvcvideo.h
@@ -90,6 +90,7 @@
 #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
@@ -737,4 +738,6 @@ struct uvc_device {
 	unsigned long warnings;
 	u32 quirks;
+	/* Control transfer throttling (UVC_QUIRK_CTRL_THROTTLE) */
+	unsigned long last_ctrl_set_jiffies;
 	int intfnum;
 	char name[32];

diff --git a/drivers/media/usb/uvc/uvc_video.c b/drivers/media/usb/uvc/uvc_video.c
index XXXXXXX..XXXXXXX 100644
--- a/drivers/media/usb/uvc/uvc_video.c
+++ b/drivers/media/usb/uvc/uvc_video.c
@@ -71,10 +71,33 @@ int uvc_query_ctrl(struct uvc_device *dev, u8 query, u8 unit,
 		u8 intfnum, u8 cs, void *data, u16 size)
 {
 	int ret;
 	u8 error;
 	u8 tmp;

+	/*
+	 * Rate-limit SET_CUR operations for devices with fragile firmware.
+	 * The Razer Kiyo Pro locks up after ~25 rapid consecutive SET_CUR
+	 * transfers, ultimately crashing the xHCI host controller.
+	 */
+	if (query == UVC_SET_CUR &&
+	    (dev->quirks & UVC_QUIRK_CTRL_THROTTLE)) {
+		unsigned long min_interval = msecs_to_jiffies(50);
+
+		if (dev->last_ctrl_set_jiffies &&
+		    time_before(jiffies,
+				dev->last_ctrl_set_jiffies + min_interval)) {
+			unsigned long elapsed = dev->last_ctrl_set_jiffies +
+						min_interval - jiffies;
+			msleep(jiffies_to_msecs(elapsed));
+		}
+	}
+
 	ret = __uvc_query_ctrl(dev, query, unit, intfnum, cs, data, size,
 				UVC_CTRL_CONTROL_TIMEOUT);
+
+	if (query == UVC_SET_CUR &&
+	    (dev->quirks & UVC_QUIRK_CTRL_THROTTLE))
+		dev->last_ctrl_set_jiffies = jiffies;
+
 	if (likely(ret == size))
 		return 0;

@@ -107,6 +130,16 @@ int uvc_query_ctrl(struct uvc_device *dev, u8 query, u8 unit,
 		return ret < 0 ? ret : -EPIPE;
 	}

+	/*
+	 * Skip the error code query for devices that crash under load.
+	 * The standard error-code query (GET_CUR on
+	 * UVC_VC_REQUEST_ERROR_CODE_CONTROL) sends a second USB transfer to
+	 * a device that is already stalling, which can amplify the failure
+	 * into a full firmware lockup and xHCI controller death.
+	 */
+	if (dev->quirks & UVC_QUIRK_CTRL_THROTTLE)
+		return -EPIPE;
+
 	/* Reuse data[0] to request the error code. */
 	tmp = *(u8 *)data;

 	ret = __uvc_query_ctrl(dev, UVC_GET_CUR, 0, intfnum,
 			       UVC_VC_REQUEST_ERROR_CODE_CONTROL, data, 1,
--
2.43.0

[PATCH 3/3] media: uvcvideo: add quirks for Razer Kiyo Pro webcam

[JP Hein]

The Razer Kiyo Pro (1532:0e05) is a USB 3.0 webcam whose firmware has
two failure modes that cascade into full xHCI host controller death,
disconnecting every USB device on the bus:

  1. LPM/autosuspend resume: the device fails to reinitialize its UVC
     endpoints on resume, producing EPIPE on SET_CUR. The stalled
     endpoint triggers an xHCI stop-endpoint timeout.

  2. Rapid control transfers: ~25 rapid consecutive SET_CUR operations
     overwhelm the firmware, causing a full lockup.

Add the device to the UVC driver table with:

  - UVC_QUIRK_CTRL_THROTTLE: rate-limit SET_CUR (50ms interval) and
    skip error-code queries after EPIPE to prevent crash trigger #2.

  - UVC_QUIRK_DISABLE_AUTOSUSPEND: prevent USB autosuspend transitions
    that trigger crash #1. Same approach as Insta360 Link.

  - UVC_QUIRK_NO_RESET_RESUME: avoid the fragile reset-during-resume
    path. Same approach as Logitech Rally Bar.

Cc: stable@vger.kernel.org
Link: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2061177
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 XXXXXXX..XXXXXXX 100644
--- a/drivers/media/usb/uvc/uvc_driver.c
+++ b/drivers/media/usb/uvc/uvc_driver.c
@@ -2566,6 +2566,22 @@ static const struct usb_device_id uvc_ids[] = {
 	  .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) },
+
 	/* Oculus VR Positional Tracker DK2 */
 	{ .match_flags		= USB_DEVICE_ID_MATCH_DEVICE
 				| USB_DEVICE_ID_MATCH_INT_INFO,
--
2.43.0

Re: [PATCH 0/3] USB/UVC: Add quirks to prevent Razer Kiyo Pro xHCI cascade failure

[Alan Stern]

On Sat, Mar 21, 2026 at 03:37:02PM -0700, JP Hein wrote:
> 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.

Shouldn't a fix for this be added to xhci-hcd?  A funky device shouldn't 
be allowed to crash an entire USB bus.

Alan Stern

Re: [PATCH 0/3] USB/UVC: Add quirks to prevent Razer Kiyo Pro xHCI cascade failure

[Michal Pecio]

On Sat, 21 Mar 2026 15:37:02 -0700, JP Hein wrote:
> This has been reported as Ubuntu Launchpad Bug #2061177 and affects
> multiple kernel versions (tested on 6.5.x through 6.8.x).

> Tested on:
>   - Kernel: 6.8.0-106-generic (Ubuntu 24.04)

How many of those problems still exist on current releases,
where hese patches would end up applied?

Does anyone have a repro?

How does it behave on non-Intel USB controllers?

Regards,
Michal

Re: [PATCH 0/3] USB/UVC: Add quirks to prevent Razer Kiyo Pro xHCI cascade failure

[Jeffrey Hein]

On Sat, Mar 21, 2026 at 09:54:00PM -0700, Michal Pecio wrote:
> On Sat, 21 Mar 2026 15:37:02 -0700, JP Hein wrote:
> > This has been reported as Ubuntu Launchpad Bug #2061177 and affects
> > multiple kernel versions (tested on 6.5.x through 6.8.x).
>
> > Tested on:
> >   - Kernel: 6.8.0-106-generic (Ubuntu 24.04)
>
> How many of those problems still exist on current releases,
> where these patches would end up applied?

Both failure modes are in the device firmware (version 8.21), not the
kernel, so they exist on any kernel version.  On 6.8.0-106-generic
(where I tested), the TRB_STOP_RING case in
xhci_handle_command_timeout() goes straight to xhci_halt() +
xhci_hc_died() without attempting per-device recovery.  I have not
verified whether this path has changed in a more recent kernel.

I have personally reproduced the crash on 6.8.0-106-generic (Ubuntu
24.04).  The "6.5.x through 6.8.x" in the cover letter was overstated
-- I should have said the Launchpad bug has reports across those
versions, but I have only tested on 6.8.

> Does anyone have a repro?

Yes.  The stress test script is in the series repository:

    https://github.com/jphein/kiyo-xhci-fix

stress-test-kiyo.sh exercises UVC controls via v4l2-ctl at maximum
rate -- brightness, contrast, saturation, white balance, exposure,
focus, pan/tilt/zoom -- cycling through their full ranges each round.
With 0ms delay between controls, the crash consistently occurs around
round 25 of 50 (~5-10 seconds of sustained rapid SET_CUR).

To reproduce:

    bash stress-test-kiyo.sh 50

With the CTRL_THROTTLE patch applied (50ms rate limit), the same test
passes 50/50 rounds reliably.

> How does it behave on non-Intel USB controllers?

I have only tested on Intel Cannon Lake PCH xHCI (8086:a36d).  I do
not have a system with a non-Intel xHCI controller and this camera to
test with.

That said, the firmware lockup itself is controller-independent -- the
device stops responding to USB control transfers regardless of the host
controller.  What varies is the host controller's response to the
resulting stop-endpoint timeout.  On 6.8, xhci-hcd takes the
TRB_STOP_RING timeout straight to hc_died(), which kills the entire
bus.  A controller whose driver implemented per-device recovery could
isolate the failure to just the offending device.

The NO_LPM and CTRL_THROTTLE quirks operate at the USB core and UVC
driver level respectively, so they prevent the firmware from reaching
the lockup state regardless of which xHCI controller is underneath.

JP



On Sat, Mar 21, 2026 at 9:54 PM Michal Pecio <michal.pecio@gmail.com> wrote:
>
> On Sat, 21 Mar 2026 15:37:02 -0700, JP Hein wrote:
> > This has been reported as Ubuntu Launchpad Bug #2061177 and affects
> > multiple kernel versions (tested on 6.5.x through 6.8.x).
>
> > Tested on:
> >   - Kernel: 6.8.0-106-generic (Ubuntu 24.04)
>
> How many of those problems still exist on current releases,
> where hese patches would end up applied?
>
> Does anyone have a repro?
>
> How does it behave on non-Intel USB controllers?
>
> Regards,
> Michal



--
Jeffrey Pine Hein
Just plain helpful.
jphein.com ☀️ techempower.org
(530) 798-4099

Re: [PATCH 0/3] USB/UVC: Add quirks to prevent Razer Kiyo Pro xHCI cascade failure

[Michal Pecio]

On Sun, 22 Mar 2026 15:10:28 -0700, Jeffrey Hein wrote:
> Both failure modes are in the device firmware (version 8.21), not the
> kernel, so they exist on any kernel version.  On 6.8.0-106-generic
> (where I tested), the TRB_STOP_RING case in
> xhci_handle_command_timeout() goes straight to xhci_halt() +
> xhci_hc_died() without attempting per-device recovery.

Command timeout is a failure of the xHCI controller, not the device,
and as Alan said, it's generally not supposed to happen so we are
curious how it happens and if it can be prevented in xhci-hcd.

Device behavior may be a contributing factor, as can be a kernel bug
or controller HW bug. It would be helpful if somebody tried this on
non-Intel hardware and on current kernels, because there were various
changes to xHCI error handling over the last two years.

> The stress test script is in the series repository:
> 
>     https://github.com/jphein/kiyo-xhci-fix
> 
> stress-test-kiyo.sh exercises UVC controls via v4l2-ctl at maximum
> rate -- brightness, contrast, saturation, white balance, exposure,
> focus, pan/tilt/zoom -- cycling through their full ranges each round.
> With 0ms delay between controls, the crash consistently occurs around
> round 25 of 50 (~5-10 seconds of sustained rapid SET_CUR).

OK, I will see if it does anything interesting on my hardware, but it
may be nothing because I don't have this camera.

Did you try it on a different camera in the same USB port?

> That said, the firmware lockup itself is controller-independent -- the
> device stops responding to USB control transfers regardless of the
> host controller.  What varies is the host controller's response to the
> resulting stop-endpoint timeout.  On 6.8, xhci-hcd takes the
> TRB_STOP_RING timeout straight to hc_died()

Nope, this is controller dependent because Stop Endpoint is a command
to the controller and it has no reason to fail. Something is broken.

Could you boot a newer kernel (compile 7.0-rc5 yourself or at least get
latest release (or beta) of your distribution), enable dynamic debug 

echo 'module xhci_hcd +p' >/proc/dynamic_debug/control
echo 'module usbcore +p' >/proc/dynamic_debug/control

then connect the camera, crash it again and send dmesg output?

Regards,
Michal

Re: [PATCH 0/3] USB/UVC: Add quirks to prevent Razer Kiyo Pro xHCI cascade failure

[Ricardo Ribalda]

Hi JP

On Sat, 21 Mar 2026 at 23:38, JP Hein <jp@jphein.com> wrote:
>
> 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.

Have you tried reaching out to Razer in case they have a new firmware
that fixes your issues?

>
> 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: ~25 rapid consecutive UVC SET_CUR
>      operations overwhelm the firmware. The standard error-code query
>      (GET_CUR on UVC_VC_REQUEST_ERROR_CODE_CONTROL) amplifies the
>      failure by sending a second transfer to the already-stalling device,
>      pushing it into a full lockup and xHCI controller death.
>
> This has been reported as Ubuntu Launchpad Bug #2061177 and affects
> multiple kernel versions (tested on 6.5.x through 6.8.x). There are
> currently no device-specific quirks for this webcam in either the USB
> core quirks table or the UVC driver device table.
>
> This series adds three patches:
>
> Patch 1: USB core — USB_QUIRK_NO_LPM to prevent Link Power Management
>   transitions that destabilize the device firmware.
>
> Patch 2: UVC driver — introduce UVC_QUIRK_CTRL_THROTTLE to rate-limit
>   SET_CUR control transfers (50ms minimum interval) and skip the
>   error-code query after EPIPE errors on affected devices.
>
> Patch 3: UVC driver — add Razer Kiyo Pro device table entry with
>   UVC_QUIRK_CTRL_THROTTLE, UVC_QUIRK_DISABLE_AUTOSUSPEND, and
>   UVC_QUIRK_NO_RESET_RESUME to address both crash triggers.
>
> Together, these keep the device in a stable active state, prevent rapid
> control transfer crashes, and avoid the power management transitions
> that trigger the firmware bug.
>
> Tested on:
>   - Kernel: 6.8.0-106-generic (Ubuntu 24.04)
>   - Hardware: Intel Cannon Lake PCH xHCI (8086:a36d)
>   - Device: Razer Kiyo Pro (1532:0e05), firmware 8.21
>   - Stress test: 50 rounds of rapid UVC control changes, 0 failures
>
> JP Hein (3):
>   USB: core: add NO_LPM quirk for Razer Kiyo Pro webcam
>   media: uvcvideo: add UVC_QUIRK_CTRL_THROTTLE for fragile firmware
>   media: uvcvideo: add quirks for Razer Kiyo Pro webcam
>
>  drivers/media/usb/uvc/uvc_driver.c | 16 ++++++++++++++++
>  drivers/media/usb/uvc/uvc_video.c  | 33 +++++++++++++++++++++++++++++++++
>  drivers/media/usb/uvc/uvcvideo.h   |  3 +++
>  drivers/usb/core/quirks.c          |  2 ++
>  4 files changed, 54 insertions(+)
>


-- 
Ricardo Ribalda

[PATCH 0/3] USB/UVC: Add quirks to prevent Razer Kiyo Pro xHCI cascade failure

[JP Hein]

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 SET_CUR operations
     (hundreds over several seconds) overwhelm the firmware. The error-code query
     (GET_CUR on UVC_VC_REQUEST_ERROR_CODE_CONTROL) amplifies the
     failure by sending a second transfer to the already-stalling device,
     pushing it into a full lockup and xHCI controller death.

This has been reported as Ubuntu Launchpad Bug #2061177 and affects
multiple kernel versions (tested on 6.5.x through 6.8.x). There are
currently no device-specific quirks for this webcam in either the USB
core quirks table or the UVC driver device table.

This series adds three patches:

Patch 1: USB core — USB_QUIRK_NO_LPM to prevent Link Power Management
  transitions that destabilize the device firmware.

Patch 2: UVC driver — introduce UVC_QUIRK_CTRL_THROTTLE to rate-limit
  SET_CUR control transfers (50ms minimum interval) and skip the
  error-code query after EPIPE errors on affected devices.

Patch 3: UVC driver — add Razer Kiyo Pro device table entry with
  UVC_QUIRK_CTRL_THROTTLE, UVC_QUIRK_DISABLE_AUTOSUSPEND, and
  UVC_QUIRK_NO_RESET_RESUME to address both crash triggers.

Together, these keep the device in a stable active state, prevent rapid
control transfer crashes, and avoid the power management transitions
that trigger the firmware bug.

Tested on:
  - Kernel: 6.8.0-106-generic (Ubuntu 24.04)
  - Hardware: Intel Cannon Lake PCH xHCI (8086:a36d)
  - Device: Razer Kiyo Pro (1532:0e05), firmware 8.21
  - Stress test: 50 rounds of rapid UVC control changes, 0 failures

JP Hein (3):
  USB: core: add NO_LPM quirk for Razer Kiyo Pro webcam
  media: uvcvideo: add UVC_QUIRK_CTRL_THROTTLE for fragile firmware
  media: uvcvideo: add quirks for Razer Kiyo Pro webcam

 drivers/media/usb/uvc/uvc_driver.c | 17 +++++++++++++++++
 drivers/media/usb/uvc/uvc_video.c  | 33 +++++++++++++++++++++++++++++++++
 drivers/media/usb/uvc/uvcvideo.h   |  3 +++
 drivers/usb/core/quirks.c          |  2 ++
 4 files changed, 55 insertions(+)