* Re: [PATCH v3 1/3] usb: typec: ucsi: Detect and skip duplicate altmodes from buggy firmware
From: Heikki Krogerus @ 2026-04-08 10:09 UTC (permalink / raw)
To: Dmitry Baryshkov, AceLan Kao
Cc: Greg Kroah-Hartman, Pooja Katiyar, Abel Vesa, Andrei Kuchynski,
Venkat Jayaraman, Christian A. Ehrhardt, Pei Xiao,
François Scala, linux-usb, linux-kernel
In-Reply-To: <abF00-Squp-tEOKS@kuha>
+François
On Wed, Mar 11, 2026 at 03:57:41PM +0200, Heikki Krogerus wrote:
> Thu, Mar 05, 2026 at 04:58:02PM +0200, Dmitry Baryshkov kirjoitti:
> > On Wed, Feb 11, 2026 at 06:37:41AM +0100, Greg Kroah-Hartman wrote:
> > > On Wed, Feb 11, 2026 at 11:32:37AM +0800, AceLan Kao wrote:
> > > > A gentle ping.
> > > > Please help to review these patches, thanks.
> > >
> > > Wait, no, we rejected this series and said "fix the firmware".
> > >
> > > What happened to doing that?
> >
> > Having a similar problem with other platforms. It's not always possible
> > to fix the firmware. I have one platform with a similar issue, but that
> > laptop is EOLed long ago (Lenovo Yoga C630, the issue has been worked
> > around in the EC driver, but I'd be really happy to switch to the
> > generic fixup). At this point it really feels that there might
> > be more UCSI implemetations having this issue.
>
> I would still like to get an answer from Dell for this (if this was
> the Dell case). It looks like they are using the GET_ALTMODES_COMMAND
> in some custom way. It's almost like they are first returning all the
> SVIDs without the modes, followed by something else.
>
> So even if these products are EOL, and we will never get the firmware
> fixed, we still need to understand what exactly is being returned to
> the command, and is it returned like that intentionally or not.
François is now seeing the same issue. I guess nobody has had any
luck contacting Dell?
Chia-Lin, could you rebase and resend this?
thanks,
--
heikki
^ permalink raw reply
* [PATCH] usb: typec: ucsi: Add quirk for repeating SOP altmodes
From: Konrad Dybcio @ 2026-04-08 10:18 UTC (permalink / raw)
To: Heikki Krogerus, Greg Kroah-Hartman
Cc: usb4-upstream, linux-usb, linux-kernel, Konrad Dybcio
From: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Firmware on at least the Qualcomm X1E80100 SoC ignores the offset and
number fields of the GET_ALTERNATE_MODES command (with the recipient
set to SOP specifically), resulting in the UCSI core getting a payload
containing _all_ of the supported altmodes over and over and over again
(15 times 2 modes in total).
This leads to a number of 'already exists' splats from sysfs, as the
code tries to repeatedly register the same modes, with the same VDO and
SVIDs, most notably when connected to a TBT3 device that also supports
DP altmode.
Since this problem is isolated and the firmware can not really be
updated, work around it explicitly.
Signed-off-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
---
drivers/usb/typec/ucsi/ucsi.c | 4 ++++
drivers/usb/typec/ucsi/ucsi.h | 2 ++
drivers/usb/typec/ucsi/ucsi_glink.c | 4 +++-
3 files changed, 9 insertions(+), 1 deletion(-)
diff --git a/drivers/usb/typec/ucsi/ucsi.c b/drivers/usb/typec/ucsi/ucsi.c
index f6bb88b1ccee..88107af5f27a 100644
--- a/drivers/usb/typec/ucsi/ucsi.c
+++ b/drivers/usb/typec/ucsi/ucsi.c
@@ -632,6 +632,10 @@ static int ucsi_register_altmodes(struct ucsi_connector *con, u8 recipient)
if (ret)
return ret;
}
+
+ if (recipient == UCSI_RECIPIENT_SOP &&
+ con->ucsi->quirks & UCSI_REPEATING_SOP_ALTMODES)
+ return 0;
}
return 0;
diff --git a/drivers/usb/typec/ucsi/ucsi.h b/drivers/usb/typec/ucsi/ucsi.h
index cff9ddc2ae21..1dcf8343d00a 100644
--- a/drivers/usb/typec/ucsi/ucsi.h
+++ b/drivers/usb/typec/ucsi/ucsi.h
@@ -500,6 +500,8 @@ struct ucsi {
/* USB4 connection can imply that USB communcation is supported */
#define UCSI_USB4_IMPLIES_USB BIT(2)
+/* GET_ALTERNATE_MODES ignores OFFSET field for recipient == SOP */
+#define UCSI_REPEATING_SOP_ALTMODES BIT(3)
};
#define UCSI_MAX_DATA_LENGTH(u) (((u)->version < UCSI_VERSION_2_0) ? 0x10 : 0xff)
diff --git a/drivers/usb/typec/ucsi/ucsi_glink.c b/drivers/usb/typec/ucsi/ucsi_glink.c
index 12e07b9fe622..358b69db71b7 100644
--- a/drivers/usb/typec/ucsi/ucsi_glink.c
+++ b/drivers/usb/typec/ucsi/ucsi_glink.c
@@ -371,7 +371,9 @@ static void pmic_glink_ucsi_destroy(void *data)
static unsigned long quirk_sc8180x = UCSI_NO_PARTNER_PDOS;
static unsigned long quirk_sc8280xp = UCSI_NO_PARTNER_PDOS | UCSI_DELAY_DEVICE_PDOS;
static unsigned long quirk_sm8450 = UCSI_DELAY_DEVICE_PDOS;
-static unsigned long quirk_x1e80100 = UCSI_DELAY_DEVICE_PDOS | UCSI_USB4_IMPLIES_USB;
+static unsigned long quirk_x1e80100 = UCSI_DELAY_DEVICE_PDOS |
+ UCSI_USB4_IMPLIES_USB |
+ UCSI_REPEATING_SOP_ALTMODES;
static const struct of_device_id pmic_glink_ucsi_of_quirks[] = {
{ .compatible = "qcom,glymur-pmic-glink", .data = &quirk_sm8450, },
---
base-commit: f3e6330d7fe42b204af05a2dbc68b379e0ad179e
change-id: 20260408-topic-repeating_sop_altmodes_x1-cf19cc381b42
Best regards,
--
Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
^ permalink raw reply related
* Re: [PATCH] usb: rtl8150: avoid using uninitialized CSCR value
From: Andrew Lunn @ 2026-04-08 12:26 UTC (permalink / raw)
To: Michal Pecio
Cc: Petko Manolov, Simon Horman, Morduan Zang, Andrew Lunn,
David S . Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
linux-usb, netdev, linux-kernel, syzbot+9db6c624635564ad813c
In-Reply-To: <20260408103343.19cf599a.michal.pecio@gmail.com>
> BTW, some functions like rtl8150_reset() pre-set data to a value which
> will be safe in case of get_register() failure. But here, unhandled
> set_register() error is dodgy - the 0x10 bit may never turn on.
rtl8150_reset() is not great, it would be better to use something from
iopoll.h, and return ETIMEDOUT, but it does at least have a
timeout. And it looks like all other such loops have some form of
timeout.
Could this driver use some love? Yes. Does it mean not checking for
get_register() failure makes the driver badly broken? Probably not.
Andrew
^ permalink raw reply
* Re: [PATCH v1] dt-bindings: usb: Fix EIC7700 USB reset's issue
From: Conor Dooley @ 2026-04-08 17:24 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: caohang, gregkh, robh, krzk+dt, conor+dt, Thinh.Nguyen, p.zabel,
linux-kernel, linux-usb, devicetree, ningyu, linmin,
pinkesh.vaghela
In-Reply-To: <20260408-ginger-grouse-of-virtuosity-b3ee92@quoll>
[-- Attachment #1: Type: text/plain, Size: 1267 bytes --]
On Wed, Apr 08, 2026 at 09:48:43AM +0200, Krzysztof Kozlowski wrote:
> On Tue, Apr 07, 2026 at 02:17:02PM +0800, caohang@eswincomputing.com wrote:
> > From: Hang Cao <caohang@eswincomputing.com>
> >
> > The EIC7700 USB controller requires a USB PHY RESET operation.PHY RESET
>
> Missing space after full stop.
>
> > operation was missed in the verification version, as it was performed in
> > ESWIN's U-Boot.
> >
> > If a non-ESWIN provided loader is used, this issue will occur, resulting
> > in USB not work.This patch does not introduce any backward incompatibility
> > since the dts is not upstream yet.
>
> So U-Boot will be affected, no?
Is it even really affected? I don't think there's any bootloader for this
other than what ESWIN is shipping downstream, outside of people's development
trees. And any software that expected two resets will work just as badly as
it always did when a third one is added.
> And even if DTS is not upstreamed, what about all out of tree DTS?
> This is an already released ABI, so at least explain that driver does
> not care about resets here and grabs them all.
>
> >
> > Fixes: c640a4239db5 ("dt-bindings: usb: Add ESWIN EIC7700 USB controller")
>
>
> Best regards,
> Krzysztof
>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* [Bug 221337] New: Regression: USB webcam (0bda:636e) fails to resume from suspend on 7.0.0-rc6
From: bugzilla-daemon @ 2026-04-08 18:37 UTC (permalink / raw)
To: linux-usb
https://bugzilla.kernel.org/show_bug.cgi?id=221337
Bug ID: 221337
Summary: Regression: USB webcam (0bda:636e) fails to resume
from suspend on 7.0.0-rc6
Product: Drivers
Version: 2.5
Hardware: All
OS: Linux
Status: NEW
Severity: normal
Priority: P3
Component: USB
Assignee: drivers_usb@kernel-bugs.kernel.org
Reporter: chromechris@gmail.com
Regression: No
USB webcam (Realtek 0bda:636e, "ASUS 5M webcam" by Shinetech) fails to
resume from suspend on kernel 7.0.0-rc6. The device disconnects after
resume and does not reappear until reboot.
Kernel log on resume:
usb 1-1: PM: dpm_run_callback(): usb_dev_resume returns -22
usb 1-1: PM: failed to resume async: error -22
usb 1-1: USB disconnect, device number 2
The device works correctly on a fresh boot and across suspend/resume
on kernel 6.19.11.
Hardware: ASUS ROG Flow Z13 (GZ302EA), AMD Strix Halo
Working kernel: 6.19.11-1-cachyos
Broken kernel: 7.0.0-rc6-1-cachyos-rc
Distribution: CachyOS
--
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: Re: [PATCH v1] dt-bindings: usb: Fix EIC7700 USB reset's issue
From: Hang Cao @ 2026-04-09 2:41 UTC (permalink / raw)
To: Krzysztof Kozlowski, Conor Dooley
Cc: gregkh, robh, krzk+dt, conor+dt, Thinh.Nguyen, p.zabel,
linux-kernel, linux-usb, devicetree, ningyu, linmin,
pinkesh.vaghela
In-Reply-To: <20260408-designed-broadband-332044a2d1fb@spud>
[-- Attachment #1: Type: text/plain, Size: 2702 bytes --]
Hi, Krzysztof & Conor
No, U-Boot will NOT be affected. Sorry for the misunderstanding due to the
inaccurate commit message.
I will send the next version with the improved commit message below:
The EIC7700 USB requires a USB PHY reset operation; otherwise, the USB will
not work. The reason why the USB driver that was applied can work properly is
that the USB PHY has already been reset in ESWIN's U-Boot.
However, the proper functioning of the USB driver should not be dependent on
the bootloader. Therefore, it is necessary to incorporate the USB PHY reset
signal into the DT bindings.
This patch does not introduce any backward incompatibility since the dts is
not upstream yet. As array of reset operations are used in the driver,
no modifications to the USB controller driver are needed.
Best regards,
Hang
> -----Original Messages-----
> From: "Conor Dooley" <conor@kernel.org>
> Send time:Thursday, 09/04/2026 01:24:34
> To: "Krzysztof Kozlowski" <krzk@kernel.org>
> Cc: caohang@eswincomputing.com, gregkh@linuxfoundation.org, robh@kernel.org, krzk+dt@kernel.org, conor+dt@kernel.org, Thinh.Nguyen@synopsys.com, p.zabel@pengutronix.de, linux-kernel@vger.kernel.org, linux-usb@vger.kernel.org, devicetree@vger.kernel.org, ningyu@eswincomputing.com, linmin@eswincomputing.com, pinkesh.vaghela@einfochips.com
> Subject: Re: [PATCH v1] dt-bindings: usb: Fix EIC7700 USB reset's issue
>
> On Wed, Apr 08, 2026 at 09:48:43AM +0200, Krzysztof Kozlowski wrote:
> > On Tue, Apr 07, 2026 at 02:17:02PM +0800, caohang@eswincomputing.com wrote:
> > > From: Hang Cao <caohang@eswincomputing.com>
> > >
> > > The EIC7700 USB controller requires a USB PHY RESET operation.PHY RESET
> >
> > Missing space after full stop.
> >
> > > operation was missed in the verification version, as it was performed in
> > > ESWIN's U-Boot.
> > >
> > > If a non-ESWIN provided loader is used, this issue will occur, resulting
> > > in USB not work.This patch does not introduce any backward incompatibility
> > > since the dts is not upstream yet.
> >
> > So U-Boot will be affected, no?
>
> Is it even really affected? I don't think there's any bootloader for this
> other than what ESWIN is shipping downstream, outside of people's development
> trees. And any software that expected two resets will work just as badly as
> it always did when a third one is added.
>
> > And even if DTS is not upstreamed, what about all out of tree DTS?
> > This is an already released ABI, so at least explain that driver does
> > not care about resets here and grabs them all.
> >
> > >
> > > Fixes: c640a4239db5 ("dt-bindings: usb: Add ESWIN EIC7700 USB controller")
> >
> >
> > Best regards,
> > Krzysztof
> >
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 235 bytes --]
^ permalink raw reply
* Re: [PATCH v2 2/3] usb: chipidea: core: allow ci_irq_handler() handle both ID and VBUS change
From: Xu Yang @ 2026-04-09 6:11 UTC (permalink / raw)
To: Peter Chen (CIX); +Cc: gregkh, jun.li, linux-usb, linux-kernel, imx
In-Reply-To: <adXqKIri+bFwIbwt@nchen-desktop>
On Wed, Apr 08, 2026 at 01:39:52PM +0800, Peter Chen (CIX) wrote:
> On 26-04-02 15:14:56, Xu Yang wrote:
> > For USB role switch-triggered IRQ, ID and VBUS change come together, for
> > example when switching from host to device mode. ID indicate a role switch
> > and VBUS is required to determine whether the device controller can start
> > operating. Currently, ci_irq_handler() handles only a single event per
> > invocation. This can cause an issue where switching to device mode results
> > in the device controller not working at all. Allowing ci_irq_handler() to
> > handle both ID and VBUS change in one call resolves this issue.
> >
> > Meanwhile, this change also affects the VBUS event handling logic.
> > Previously, if an ID event indicated host mode the VBUS IRQ will be
> > ignored as the device disable BSE when stop() is called. With the new
> > behavior, if ID and VBUS IRQ occur together and the target mode is host,
> > the VBUS event is queued and ci_handle_vbus_change() will call
> > usb_gadget_vbus_connect(), after which USBMODE is switched to device mode,
> > causing host mode to stop working. To prevent this, an additional check is
> > added to skip handling VBUS event when current role is not device mode.
> >
> > Suggested-by: Peter Chen <peter.chen@kernel.org>
> > Fixes: e1b5d2bed67c ("usb: chipidea: core: handle usb role switch in a common way")
> > Cc: stable@vger.kernel.org
> > Signed-off-by: Xu Yang <xu.yang_2@nxp.com>
> >
> > ---
> > Changes in v2:
> > - change ci_irq_handler() instead of assign id_event/b_sess_valid_event
> > as true and queue otg work directly
> > ---
> > drivers/usb/chipidea/core.c | 45 +++++++++++++++++++------------------
> > drivers/usb/chipidea/otg.c | 3 +++
> > 2 files changed, 26 insertions(+), 22 deletions(-)
> >
> > diff --git a/drivers/usb/chipidea/core.c b/drivers/usb/chipidea/core.c
> > index 87be716dff3e..7cfabb04a4fb 100644
> > --- a/drivers/usb/chipidea/core.c
> > +++ b/drivers/usb/chipidea/core.c
> > @@ -544,30 +544,31 @@ static irqreturn_t ci_irq_handler(int irq, void *data)
> > if (ret == IRQ_HANDLED)
> > return ret;
> > }
> > - }
> >
> > - /*
> > - * Handle id change interrupt, it indicates device/host function
> > - * switch.
> > - */
> > - if (ci->is_otg && (otgsc & OTGSC_IDIE) && (otgsc & OTGSC_IDIS)) {
> > - ci->id_event = true;
> > - /* Clear ID change irq status */
> > - hw_write_otgsc(ci, OTGSC_IDIS, OTGSC_IDIS);
> > - ci_otg_queue_work(ci);
> > - return IRQ_HANDLED;
> > - }
> > + /*
> > + * Handle id change interrupt, it indicates device/host function
> > + * switch.
> > + */
> > + if ((otgsc & OTGSC_IDIE) && (otgsc & OTGSC_IDIS)) {
> > + ci->id_event = true;
> > + /* Clear ID change irq status */
> > + hw_write_otgsc(ci, OTGSC_IDIS, OTGSC_IDIS);
> > + }
> >
> > - /*
> > - * Handle vbus change interrupt, it indicates device connection
> > - * and disconnection events.
> > - */
> > - if (ci->is_otg && (otgsc & OTGSC_BSVIE) && (otgsc & OTGSC_BSVIS)) {
> > - ci->b_sess_valid_event = true;
> > - /* Clear BSV irq */
> > - hw_write_otgsc(ci, OTGSC_BSVIS, OTGSC_BSVIS);
> > - ci_otg_queue_work(ci);
> > - return IRQ_HANDLED;
> > + /*
> > + * Handle vbus change interrupt, it indicates device connection
> > + * and disconnection events.
> > + */
> > + if ((otgsc & OTGSC_BSVIE) && (otgsc & OTGSC_BSVIS)) {
> > + ci->b_sess_valid_event = true;
> > + /* Clear BSV irq */
> > + hw_write_otgsc(ci, OTGSC_BSVIS, OTGSC_BSVIS);
> > + }
> > +
> > + if (ci->id_event || ci->b_sess_valid_event) {
> > + ci_otg_queue_work(ci);
> > + return IRQ_HANDLED;
> > + }
> > }
> >
> > /* Handle device/host interrupt */
> > diff --git a/drivers/usb/chipidea/otg.c b/drivers/usb/chipidea/otg.c
> > index 647e98f4e351..def933b73a90 100644
> > --- a/drivers/usb/chipidea/otg.c
> > +++ b/drivers/usb/chipidea/otg.c
> > @@ -130,6 +130,9 @@ enum ci_role ci_otg_role(struct ci_hdrc *ci)
> >
> > void ci_handle_vbus_change(struct ci_hdrc *ci)
> > {
> > + if (ci->role != CI_ROLE_GADGET)
> > + return;
> > +
>
> Are there the situations that the ci->role is not CI_ROLE_GADGET, but
> it needs to handle VBUS? Eg, ci->role is CI_ROLE_NONE, and VBUS event
> occurs?
I suppose you refer CI_ROLE_END.
When the role is CI_ROLE_END, the VBUS IRQ is disabled.
- If the controller keeps at CI_ROLE_END state and VBUS comes, the IRQ
won't trigger just like it is ignored as it means nothing for CI_ROLE_END.
- If VBUS comes at CI_ROLE_END state and the controller switches to
CI_ROLE_GADGET later, the VBUS event was lost but the driver will lookup
real VBUS state and do proper actions.
So the situations seem not exist.
Thanks,
Xu Yang
^ permalink raw reply
* Re: [PATCH v5 2/3] media: uvcvideo: add UVC_QUIRK_CTRL_THROTTLE for fragile firmware
From: Ricardo Ribalda @ 2026-04-09 6:45 UTC (permalink / raw)
To: JP Hein, Alan Stern, Michal Pecio
Cc: Laurent Pinchart, Hans de Goede, Greg Kroah-Hartman, linux-media,
linux-usb, stable
In-Reply-To: <20260331003806.212565-3-jp@jphein.com>
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
^ permalink raw reply
* Re: [PATCH v5 3/3] media: uvcvideo: add quirks for Razer Kiyo Pro webcam
From: Ricardo Ribalda @ 2026-04-09 6:49 UTC (permalink / raw)
To: JP Hein
Cc: Laurent Pinchart, Hans de Goede, Greg Kroah-Hartman, linux-media,
linux-usb, Michal Pecio, stable
In-Reply-To: <20260331003806.212565-4-jp@jphein.com>
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
^ permalink raw reply
* Re: [PATCH v5 3/3] media: uvcvideo: add quirks for Razer Kiyo Pro webcam
From: Jeffrey Hein @ 2026-04-09 7:38 UTC (permalink / raw)
To: Ricardo Ribalda
Cc: Laurent Pinchart, Hans de Goede, Greg Kroah-Hartman, linux-media,
linux-usb, Michal Pecio, stable
In-Reply-To: <CANiDSCs2Mt1XziD9w6Dv1uid82UdkeQ2EuyU0+W1RxtqaHTyPw@mail.gmail.com>
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
^ permalink raw reply
* [PATCH v6 0/2] media: uvcvideo: Add quirks to prevent Razer Kiyo Pro xHCI cascade failure
From: JP Hein @ 2026-04-09 7:42 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. 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.
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 v6 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()
and skip the error-code query after EPIPE errors on affected devices.
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 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 -- the
firmware doesn't distinguish between query directions under load
(Ricardo Ribalda)
- Added lsusb -v Device Descriptor to patch 2/2 commit message
(Ricardo Ribalda)
- Bug reproduced on two separate Kiyo Pro units, confirming not
unit-specific
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 | 30 ++++++++++++++++++++++++++++++
drivers/media/usb/uvc/uvcvideo.h | 3 +++
3 files changed, 49 insertions(+)
--
2.43.0
^ permalink raw reply
* [PATCH v6 1/2] media: uvcvideo: add UVC_QUIRK_CTRL_THROTTLE for fragile USB firmware
From: JP Hein @ 2026-04-09 7:42 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: <20260409074242.2115657-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. The kernel's standard UVC error recovery (GET_CUR on
UVC_VC_REQUEST_ERROR_CODE_CONTROL) then sends a second transfer to the
already-stalling device, amplifying the failure into complete firmware
lockup and xHCI controller death.
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()
- Skips the error-code query after EPIPE to avoid amplifying stalls
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 | 30 ++++++++++++++++++++++++++++++
drivers/media/usb/uvc/uvcvideo.h | 3 +++
2 files changed, 33 insertions(+)
diff --git a/drivers/media/usb/uvc/uvc_video.c b/drivers/media/usb/uvc/uvc_video.c
index a5013a7..cee93ac 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;
@@ -108,6 +128,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 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 v6 2/2] media: uvcvideo: add Razer Kiyo Pro to device info table
From: JP Hein @ 2026-04-09 7:42 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: <20260409074242.2115657-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 and skip
error-code queries after EPIPE
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 -v:
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
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
* Re: [PATCH v5 2/3] media: uvcvideo: add UVC_QUIRK_CTRL_THROTTLE for fragile firmware
From: Jeffrey Hein @ 2026-04-09 7:51 UTC (permalink / raw)
To: Ricardo Ribalda
Cc: Alan Stern, Michal Pecio, Laurent Pinchart, Hans de Goede,
Greg Kroah-Hartman, linux-media, linux-usb, stable
In-Reply-To: <CAD5VvzAu8+Qz7hEEBzuKvO11X=YD-wrtX3_Tk77g2Cq5rZZD0Q@mail.gmail.com>
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
^ permalink raw reply
* Re: [PATCH v6 1/2] media: uvcvideo: add UVC_QUIRK_CTRL_THROTTLE for fragile USB firmware
From: Ricardo Ribalda @ 2026-04-09 7:57 UTC (permalink / raw)
To: JP Hein
Cc: Laurent Pinchart, Hans de Goede, Greg Kroah-Hartman, linux-media,
linux-usb, Michal Pecio
In-Reply-To: <20260409074242.2115657-2-jp@jphein.com>
On Thu, 9 Apr 2026 at 09:44, JP Hein <jp@jphein.com> wrote:
>
> 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. The kernel's standard UVC error recovery (GET_CUR on
> UVC_VC_REQUEST_ERROR_CODE_CONTROL) then sends a second transfer to the
> already-stalling device, amplifying the failure into complete firmware
> lockup and xHCI controller death.
>
> 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()
> - Skips the error-code query after EPIPE to avoid amplifying stalls
>
> 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 | 30 ++++++++++++++++++++++++++++++
> drivers/media/usb/uvc/uvcvideo.h | 3 +++
> 2 files changed, 33 insertions(+)
>
> diff --git a/drivers/media/usb/uvc/uvc_video.c b/drivers/media/usb/uvc/uvc_video.c
> index a5013a7..cee93ac 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;
> @@ -108,6 +128,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;
I do not believe this is needed anymore now that the check is in the
inner funcion
> +
> /* 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 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
>
--
Ricardo Ribalda
^ permalink raw reply
* Re: [PATCH v6 2/2] media: uvcvideo: add Razer Kiyo Pro to device info table
From: Ricardo Ribalda @ 2026-04-09 7:57 UTC (permalink / raw)
To: JP Hein
Cc: Laurent Pinchart, Hans de Goede, Greg Kroah-Hartman, linux-media,
linux-usb, Michal Pecio
In-Reply-To: <20260409074242.2115657-3-jp@jphein.com>
Hi
On Thu, 9 Apr 2026 at 09:44, JP Hein <jp@jphein.com> wrote:
>
> 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 and skip
> error-code queries after EPIPE
> 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 -v:
> 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
>
Is this the whole output of lsusb?? Can you try with lsusb -vv?
> 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
>
--
Ricardo Ribalda
^ permalink raw reply
* Re: [PATCH v5 2/3] media: uvcvideo: add UVC_QUIRK_CTRL_THROTTLE for fragile firmware
From: Michal Pecio @ 2026-04-09 8:02 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: <CANiDSCvsxP+npQTHUrMTp+Z8XULYKSLTz2AFu+WQnsLbRBGa2w@mail.gmail.com>
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
^ permalink raw reply
* Re: [PATCH v6 1/2] media: uvcvideo: add UVC_QUIRK_CTRL_THROTTLE for fragile USB firmware
From: Jeffrey Hein @ 2026-04-09 8:12 UTC (permalink / raw)
To: Ricardo Ribalda
Cc: Laurent Pinchart, Hans de Goede, Greg Kroah-Hartman, linux-media,
linux-usb, Michal Pecio
In-Reply-To: <CANiDSCva8V5+h6QsHLXEsJfjMPYaoGWKzZcvH9u2wgXCs-jRdw@mail.gmail.com>
Hi Ricardo,
Agreed -- the error-code query goes through __uvc_query_ctrl() now,
so it gets the 50ms throttle automatically. Dropped in v7.
Thanks,
JP
On Thu, Apr 9, 2026 at 12:57 AM Ricardo Ribalda <ribalda@chromium.org> wrote:
>
> On Thu, 9 Apr 2026 at 09:44, JP Hein <jp@jphein.com> wrote:
> >
> > 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. The kernel's standard UVC error recovery (GET_CUR on
> > UVC_VC_REQUEST_ERROR_CODE_CONTROL) then sends a second transfer to the
> > already-stalling device, amplifying the failure into complete firmware
> > lockup and xHCI controller death.
> >
> > 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()
> > - Skips the error-code query after EPIPE to avoid amplifying stalls
> >
> > 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 | 30 ++++++++++++++++++++++++++++++
> > drivers/media/usb/uvc/uvcvideo.h | 3 +++
> > 2 files changed, 33 insertions(+)
> >
> > diff --git a/drivers/media/usb/uvc/uvc_video.c b/drivers/media/usb/uvc/uvc_video.c
> > index a5013a7..cee93ac 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;
> > @@ -108,6 +128,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;
>
> I do not believe this is needed anymore now that the check is in the
> inner funcion
>
> > +
> > /* 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 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
> >
>
>
> --
> Ricardo Ribalda
^ permalink raw reply
* Re: [PATCH v6 2/2] media: uvcvideo: add Razer Kiyo Pro to device info table
From: Jeffrey Hein @ 2026-04-09 8:13 UTC (permalink / raw)
To: Ricardo Ribalda
Cc: Laurent Pinchart, Hans de Goede, Greg Kroah-Hartman, linux-media,
linux-usb, Michal Pecio
In-Reply-To: <CANiDSCvNLVO7EEMO-FzSD1cteoMUTcftaXqvw5-AW-VqKLkNxA@mail.gmail.com>
Hi Ricardo,
Full lsusb -vv output included in the v7 commit message.
Thanks,
JP
On Thu, Apr 9, 2026 at 12:58 AM Ricardo Ribalda <ribalda@chromium.org> wrote:
>
> Hi
>
> On Thu, 9 Apr 2026 at 09:44, JP Hein <jp@jphein.com> wrote:
> >
> > 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 and skip
> > error-code queries after EPIPE
> > 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 -v:
> > 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
> >
>
> Is this the whole output of lsusb?? Can you try with lsusb -vv?
>
> > 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
> >
>
>
> --
> Ricardo Ribalda
^ permalink raw reply
* Re: [PATCH v5 2/3] media: uvcvideo: add UVC_QUIRK_CTRL_THROTTLE for fragile firmware
From: Jeffrey Hein @ 2026-04-09 8:15 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: <20260409100247.7cfb62d1.michal.pecio@gmail.com>
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
^ permalink raw reply
* [PATCH] usb: musb: omap2430: Fix use-after-free in omap2430_probe()
From: Wentao Liang @ 2026-04-09 10:11 UTC (permalink / raw)
To: b-liu, gregkh; +Cc: linux-usb, linux-omap, linux-kernel, Wentao Liang, stable
In omap2430_probe(), of_node_put(np) is called prematurely before the
last access to np, leading to a use-after-free if the node's reference
count drops to zero. Move the of_node_put() calls after the last use of
np in both the success and error paths.
Fixes: ffbe2feac59b ("usb: musb: omap2430: Fix probe regression for missing resources")
Cc: stable@vger.kernel.org
Signed-off-by: Wentao Liang <vulab@iscas.ac.cn>
---
drivers/usb/musb/omap2430.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/usb/musb/omap2430.c b/drivers/usb/musb/omap2430.c
index 48bb9bfb2204..333ab79f0ca9 100644
--- a/drivers/usb/musb/omap2430.c
+++ b/drivers/usb/musb/omap2430.c
@@ -337,7 +337,6 @@ static int omap2430_probe(struct platform_device *pdev)
} else {
device_set_of_node_from_dev(&musb->dev, &pdev->dev);
}
- of_node_put(np);
glue->dev = &pdev->dev;
glue->musb = musb;
@@ -455,6 +454,7 @@ static int omap2430_probe(struct platform_device *pdev)
dev_err(&pdev->dev, "failed to register musb device\n");
goto err_disable_rpm;
}
+ of_node_put(np);
return 0;
@@ -464,6 +464,7 @@ static int omap2430_probe(struct platform_device *pdev)
if (!IS_ERR(glue->control_otghs))
put_device(glue->control_otghs);
err_put_musb:
+ of_node_put(np);
platform_device_put(musb);
return ret;
--
2.34.1
^ permalink raw reply related
* [PATCH v1 1/2] dt-bindings: usb: dwc3: add support for StarFive JHB100
From: Minda Chen @ 2026-04-09 10:12 UTC (permalink / raw)
To: Greg Kroah-Hartman, Thinh Nguyen, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, linux-usb
Cc: linux-kernel, devicetree, Minda Chen
In-Reply-To: <20260409101227.39417-1-minda.chen@starfivetech.com>
Add support for the USB 2.0 Dual-Role Device (DRD) controller embedded
in the StarFive JHB100 SoC. The controller is based on the Synopsys
DesignWare Core USB 3 (DWC3) IP.
Signed-off-by: Minda Chen <minda.chen@starfivetech.com>
---
.../bindings/usb/starfive,jhb100-dwc3.yaml | 64 +++++++++++++++++++
MAINTAINERS | 3 +-
2 files changed, 66 insertions(+), 1 deletion(-)
create mode 100644 Documentation/devicetree/bindings/usb/starfive,jhb100-dwc3.yaml
diff --git a/Documentation/devicetree/bindings/usb/starfive,jhb100-dwc3.yaml b/Documentation/devicetree/bindings/usb/starfive,jhb100-dwc3.yaml
new file mode 100644
index 000000000000..fbabe99e9d5c
--- /dev/null
+++ b/Documentation/devicetree/bindings/usb/starfive,jhb100-dwc3.yaml
@@ -0,0 +1,64 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/usb/starfive,jhb100-dwc3.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: StarFive JHB100 DWC3 USB SoC Controller
+
+maintainers:
+ - Minda Chen <minda.chen@starfivetech.com>
+
+description:
+ The USB DRD controller on JHB100 BMC SoC.
+
+allOf:
+ - $ref: snps,dwc3-common.yaml#
+
+properties:
+ compatible:
+ const: starfive,jhb100-dwc3
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ clocks:
+ items:
+ - description: USB main enable clk
+ - description: DWC3 bus early clock
+ - description: DWC3 ref clock
+
+ clock-names:
+ items:
+ - const: main
+ - const: bus_early
+ - const: ref
+
+ resets:
+ maxItems: 1
+
+required:
+ - compatible
+ - reg
+ - clocks
+ - clock-names
+ - interrupts
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ usb@11800000 {
+ compatible = "starfive,jhb100-dwc3";
+ reg = <0x11800000 0x10000>;
+ clocks = <&usbcrg 9>,
+ <&usbcrg 5>,
+ <&usbcrg 6>;
+ clock-names = "main", "bus_early", "ref";
+ resets = <&usbcrg 4>;
+ interrupts = <105>;
+ dr_mode = "host";
+ };
diff --git a/MAINTAINERS b/MAINTAINERS
index 32bd94a0b94c..2f3475e0b678 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -25252,10 +25252,11 @@ F: Documentation/devicetree/bindings/reset/starfive,jh7100-reset.yaml
F: drivers/reset/starfive/reset-starfive-jh71*
F: include/dt-bindings/reset/starfive?jh71*.h
-STARFIVE JH71X0 USB DRIVERS
+STARFIVE USB DRIVERS
M: Minda Chen <minda.chen@starfivetech.com>
S: Maintained
F: Documentation/devicetree/bindings/usb/starfive,jh7110-usb.yaml
+F: Documentation/devicetree/bindings/usb/starfive,jhb100-dwc3.yaml
F: drivers/usb/cdns3/cdns3-starfive.c
STARFIVE JH71XX PMU CONTROLLER DRIVER
--
2.17.1
^ permalink raw reply related
* [PATCH v1 0/2] Add StarFive JHB100 soc BMC DRD USB support
From: Minda Chen @ 2026-04-09 10:12 UTC (permalink / raw)
To: Greg Kroah-Hartman, Thinh Nguyen, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, linux-usb
Cc: linux-kernel, devicetree, Minda Chen
JHB100 is a Starfive new RISC-V SoC for datacenter BMC (Baseboard
Managent Controller). Similar with Aspeed 27x0.
The JHB100 minimal system upstream is in progress:
https://patchwork.kernel.org/project/linux-riscv/cover/20260403054945.467700-1-changhuang.liang@starfivetech.com/
JHB100 contain 2 USB 2.0 dwc3 USB port, and intergrated with USB
2.0 PHY. These 2 ports just for BMC soc use. Actually JHB100 contain
other dwc3 usb controllers, which is using as xhci over PCIe and locate
in PCIe EP. It is working for host server. But now PCIe EP driver is not
in upstream progress. So just commit BMC USB 2.0 port driver patches to
upstream first.
The patch base in V7.0-rc5
Minda Chen (2):
dt-bindings: usb: dwc3: add support for StarFive JHB100
usb: dwc3: starfive: Add JHB100 USB 2.0 DRD controller
.../bindings/usb/starfive,jhb100-dwc3.yaml | 64 +++++++++++++++++++
MAINTAINERS | 3 +-
drivers/usb/dwc3/dwc3-generic-plat.c | 2 +-
3 files changed, 67 insertions(+), 2 deletions(-)
create mode 100644 Documentation/devicetree/bindings/usb/starfive,jhb100-dwc3.yaml
base-commit: c369299895a591d96745d6492d4888259b004a9e
--
2.17.1
^ permalink raw reply
* [PATCH v1 2/2] usb: dwc3: starfive: Add JHB100 USB 2.0 DRD controller
From: Minda Chen @ 2026-04-09 10:12 UTC (permalink / raw)
To: Greg Kroah-Hartman, Thinh Nguyen, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, linux-usb
Cc: linux-kernel, devicetree, Minda Chen
In-Reply-To: <20260409101227.39417-1-minda.chen@starfivetech.com>
JHB100 contains 2 dwc3 USB controllers and PHYs and working
as USB 2.0 speed. It can working in generic platform and
setting default properties.
Signed-off-by: Minda Chen <minda.chen@starfivetech.com>
---
drivers/usb/dwc3/dwc3-generic-plat.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/usb/dwc3/dwc3-generic-plat.c b/drivers/usb/dwc3/dwc3-generic-plat.c
index e846844e0023..4f2a9c531f0b 100644
--- a/drivers/usb/dwc3/dwc3-generic-plat.c
+++ b/drivers/usb/dwc3/dwc3-generic-plat.c
@@ -89,7 +89,6 @@ static int dwc3_generic_probe(struct platform_device *pdev)
dev_err(&pdev->dev, "missing memory resource\n");
return -ENODEV;
}
-
dwc3g->resets = devm_reset_control_array_get_optional_exclusive(dev);
if (IS_ERR(dwc3g->resets))
return dev_err_probe(dev, PTR_ERR(dwc3g->resets), "failed to get resets\n");
@@ -214,6 +213,7 @@ static const struct of_device_id dwc3_generic_of_match[] = {
{ .compatible = "spacemit,k1-dwc3", },
{ .compatible = "fsl,ls1028a-dwc3", &fsl_ls1028_dwc3},
{ .compatible = "eswin,eic7700-dwc3", &eic7700_dwc3},
+ { .compatible = "starfive,jhb100-dwc3", },
{ /* sentinel */ }
};
MODULE_DEVICE_TABLE(of, dwc3_generic_of_match);
--
2.17.1
^ permalink raw reply related
* 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