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

[PATCH v5 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 HD Webcam C270).

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 9e7e49712..7c4038a1e 100644
--- a/drivers/usb/core/quirks.c
+++ b/drivers/usb/core/quirks.c
@@ -480,6 +480,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 v5 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 several hundred rapid control
changes over a few seconds, the device stops responding 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 | 32 +++++++++++++++++++++++++++++++
 drivers/media/usb/uvc/uvcvideo.h  |  3 +++
 2 files changed, 35 insertions(+)

diff --git a/drivers/media/usb/uvc/uvc_video.c b/drivers/media/usb/uvc/uvc_video.c
index 40c76c051..9f402f55e 100644
--- a/drivers/media/usb/uvc/uvc_video.c
+++ b/drivers/media/usb/uvc/uvc_video.c
@@ -75,8 +75,30 @@ int uvc_query_ctrl(struct uvc_device *dev, u8 query, u8 unit,
 	u8 error;
 	u8 tmp;
 
+	/*
+	 * Rate-limit SET_CUR operations for devices with fragile firmware.
+	 * The Razer Kiyo Pro locks up under sustained rapid SET_CUR
+	 * transfers (hundreds without delay), crashing the xHCI 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;
 
@@ -108,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;
 
diff --git a/drivers/media/usb/uvc/uvcvideo.h b/drivers/media/usb/uvc/uvcvideo.h
index 8480d65ec..cafc71457 100644
--- a/drivers/media/usb/uvc/uvcvideo.h
+++ b/drivers/media/usb/uvc/uvcvideo.h
@@ -81,6 +81,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
@@ -579,6 +580,8 @@ struct uvc_device {
 	struct usb_interface *intf;
 	unsigned long warnings;
 	u32 quirks;
+	/* Control transfer throttling (UVC_QUIRK_CTRL_THROTTLE) */
+	unsigned long last_ctrl_set_jiffies;
 	int intfnum;
 	char name[32];
 
-- 
2.43.0

[PATCH v5 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: sustained rapid SET_CUR operations
     (hundreds over several seconds) overwhelm the firmware.

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 | 17 +++++++++++++++++
 1 file changed, 17 insertions(+)

diff --git a/drivers/media/usb/uvc/uvc_driver.c b/drivers/media/usb/uvc/uvc_driver.c
index b0ca81d92..e8b4de942 100644
--- a/drivers/media/usb/uvc/uvc_driver.c
+++ b/drivers/media/usb/uvc/uvc_driver.c
@@ -2920,6 +2920,23 @@ 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

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

[Ricardo Ribalda]

Hi JP

On Tue, 31 Mar 2026 at 02:38, JP Hein <jp@jphein.com> wrote:
>
> 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 several hundred rapid control
> changes over a few seconds, the device stops responding entirely,
> triggering an xHCI stop-endpoint command timeout that causes the host
> controller to be declared dead, disconnecting every USB device on the
> bus.

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.

>
> 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 | 32 +++++++++++++++++++++++++++++++
>  drivers/media/usb/uvc/uvcvideo.h  |  3 +++
>  2 files changed, 35 insertions(+)
>
> diff --git a/drivers/media/usb/uvc/uvc_video.c b/drivers/media/usb/uvc/uvc_video.c
> index 40c76c051..9f402f55e 100644
> --- a/drivers/media/usb/uvc/uvc_video.c
> +++ b/drivers/media/usb/uvc/uvc_video.c
> @@ -75,8 +75,30 @@ int uvc_query_ctrl(struct uvc_device *dev, u8 query, u8 unit,
>         u8 error;
>         u8 tmp;
>

Why don't do you do the rate-limit in __uvc_query_ctrl()?

Are you sure that you only have to limit UVC_SET_CUR?

> +       /*
> +        * Rate-limit SET_CUR operations for devices with fragile firmware.
> +        * The Razer Kiyo Pro locks up under sustained rapid SET_CUR
> +        * transfers (hundreds without delay), crashing the xHCI 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;
>
> @@ -108,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;
>
> diff --git a/drivers/media/usb/uvc/uvcvideo.h b/drivers/media/usb/uvc/uvcvideo.h
> index 8480d65ec..cafc71457 100644
> --- a/drivers/media/usb/uvc/uvcvideo.h
> +++ b/drivers/media/usb/uvc/uvcvideo.h
> @@ -81,6 +81,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
> @@ -579,6 +580,8 @@ struct uvc_device {
>         struct usb_interface *intf;
>         unsigned long warnings;
>         u32 quirks;
> +       /* Control transfer throttling (UVC_QUIRK_CTRL_THROTTLE) */
> +       unsigned long last_ctrl_set_jiffies;
>         int intfnum;
>         char name[32];
>
> --
> 2.43.0
>


-- 
Ricardo Ribalda

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

[Ricardo Ribalda]

Hi JP

When we add a quirk to the list we include the output of `lsusb -v -d
1532:` to the commit message. Please add it to your next version.

Thanks!

On Tue, 31 Mar 2026 at 02:38, JP Hein <jp@jphein.com> wrote:
>
> 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: sustained rapid SET_CUR operations
>      (hundreds over several seconds) overwhelm the firmware.
>
> 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 | 17 +++++++++++++++++
>  1 file changed, 17 insertions(+)
>
> diff --git a/drivers/media/usb/uvc/uvc_driver.c b/drivers/media/usb/uvc/uvc_driver.c
> index b0ca81d92..e8b4de942 100644
> --- a/drivers/media/usb/uvc/uvc_driver.c
> +++ b/drivers/media/usb/uvc/uvc_driver.c
> @@ -2920,6 +2920,23 @@ 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
>


-- 
Ricardo Ribalda

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

[Jeffrey Hein]

Hi Ricardo,

On Thu, 9 Apr 2026 at 08:49, Ricardo Ribalda <ribalda@chromium.org> wrote:
> When we add a quirk to the list we include the output of `lsusb -v -d
> 1532:` to the commit message. Please add it to your next version.

Added the Device Descriptor section from lsusb -v to the v6 commit
message for patch 2/2.

Thanks,
JP

On Wed, Apr 8, 2026 at 11:50 PM Ricardo Ribalda <ribalda@chromium.org> wrote:
>
> Hi JP
>
> When we add a quirk to the list we include the output of `lsusb -v -d
> 1532:` to the commit message. Please add it to your next version.
>
> Thanks!
>
> On Tue, 31 Mar 2026 at 02:38, JP Hein <jp@jphein.com> wrote:
> >
> > 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: sustained rapid SET_CUR operations
> >      (hundreds over several seconds) overwhelm the firmware.
> >
> > 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 | 17 +++++++++++++++++
> >  1 file changed, 17 insertions(+)
> >
> > diff --git a/drivers/media/usb/uvc/uvc_driver.c b/drivers/media/usb/uvc/uvc_driver.c
> > index b0ca81d92..e8b4de942 100644
> > --- a/drivers/media/usb/uvc/uvc_driver.c
> > +++ b/drivers/media/usb/uvc/uvc_driver.c
> > @@ -2920,6 +2920,23 @@ 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
> >
>
>
> --
> Ricardo Ribalda



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

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

[Jeffrey Hein]

Hi Ricardo,

On Thu, 9 Apr 2026 at 08:45, Ricardo Ribalda <ribalda@chromium.org> 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.

Agreed -- a single device shouldn't be able to take down the host.
Alan Stern raised the same point and asked whether xhci-hcd should
handle this. Michal Pecio noted that the stop-endpoint command timeout
is a controller-side failure and asked for dynamic debug traces on
newer kernels and non-Intel hardware.

I provided the 6.17 traces. The result: the stress test (control
transfers only) now passes 50/50 thanks to xHCI error handling
improvements between 6.8 and 6.17. But starting a video stream still
triggers hc_died() -- the firmware fails to disable LPM during stream
setup, the endpoint stalls, and the stop-endpoint command times out.

So there's an open question on the xHCI side about whether the
controller could recover from stop-endpoint timeouts instead of
killing the HC. The UVC quirks are defense-in-depth -- they prevent
the firmware from reaching the failure state that triggers the timeout
in the first place.

I'm also planning to test on additional Intel machines (and non-Intel
if I can source one) to determine whether the stop-endpoint timeout
is controller-specific, per Michal's request.

> Why don't do you do the rate-limit in __uvc_query_ctrl()?

Good point -- moved it there in v6. This covers all callers including
uvc_set_video_ctrl() which bypasses uvc_query_ctrl() for probe/commit.

> Are you sure that you only have to limit UVC_SET_CUR?

I haven't been able to isolate the crash to a specific query direction
-- our testing shows it's the sustained transfer rate that matters. v6
throttles all query types in __uvc_query_ctrl() to be safe.

v6 posted with these changes.

Thanks,
JP

>
> On Wed, Apr 8, 2026 at 11:45 PM Ricardo Ribalda <ribalda@chromium.org> wrote:
>>
>> Hi JP
>>
>> On Tue, 31 Mar 2026 at 02:38, JP Hein <jp@jphein.com> wrote:
>> >
>> > 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 several hundred rapid control
>> > changes over a few seconds, the device stops responding entirely,
>> > triggering an xHCI stop-endpoint command timeout that causes the host
>> > controller to be declared dead, disconnecting every USB device on the
>> > bus.
>>
>> 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.
>>
>> >
>> > 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 | 32 +++++++++++++++++++++++++++++++
>> >  drivers/media/usb/uvc/uvcvideo.h  |  3 +++
>> >  2 files changed, 35 insertions(+)
>> >
>> > diff --git a/drivers/media/usb/uvc/uvc_video.c b/drivers/media/usb/uvc/uvc_video.c
>> > index 40c76c051..9f402f55e 100644
>> > --- a/drivers/media/usb/uvc/uvc_video.c
>> > +++ b/drivers/media/usb/uvc/uvc_video.c
>> > @@ -75,8 +75,30 @@ int uvc_query_ctrl(struct uvc_device *dev, u8 query, u8 unit,
>> >         u8 error;
>> >         u8 tmp;
>> >
>>
>> Why don't do you do the rate-limit in __uvc_query_ctrl()?
>>
>> Are you sure that you only have to limit UVC_SET_CUR?
>>
>> > +       /*
>> > +        * Rate-limit SET_CUR operations for devices with fragile firmware.
>> > +        * The Razer Kiyo Pro locks up under sustained rapid SET_CUR
>> > +        * transfers (hundreds without delay), crashing the xHCI 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;
>> >
>> > @@ -108,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;
>> >
>> > diff --git a/drivers/media/usb/uvc/uvcvideo.h b/drivers/media/usb/uvc/uvcvideo.h
>> > index 8480d65ec..cafc71457 100644
>> > --- a/drivers/media/usb/uvc/uvcvideo.h
>> > +++ b/drivers/media/usb/uvc/uvcvideo.h
>> > @@ -81,6 +81,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
>> > @@ -579,6 +580,8 @@ struct uvc_device {
>> >         struct usb_interface *intf;
>> >         unsigned long warnings;
>> >         u32 quirks;
>> > +       /* Control transfer throttling (UVC_QUIRK_CTRL_THROTTLE) */
>> > +       unsigned long last_ctrl_set_jiffies;
>> >         int intfnum;
>> >         char name[32];
>> >
>> > --
>> > 2.43.0
>> >
>>
>>
>> --
>> Ricardo Ribalda

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

[Michal Pecio]

On Thu, 9 Apr 2026 08:45:17 +0200, Ricardo Ribalda wrote:
> Hi JP
> 
> On Tue, 31 Mar 2026 at 02:38, JP Hein <jp@jphein.com> wrote:
> >
> > 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 several hundred rapid
> > control changes over a few seconds, the device stops responding
> > entirely, triggering an xHCI stop-endpoint command timeout that
> > causes the host controller to be declared dead, disconnecting every
> > USB device on the bus.  
> 
> 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.

I see that there is a case which crashes the host controller, but
without dynamic debug. It would be helpful if this can be reproduced
with debug enabled.

In the future, please also make sure that there are no unrelated
devices spamming dmesg, like "slot 17 ep 2" in those "stall" logs.
Please find this device and disconnect it or unbind its driver.

The initial cause of all that may really be the device getting
locked up for no good reason, but not 100% sure yet.

Regards,
Michal

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

[Jeffrey Hein]

Hi Michal,

Thanks for taking another look.

I will reproduce the hc_died() crash with dynamic debug enabled
(xhci_hcd +p, usbcore +p) and with all unrelated USB devices
disconnected so the logs are clean. The slot 17 stalls in the
previous logs may have been from another device on the bus --
I will make sure only the Kiyo is connected for the next capture.

The crash that kills the controller happens when starting a video
stream (LPM disable failure path). I can SSH in to grab dmesg
live during the crash since the controller death only takes out
USB, not the network.

Will follow up with the traces.

Thanks,
JP


On Thu, Apr 9, 2026 at 1:02 AM Michal Pecio <michal.pecio@gmail.com> wrote:
>
> On Thu, 9 Apr 2026 08:45:17 +0200, Ricardo Ribalda wrote:
> > Hi JP
> >
> > On Tue, 31 Mar 2026 at 02:38, JP Hein <jp@jphein.com> wrote:
> > >
> > > 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 several hundred rapid
> > > control changes over a few seconds, the device stops responding
> > > entirely, triggering an xHCI stop-endpoint command timeout that
> > > causes the host controller to be declared dead, disconnecting every
> > > USB device on the bus.
> >
> > 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.
>
> I see that there is a case which crashes the host controller, but
> without dynamic debug. It would be helpful if this can be reproduced
> with debug enabled.
>
> In the future, please also make sure that there are no unrelated
> devices spamming dmesg, like "slot 17 ep 2" in those "stall" logs.
> Please find this device and disconnect it or unbind its driver.
>
> The initial cause of all that may really be the device getting
> locked up for no good reason, but not 100% sure yet.
>
> Regards,
> Michal