* [PATCH] HID: usbhid: replace strlcat with better alternatives
From: Mahad Ibrahim @ 2026-04-10 19:24 UTC (permalink / raw)
To: Jiri Kosina, Benjamin Tissoires
Cc: linux-usb, linux-input, linux-hardening, linux-kernel-mentees,
Shuah Khan, linux-kernel, Mahad Ibrahim
In preparation for the removal of the strlcat() API as per the KSPP,
replace the string concatenation logic in hid-core, usbkbd, and
usbmouse with struct seq_buf, which tracks the current write position
and remaining space internally. The changes implemented include:
- Replace device name and phys concatenation with seq_buf_puts().
- Include Struct seq_buf and its initialization.
- Include header file of seq_buf.
- Replace strlen() with seq_buf_used() on the string buffer which was
tracked by seq_buf to increase speed.
- Add size_t len in files which did not have it.
- Use of strscpy with length in place of strlcat.
Testing: This driver was compiled as a module as well as in-built in
QEMU with the QEMU basic mouse, and QEMU basic keyboard. The testing was
done in the following steps.
- Add Hardware Mouse in QEMU checking the usbhid module.
- Verify dmesg string name of mouse.
- Blacklist hidusb module from auto-loading, and removing the module via
rmmod.
- Load usbmouse module, and reattach QEMU mouse.
- Verify dmesg string name of mouse.
- Repeat same procedure on usbkbd module.
This aligns the driver with KSPP security guidelines.
Link: https://github.com/KSPP/linux/issues/370
Signed-off-by: Mahad Ibrahim <mahad.ibrahim.dev@gmail.com>
---
drivers/hid/usbhid/hid-core.c | 17 ++++++++++-------
drivers/hid/usbhid/usbkbd.c | 15 ++++++++++-----
drivers/hid/usbhid/usbmouse.c | 15 ++++++++++-----
3 files changed, 30 insertions(+), 17 deletions(-)
diff --git a/drivers/hid/usbhid/hid-core.c b/drivers/hid/usbhid/hid-core.c
index ddd5d77fb5a5..476308378e90 100644
--- a/drivers/hid/usbhid/hid-core.c
+++ b/drivers/hid/usbhid/hid-core.c
@@ -27,6 +27,7 @@
#include <linux/wait.h>
#include <linux/workqueue.h>
#include <linux/string.h>
+#include <linux/seq_buf.h>
#include <linux/usb.h>
@@ -1365,6 +1366,7 @@ static int usbhid_probe(struct usb_interface *intf, const struct usb_device_id *
struct usb_device *dev = interface_to_usbdev(intf);
struct usbhid_device *usbhid;
struct hid_device *hid;
+ struct seq_buf hid_name;
unsigned int n, has_in = 0;
size_t len;
int ret;
@@ -1399,7 +1401,7 @@ static int usbhid_probe(struct usb_interface *intf, const struct usb_device_id *
hid->vendor = le16_to_cpu(dev->descriptor.idVendor);
hid->product = le16_to_cpu(dev->descriptor.idProduct);
hid->version = le16_to_cpu(dev->descriptor.bcdDevice);
- hid->name[0] = 0;
+ seq_buf_init(&hid_name, hid->name, sizeof(hid->name));
if (intf->cur_altsetting->desc.bInterfaceProtocol ==
USB_INTERFACE_PROTOCOL_MOUSE)
hid->type = HID_TYPE_USBMOUSE;
@@ -1407,22 +1409,23 @@ static int usbhid_probe(struct usb_interface *intf, const struct usb_device_id *
hid->type = HID_TYPE_USBNONE;
if (dev->manufacturer)
- strscpy(hid->name, dev->manufacturer, sizeof(hid->name));
+ seq_buf_puts(&hid_name, dev->manufacturer);
if (dev->product) {
if (dev->manufacturer)
- strlcat(hid->name, " ", sizeof(hid->name));
- strlcat(hid->name, dev->product, sizeof(hid->name));
+ seq_buf_puts(&hid_name, " ");
+ seq_buf_puts(&hid_name, dev->product);
}
- if (!strlen(hid->name))
+ if (!seq_buf_used(&hid_name))
snprintf(hid->name, sizeof(hid->name), "HID %04x:%04x",
le16_to_cpu(dev->descriptor.idVendor),
le16_to_cpu(dev->descriptor.idProduct));
usb_make_path(dev, hid->phys, sizeof(hid->phys));
- strlcat(hid->phys, "/input", sizeof(hid->phys));
- len = strlen(hid->phys);
+ len = strnlen(hid->phys, sizeof(hid->phys));
+ strscpy(hid->phys + len, "/input", sizeof(hid->phys) - len);
+ len = strnlen(hid->phys, sizeof(hid->phys));
if (len < sizeof(hid->phys) - 1)
snprintf(hid->phys + len, sizeof(hid->phys) - len,
"%d", intf->altsetting[0].desc.bInterfaceNumber);
diff --git a/drivers/hid/usbhid/usbkbd.c b/drivers/hid/usbhid/usbkbd.c
index 6b33e6ad0846..83d4df0d7a45 100644
--- a/drivers/hid/usbhid/usbkbd.c
+++ b/drivers/hid/usbhid/usbkbd.c
@@ -20,6 +20,7 @@
#include <linux/init.h>
#include <linux/usb/input.h>
#include <linux/hid.h>
+#include <linux/seq_buf.h>
/*
* Version Information
@@ -266,8 +267,10 @@ static int usb_kbd_probe(struct usb_interface *iface,
struct usb_endpoint_descriptor *endpoint;
struct usb_kbd *kbd;
struct input_dev *input_dev;
+ struct seq_buf kbd_name;
int i, pipe, maxp;
int error = -ENOMEM;
+ size_t len;
interface = iface->cur_altsetting;
@@ -292,24 +295,26 @@ static int usb_kbd_probe(struct usb_interface *iface,
kbd->usbdev = dev;
kbd->dev = input_dev;
spin_lock_init(&kbd->leds_lock);
+ seq_buf_init(&kbd_name, kbd->name, sizeof(kbd->name));
if (dev->manufacturer)
- strscpy(kbd->name, dev->manufacturer, sizeof(kbd->name));
+ seq_buf_puts(&kbd_name, dev->manufacturer);
if (dev->product) {
if (dev->manufacturer)
- strlcat(kbd->name, " ", sizeof(kbd->name));
- strlcat(kbd->name, dev->product, sizeof(kbd->name));
+ seq_buf_puts(&kbd_name, " ");
+ seq_buf_puts(&kbd_name, dev->product);
}
- if (!strlen(kbd->name))
+ if (!seq_buf_used(&kbd_name))
snprintf(kbd->name, sizeof(kbd->name),
"USB HIDBP Keyboard %04x:%04x",
le16_to_cpu(dev->descriptor.idVendor),
le16_to_cpu(dev->descriptor.idProduct));
usb_make_path(dev, kbd->phys, sizeof(kbd->phys));
- strlcat(kbd->phys, "/input0", sizeof(kbd->phys));
+ len = strnlen(kbd->phys, sizeof(kbd->phys));
+ strscpy(kbd->phys + len, "/input0", sizeof(kbd->phys) - len);
input_dev->name = kbd->name;
input_dev->phys = kbd->phys;
diff --git a/drivers/hid/usbhid/usbmouse.c b/drivers/hid/usbhid/usbmouse.c
index 7cc4f9558e5f..b3b2abeee614 100644
--- a/drivers/hid/usbhid/usbmouse.c
+++ b/drivers/hid/usbhid/usbmouse.c
@@ -18,6 +18,7 @@
#include <linux/init.h>
#include <linux/usb/input.h>
#include <linux/hid.h>
+#include <linux/seq_buf.h>
/* for apple IDs */
#ifdef CONFIG_USB_HID_MODULE
@@ -110,8 +111,10 @@ static int usb_mouse_probe(struct usb_interface *intf, const struct usb_device_i
struct usb_endpoint_descriptor *endpoint;
struct usb_mouse *mouse;
struct input_dev *input_dev;
+ struct seq_buf mouse_name;
int pipe, maxp;
int error = -ENOMEM;
+ size_t len;
interface = intf->cur_altsetting;
@@ -140,24 +143,26 @@ static int usb_mouse_probe(struct usb_interface *intf, const struct usb_device_i
mouse->usbdev = dev;
mouse->dev = input_dev;
+ seq_buf_init(&mouse_name, mouse->name, sizeof(mouse->name));
if (dev->manufacturer)
- strscpy(mouse->name, dev->manufacturer, sizeof(mouse->name));
+ seq_buf_puts(&mouse_name, dev->manufacturer);
if (dev->product) {
if (dev->manufacturer)
- strlcat(mouse->name, " ", sizeof(mouse->name));
- strlcat(mouse->name, dev->product, sizeof(mouse->name));
+ seq_buf_puts(&mouse_name, " ");
+ seq_buf_puts(&mouse_name, dev->product);
}
- if (!strlen(mouse->name))
+ if (!seq_buf_used(&mouse_name))
snprintf(mouse->name, sizeof(mouse->name),
"USB HIDBP Mouse %04x:%04x",
le16_to_cpu(dev->descriptor.idVendor),
le16_to_cpu(dev->descriptor.idProduct));
usb_make_path(dev, mouse->phys, sizeof(mouse->phys));
- strlcat(mouse->phys, "/input0", sizeof(mouse->phys));
+ len = strnlen(mouse->phys, sizeof(mouse->phys));
+ strscpy(mouse->phys + len, "/input0", sizeof(mouse->phys) - len);
input_dev->name = mouse->name;
input_dev->phys = mouse->phys;
--
2.39.5
^ permalink raw reply related
* Re: [PATCH] thunderbolt: debugfs: Don't stop reading SB registers if just one fails
From: Konrad Dybcio @ 2026-04-10 17:27 UTC (permalink / raw)
To: Mika Westerberg
Cc: Konrad Dybcio, Andreas Noever, Mika Westerberg, Yehezkel Bernat,
usb4-upstream, linux-usb, linux-kernel
In-Reply-To: <20260410151007.GM3552@black.igk.intel.com>
On 4/10/26 5:10 PM, Mika Westerberg wrote:
> On Fri, Apr 10, 2026 at 04:43:54PM +0200, Konrad Dybcio wrote:
>> On 4/10/26 4:29 PM, Konrad Dybcio wrote:
>>> On 4/9/26 4:32 PM, Mika Westerberg wrote:
>>>> On Thu, Apr 09, 2026 at 02:59:22PM +0200, Konrad Dybcio wrote:
>>>>> On 4/9/26 2:04 PM, Mika Westerberg wrote:
>>>
>>> [...]
>>>
>>>>>> I assume you have tested this on a hardware that supports this too, right?
>>>>>
>>>>> Hardware that exposes that register this does not exercise the altered
>>>>> code path.
>>>>
>>>> Well it may happen now that previously we got -EIO from some other register
>>>> and we stopped there, now this changes and we actually continue reading so
>>>> this definitely should be tested.
>>>
>>> The only register before USB4_SB_GEN4_TXFFE that isn't in-spec for
>>> both retimers in v1.0 and v2.0 is USB4_SB_LRD_TUNING (0x07). The PS8830
>>> interestingly reports all zeroes (not a bounce).
>>>
>>> The registers following USB4_SB_GEN4_TXFFE in the array are
>>> USB4_SB_VERSION and USB4_SB_DATA. The former is not accessed anywhere
>>> else in the code, at first glance. The latter is, during NVM r/w and
>>> in margining ops, which have definitely been in use for a long time.
>>>
>>> Plus both of them are the v1.0 spec. The USB4_SB_GEN4_TXFFE specifically
>>> isn't (the retimer supplement pdf lists it as Rsvd, the main spec pdf
>>> omits it in the SB register table), as it wasn't previously useful (since
>>> Gen4 came about in v2.0).
>>>
>>>
>>> I don't think there's an easy way to limit the reading of this register
>>> since the bit indicating Gen4 capability is in USB4_SB_LINK_CONF (0x0c),
>>> which is Rsvd on retimers regardless of the spec revision. A connected
>>> port could easily have higher/lower capabilities, too.
>>
>> Checked again, the USB4_SB_FW_VERSION (0x02) register's lowest 8 bytes
>> are 0/1 for retimers implementing USB4v1 and 2 for v2, so we may go this
>> path too
>
> I also checked from Retimer 1.0 spec and there it is still "Reserved. May
> have non-zero value". Probably not good to rely on that.
In Table 4-3 below that definition, it says:
"""
Shall be set to 00h or 01h
It is recommended that this field be set to 01h.
"""
But we can revisit limiting those reads another day
Konrad
^ permalink raw reply
* [Bug 221340] uas driver hangs and causes usb reset
From: bugzilla-daemon @ 2026-04-10 16:45 UTC (permalink / raw)
To: linux-usb
In-Reply-To: <bug-221340-208809@https.bugzilla.kernel.org/>
https://bugzilla.kernel.org/show_bug.cgi?id=221340
--- Comment #4 from DaisyTheFoxxo@proton.me ---
(In reply to Michał Pecio from comment #3)
> There is also Unmap/Read sub-channel in this log.
>
> By "hang", do you mean that no I/O happens for 30 seconds or some other time
> before these messages show up?
yes
>
> BTW, if you run (as root)
> echo 'func handle_tx_event +p' >/proc/dynamic_debug/control
>
> do you see anything new appear in dmesg at this time?
>
> That would point to some "action" at xHCI layer, though I suppose it's also
> possible that nothing interesting happens and the device simply never
> responds to some commands under some circumstances.
I have been having difficulties reproducing the bug recently, I will let you
know when it happens again
--
You may reply to this email to add a comment.
You are receiving this mail because:
You are watching the assignee of the bug.
^ permalink raw reply
* Re: [PATCH 04/61] ext4: Prefer IS_ERR_OR_NULL over manual NULL check
From: Theodore Ts'o @ 2026-04-10 15:18 UTC (permalink / raw)
To: amd-gfx, apparmor, bpf, ceph-devel, cocci, dm-devel, dri-devel,
gfs2, intel-gfx, intel-wired-lan, iommu, kvm, linux-arm-kernel,
linux-block, linux-bluetooth, linux-btrfs, linux-cifs, linux-clk,
linux-erofs, linux-ext4, linux-fsdevel, linux-gpio, linux-hyperv,
linux-input, linux-kernel, linux-leds, linux-media, linux-mips,
linux-mm, linux-modules, linux-mtd, linux-nfs, linux-omap,
linux-phy, linux-pm, linux-rockchip, linux-s390, linux-scsi,
linux-sctp, linux-security-module, linux-sh, linux-sound,
linux-stm32, linux-trace-kernel, linux-usb, linux-wireless,
netdev, ntfs3, samba-technical, sched-ext, target-devel,
tipc-discussion, v9fs, Philipp Hahn
Cc: Theodore Ts'o, Andreas Dilger
In-Reply-To: <20260310-b4-is_err_or_null-v1-4-bd63b656022d@avm.de>
On Tue, 10 Mar 2026 12:48:30 +0100, Philipp Hahn wrote:
> Prefer using IS_ERR_OR_NULL() over using IS_ERR() and a manual NULL
> check.
>
> Change generated with coccinelle.
Applied, thanks!
[04/61] ext4: Prefer IS_ERR_OR_NULL over manual NULL check
commit: 1d749e110277ce4103f27bd60d6181e52c0cc1e3
Best regards,
--
Theodore Ts'o <tytso@mit.edu>
^ permalink raw reply
* Re: [PATCH] thunderbolt: debugfs: Don't stop reading SB registers if just one fails
From: Mika Westerberg @ 2026-04-10 15:10 UTC (permalink / raw)
To: Konrad Dybcio
Cc: Konrad Dybcio, Andreas Noever, Mika Westerberg, Yehezkel Bernat,
usb4-upstream, linux-usb, linux-kernel
In-Reply-To: <f1af27b6-e166-46b9-91d3-5e293fd6d74b@oss.qualcomm.com>
On Fri, Apr 10, 2026 at 04:43:54PM +0200, Konrad Dybcio wrote:
> On 4/10/26 4:29 PM, Konrad Dybcio wrote:
> > On 4/9/26 4:32 PM, Mika Westerberg wrote:
> >> On Thu, Apr 09, 2026 at 02:59:22PM +0200, Konrad Dybcio wrote:
> >>> On 4/9/26 2:04 PM, Mika Westerberg wrote:
> >
> > [...]
> >
> >>>> I assume you have tested this on a hardware that supports this too, right?
> >>>
> >>> Hardware that exposes that register this does not exercise the altered
> >>> code path.
> >>
> >> Well it may happen now that previously we got -EIO from some other register
> >> and we stopped there, now this changes and we actually continue reading so
> >> this definitely should be tested.
> >
> > The only register before USB4_SB_GEN4_TXFFE that isn't in-spec for
> > both retimers in v1.0 and v2.0 is USB4_SB_LRD_TUNING (0x07). The PS8830
> > interestingly reports all zeroes (not a bounce).
> >
> > The registers following USB4_SB_GEN4_TXFFE in the array are
> > USB4_SB_VERSION and USB4_SB_DATA. The former is not accessed anywhere
> > else in the code, at first glance. The latter is, during NVM r/w and
> > in margining ops, which have definitely been in use for a long time.
> >
> > Plus both of them are the v1.0 spec. The USB4_SB_GEN4_TXFFE specifically
> > isn't (the retimer supplement pdf lists it as Rsvd, the main spec pdf
> > omits it in the SB register table), as it wasn't previously useful (since
> > Gen4 came about in v2.0).
> >
> >
> > I don't think there's an easy way to limit the reading of this register
> > since the bit indicating Gen4 capability is in USB4_SB_LINK_CONF (0x0c),
> > which is Rsvd on retimers regardless of the spec revision. A connected
> > port could easily have higher/lower capabilities, too.
>
> Checked again, the USB4_SB_FW_VERSION (0x02) register's lowest 8 bytes
> are 0/1 for retimers implementing USB4v1 and 2 for v2, so we may go this
> path too
I also checked from Retimer 1.0 spec and there it is still "Reserved. May
have non-zero value". Probably not good to rely on that.
^ permalink raw reply
* Re: [PATCH v7 1/2] arm64: dts: qcom: glymur: Add USB related nodes
From: Rob Herring @ 2026-04-10 14:52 UTC (permalink / raw)
To: Abel Vesa
Cc: Bjorn Andersson, Konrad Dybcio, Krzysztof Kozlowski, Conor Dooley,
Greg Kroah-Hartman, Wesley Cheng, Pankaj Patil, linux-arm-msm,
devicetree, linux-kernel, linux-usb, Wesley Cheng, Konrad Dybcio,
Dmitry Baryshkov
In-Reply-To: <20260320-dts-qcom-glymur-add-usb-support-v7-1-ba367eda6010@oss.qualcomm.com>
On Fri, Mar 20, 2026 at 12:56:52PM +0200, Abel Vesa wrote:
> From: Wesley Cheng <wesley.cheng@oss.qualcomm.com>
>
> The Glymur USB subsystem contains three USB 3.2 Gen 2 controllers,
> one USB 3.2 multi-port controller, and one USB 2.0-only controller.
> This includes five SS USB QMP PHYs (three combo and two UNI) and six M31
> eUSB2 PHYs.
>
> All controllers are based on SNPS DWC3, so describe them as Qualcomm
> flattened DWC3 nodes.
>
> Signed-off-by: Wesley Cheng <wesley.cheng@oss.qualcomm.com>
> Co-developed-by: Abel Vesa <abel.vesa@oss.qualcomm.com>
> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
> Tested-by: Pankaj Patil <pankaj.patil@oss.qualcomm.com>
> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
> Signed-off-by: Abel Vesa <abel.vesa@oss.qualcomm.com>
> ---
> arch/arm64/boot/dts/qcom/glymur.dtsi | 691 ++++++++++++++++++++++++++++++++++-
> 1 file changed, 686 insertions(+), 5 deletions(-)
>
> diff --git a/arch/arm64/boot/dts/qcom/glymur.dtsi b/arch/arm64/boot/dts/qcom/glymur.dtsi
> index bde287f645ee..641707ba1e78 100644
> --- a/arch/arm64/boot/dts/qcom/glymur.dtsi
> +++ b/arch/arm64/boot/dts/qcom/glymur.dtsi
> @@ -750,11 +750,11 @@ gcc: clock-controller@100000 {
> <0>, /* UFS PHY RX Symbol 0 */
> <0>, /* UFS PHY RX Symbol 1 */
> <0>, /* UFS PHY TX Symbol 0 */
> - <0>, /* USB3 PHY 0 */
> - <0>, /* USB3 PHY 1 */
> - <0>, /* USB3 PHY 2 */
> - <0>, /* USB3 UNI PHY pipe 0 */
> - <0>, /* USB3 UNI PHY pipe 1 */
> + <&usb_0_qmpphy QMP_USB43DP_USB3_PIPE_CLK>,
> + <&usb_1_qmpphy QMP_USB43DP_USB3_PIPE_CLK>,
> + <&usb_2_qmpphy QMP_USB43DP_USB3_PIPE_CLK>,
> + <&usb_mp_qmpphy0 QMP_USB43DP_USB3_PIPE_CLK>,
> + <&usb_mp_qmpphy1 QMP_USB43DP_USB3_PIPE_CLK>,
> <0>, /* USB4 PHY 0 pcie pipe */
> <0>, /* USB4 PHY 0 Max pipe */
> <0>, /* USB4 PHY 1 pcie pipe */
> @@ -2264,6 +2264,254 @@ &config_noc SLAVE_QUP_0 QCOM_ICC_TAG_ALWAYS>,
> };
> };
>
> + usb_hs_phy: phy@fa0000 {
> + compatible = "qcom,glymur-m31-eusb2-phy",
> + "qcom,sm8750-m31-eusb2-phy";
> + reg = <0x0 0x00fa0000 0x0 0x154>;
> + #phy-cells = <0>;
> +
> + clocks = <&tcsr TCSR_USB2_1_CLKREF_EN>;
> + clock-names = "ref";
> +
> + resets = <&gcc GCC_QUSB2PHY_USB20_HS_BCR>;
> +
> + status = "disabled";
> + };
> +
> + usb_mp_hsphy0: phy@fa1000 {
> + compatible = "qcom,glymur-m31-eusb2-phy",
> + "qcom,sm8750-m31-eusb2-phy";
> +
> + reg = <0x0 0x00fa1000 0x0 0x29c>;
> + #phy-cells = <0>;
> +
> + clocks = <&tcsr TCSR_USB2_1_CLKREF_EN>;
> + clock-names = "ref";
> +
> + resets = <&gcc GCC_QUSB2PHY_HS0_MP_BCR>;
> +
> + status = "disabled";
> + };
> +
> + usb_mp_hsphy1: phy@fa2000 {
> + compatible = "qcom,glymur-m31-eusb2-phy",
> + "qcom,sm8750-m31-eusb2-phy";
> +
> + reg = <0x0 0x00fa2000 0x0 0x29c>;
> + #phy-cells = <0>;
> +
> + clocks = <&tcsr TCSR_USB2_2_CLKREF_EN>;
> + clock-names = "ref";
> +
> + resets = <&gcc GCC_QUSB2PHY_HS1_MP_BCR>;
> +
> + status = "disabled";
> + };
> +
> + usb_mp_qmpphy0: phy@fa3000 {
> + compatible = "qcom,glymur-qmp-usb3-uni-phy";
> + reg = <0x0 0x00fa3000 0x0 0x2000>;
> +
> + clocks = <&gcc GCC_USB3_MP_PHY_AUX_CLK>,
> + <&tcsr TCSR_USB3_0_CLKREF_EN>,
> + <&rpmhcc RPMH_CXO_CLK>,
> + <&gcc GCC_USB3_MP_PHY_COM_AUX_CLK>,
> + <&gcc GCC_USB3_MP_PHY_PIPE_0_CLK>;
> + clock-names = "aux",
> + "clkref",
> + "ref",
> + "com_aux",
> + "pipe";
> +
> + power-domains = <&gcc GCC_USB3_MP_SS0_PHY_GDSC>;
> +
> + resets = <&gcc GCC_USB3_MP_SS0_PHY_BCR>,
> + <&gcc GCC_USB3UNIPHY_PHY_MP0_BCR>;
> + reset-names = "phy",
> + "phy_phy";
> +
> + clock-output-names = "usb3_uni_phy_0_pipe_clk_src";
> + #clock-cells = <0>;
> + #phy-cells = <0>;
> +
> + status = "disabled";
> + };
> +
> + usb_mp_qmpphy1: phy@fa5000 {
> + compatible = "qcom,glymur-qmp-usb3-uni-phy";
> + reg = <0x0 0x00fa5000 0x0 0x2000>;
> +
> + clocks = <&gcc GCC_USB3_MP_PHY_AUX_CLK>,
> + <&tcsr TCSR_USB3_1_CLKREF_EN>,
> + <&rpmhcc RPMH_CXO_CLK>,
> + <&gcc GCC_USB3_MP_PHY_COM_AUX_CLK>,
> + <&gcc GCC_USB3_MP_PHY_PIPE_1_CLK>;
> + clock-names = "aux",
> + "clkref",
> + "ref",
> + "com_aux",
> + "pipe";
New warnings:
4 (qcom,glymur-qmp-usb3-uni-phy): clock-names: ['aux', 'clkref', 'ref', 'com_aux', 'pipe'] is too long
4 (qcom,glymur-qmp-usb3-uni-phy): clock-names:3: 'pipe' was expected
4 (qcom,glymur-qmp-usb3-uni-phy): clock-names:2: 'com_aux' was expected
4 (qcom,glymur-qmp-usb3-uni-phy): clock-names:1: 'ref' was expected
1 (qcom,glymur-qmp-usb3-uni-phy): clocks: [[70, 329], [42, 9], [58, 0], [70, 331], [70, 332]] is too long
1 (qcom,glymur-qmp-usb3-uni-phy): clocks: [[70, 329], [42, 10], [58, 0], [70, 331], [70, 334]] is too long
1 (qcom,glymur-qmp-usb3-uni-phy): clocks: [[56, 329], [29, 9], [44, 0], [56, 331], [56, 332]] is too long
1 (qcom,glymur-qmp-usb3-uni-phy): clocks: [[56, 329], [29, 10], [44, 0], [56, 331], [56, 334]] is too long
You did test this series for DT warnings before sending, right? Please
fix and ensure they get into 7.1.
Rob
^ permalink raw reply
* Re: [PATCH] thunderbolt: debugfs: Don't stop reading SB registers if just one fails
From: Mika Westerberg @ 2026-04-10 14:44 UTC (permalink / raw)
To: Konrad Dybcio
Cc: Konrad Dybcio, Andreas Noever, Mika Westerberg, Yehezkel Bernat,
usb4-upstream, linux-usb, linux-kernel
In-Reply-To: <7d65539f-ece6-4e7c-a13e-6b12920346fa@oss.qualcomm.com>
On Fri, Apr 10, 2026 at 04:29:43PM +0200, Konrad Dybcio wrote:
> On 4/9/26 4:32 PM, Mika Westerberg wrote:
> > On Thu, Apr 09, 2026 at 02:59:22PM +0200, Konrad Dybcio wrote:
> >> On 4/9/26 2:04 PM, Mika Westerberg wrote:
>
> [...]
>
> >>> I assume you have tested this on a hardware that supports this too, right?
> >>
> >> Hardware that exposes that register this does not exercise the altered
> >> code path.
> >
> > Well it may happen now that previously we got -EIO from some other register
> > and we stopped there, now this changes and we actually continue reading so
> > this definitely should be tested.
>
> The only register before USB4_SB_GEN4_TXFFE that isn't in-spec for
> both retimers in v1.0 and v2.0 is USB4_SB_LRD_TUNING (0x07). The PS8830
> interestingly reports all zeroes (not a bounce).
>
> The registers following USB4_SB_GEN4_TXFFE in the array are
> USB4_SB_VERSION and USB4_SB_DATA. The former is not accessed anywhere
> else in the code, at first glance. The latter is, during NVM r/w and
> in margining ops, which have definitely been in use for a long time.
>
> Plus both of them are the v1.0 spec. The USB4_SB_GEN4_TXFFE specifically
> isn't (the retimer supplement pdf lists it as Rsvd, the main spec pdf
> omits it in the SB register table), as it wasn't previously useful (since
> Gen4 came about in v2.0).
>
>
> I don't think there's an easy way to limit the reading of this register
> since the bit indicating Gen4 capability is in USB4_SB_LINK_CONF (0x0c),
> which is Rsvd on retimers regardless of the spec revision. A connected
> port could easily have higher/lower capabilities, too.
Agree.
> So all in all, my understanding is that any bugs caused by this patch
> (which would have to be in the form of "reading a register causes a
> wrongful change in behavior") would really surface spec non-compliance
> from a retimer, which should be quirked out explicitly if that's the
> case.
Right. Also given the fact that this is debugfs access so not anything we
would do during normal operations, likelihood of this causing issues for
regular user should be pretty low.
> I only have hardware with various Parade retimers, none of which claim
> Gen4 support.
Okay I can give the next version a try on my test systems to make sure
there are no surprises. I should have a pretty extensive variation of
retimers (v1, v2 and pre-USB4).
^ permalink raw reply
* Re: [PATCH] thunderbolt: debugfs: Don't stop reading SB registers if just one fails
From: Konrad Dybcio @ 2026-04-10 14:43 UTC (permalink / raw)
To: Mika Westerberg
Cc: Konrad Dybcio, Andreas Noever, Mika Westerberg, Yehezkel Bernat,
usb4-upstream, linux-usb, linux-kernel
In-Reply-To: <7d65539f-ece6-4e7c-a13e-6b12920346fa@oss.qualcomm.com>
On 4/10/26 4:29 PM, Konrad Dybcio wrote:
> On 4/9/26 4:32 PM, Mika Westerberg wrote:
>> On Thu, Apr 09, 2026 at 02:59:22PM +0200, Konrad Dybcio wrote:
>>> On 4/9/26 2:04 PM, Mika Westerberg wrote:
>
> [...]
>
>>>> I assume you have tested this on a hardware that supports this too, right?
>>>
>>> Hardware that exposes that register this does not exercise the altered
>>> code path.
>>
>> Well it may happen now that previously we got -EIO from some other register
>> and we stopped there, now this changes and we actually continue reading so
>> this definitely should be tested.
>
> The only register before USB4_SB_GEN4_TXFFE that isn't in-spec for
> both retimers in v1.0 and v2.0 is USB4_SB_LRD_TUNING (0x07). The PS8830
> interestingly reports all zeroes (not a bounce).
>
> The registers following USB4_SB_GEN4_TXFFE in the array are
> USB4_SB_VERSION and USB4_SB_DATA. The former is not accessed anywhere
> else in the code, at first glance. The latter is, during NVM r/w and
> in margining ops, which have definitely been in use for a long time.
>
> Plus both of them are the v1.0 spec. The USB4_SB_GEN4_TXFFE specifically
> isn't (the retimer supplement pdf lists it as Rsvd, the main spec pdf
> omits it in the SB register table), as it wasn't previously useful (since
> Gen4 came about in v2.0).
>
>
> I don't think there's an easy way to limit the reading of this register
> since the bit indicating Gen4 capability is in USB4_SB_LINK_CONF (0x0c),
> which is Rsvd on retimers regardless of the spec revision. A connected
> port could easily have higher/lower capabilities, too.
Checked again, the USB4_SB_FW_VERSION (0x02) register's lowest 8 bytes
are 0/1 for retimers implementing USB4v1 and 2 for v2, so we may go this
path too
Konrad
^ permalink raw reply
* Re: [PATCH] thunderbolt: debugfs: Don't stop reading SB registers if just one fails
From: Konrad Dybcio @ 2026-04-10 14:29 UTC (permalink / raw)
To: Mika Westerberg
Cc: Konrad Dybcio, Andreas Noever, Mika Westerberg, Yehezkel Bernat,
usb4-upstream, linux-usb, linux-kernel
In-Reply-To: <20260409143203.GI3552@black.igk.intel.com>
On 4/9/26 4:32 PM, Mika Westerberg wrote:
> On Thu, Apr 09, 2026 at 02:59:22PM +0200, Konrad Dybcio wrote:
>> On 4/9/26 2:04 PM, Mika Westerberg wrote:
[...]
>>> I assume you have tested this on a hardware that supports this too, right?
>>
>> Hardware that exposes that register this does not exercise the altered
>> code path.
>
> Well it may happen now that previously we got -EIO from some other register
> and we stopped there, now this changes and we actually continue reading so
> this definitely should be tested.
The only register before USB4_SB_GEN4_TXFFE that isn't in-spec for
both retimers in v1.0 and v2.0 is USB4_SB_LRD_TUNING (0x07). The PS8830
interestingly reports all zeroes (not a bounce).
The registers following USB4_SB_GEN4_TXFFE in the array are
USB4_SB_VERSION and USB4_SB_DATA. The former is not accessed anywhere
else in the code, at first glance. The latter is, during NVM r/w and
in margining ops, which have definitely been in use for a long time.
Plus both of them are the v1.0 spec. The USB4_SB_GEN4_TXFFE specifically
isn't (the retimer supplement pdf lists it as Rsvd, the main spec pdf
omits it in the SB register table), as it wasn't previously useful (since
Gen4 came about in v2.0).
I don't think there's an easy way to limit the reading of this register
since the bit indicating Gen4 capability is in USB4_SB_LINK_CONF (0x0c),
which is Rsvd on retimers regardless of the spec revision. A connected
port could easily have higher/lower capabilities, too.
So all in all, my understanding is that any bugs caused by this patch
(which would have to be in the form of "reading a register causes a
wrongful change in behavior") would really surface spec non-compliance
from a retimer, which should be quirked out explicitly if that's the
case.
I only have hardware with various Parade retimers, none of which claim
Gen4 support.
Konrad
^ permalink raw reply
* [GIT PULL] USB serial updates for 7.1-rc1
From: Johan Hovold @ 2026-04-10 12:44 UTC (permalink / raw)
To: Greg Kroah-Hartman; +Cc: linux-usb, linux-kernel
The following changes since commit f338e77383789c0cae23ca3d48adcc5e9e137e3c:
Linux 7.0-rc4 (2026-03-15 13:52:05 -0700)
are available in the Git repository at:
https://git.kernel.org/pub/scm/linux/kernel/git/johan/usb-serial.git tags/usb-serial-7.1-rc1
for you to fetch changes up to 37d9c4c055c3b3357c61dba2335ab21340e33553:
USB: serial: iuu_phoenix: fix iuutool author name (2026-04-08 09:37:43 +0200)
----------------------------------------------------------------
USB serial updates for 7.1-rc1
Here are the USB serial updates for 7.1-rc1, including:
- use strscpy() instead of strcpy()
- new modem device id
All have been in linux-next with no reported issues.
----------------------------------------------------------------
Ai Chao (1):
USB: serial: ti_usb_3410_5052: use strscpy() instead of strcpy()
Fabio Porcedda (1):
USB: serial: option: add Telit Cinterion FN990A MBIM composition
Thorsten Blum (1):
USB: serial: iuu_phoenix: fix iuutool author name
drivers/usb/serial/iuu_phoenix.c | 2 +-
drivers/usb/serial/option.c | 2 ++
drivers/usb/serial/ti_usb_3410_5052.c | 16 ++++++++--------
3 files changed, 11 insertions(+), 9 deletions(-)
^ permalink raw reply
* Re: [PATCH v1 1/2] dt-bindings: usb: dwc3: add support for StarFive JHB100
From: Minda Chen @ 2026-04-10 11:28 UTC (permalink / raw)
To: Conor Dooley, Greg Kroah-Hartman, Thinh Nguyen
Cc: Rob Herring, Krzysztof Kozlowski, linux-usb@vger.kernel.org,
linux-kernel@vger.kernel.org, devicetree@vger.kernel.org
In-Reply-To: <20260409-perish-speckled-1da7daabca31@spud>
> 主题: Re: [PATCH v1 1/2] dt-bindings: usb: dwc3: add support for StarFive JHB100
>
> Acked-by: Conor Dooley <conor.dooley@microchip.com>
> pw-bot: not-applicable
Thanks Conor
Hi Thinh
Could you review patch2? Just add a compatible to generic platform driver. Thanks
Hi Greg
Can this patch-set be merged in v7.1? Thanks
^ permalink raw reply
* [PATCH v2 1/2] dt-bindings: usb: dwc3: add support for StarFive JHB100
From: Minda Chen @ 2026-04-10 11:24 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: <20260410112500.90432-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>
Acked-by: Conor Dooley <conor.dooley@microchip.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 v2 0/2] Add StarFive JHB100 soc BMC DRD USB support
From: Minda Chen @ 2026-04-10 11:24 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 integrated 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
changes form v1:
1. Add review tag to patch1
2.v1 patch 2 delte one more line, v2 just add device compatible.
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 | 1 +
3 files changed, 67 insertions(+), 1 deletion(-)
create mode 100644 Documentation/devicetree/bindings/usb/starfive,jhb100-dwc3.yaml
base-commit: c369299895a591d96745d6492d4888259b004a9e
--
2.17.1
^ permalink raw reply
* [PATCH v2 2/2] usb: dwc3: starfive: Add JHB100 USB 2.0 DRD controller
From: Minda Chen @ 2026-04-10 11:25 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: <20260410112500.90432-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 | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/usb/dwc3/dwc3-generic-plat.c b/drivers/usb/dwc3/dwc3-generic-plat.c
index e846844e0023..e9e29b63aaa4 100644
--- a/drivers/usb/dwc3/dwc3-generic-plat.c
+++ b/drivers/usb/dwc3/dwc3-generic-plat.c
@@ -214,6 +214,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: [GIT PULL] USB4/Thunderbolt changes for v7.1 merge window
From: Greg Kroah-Hartman @ 2026-04-10 11:17 UTC (permalink / raw)
To: Mika Westerberg; +Cc: Yehezkel Bernat, Lukas Wunner, Andreas Noever, linux-usb
In-Reply-To: <20260410062553.GK3552@black.igk.intel.com>
On Fri, Apr 10, 2026 at 08:25:53AM +0200, Mika Westerberg wrote:
> Hi Greg,
>
> The following changes since commit 11439c4635edd669ae435eec308f4ab8a0804808:
>
> Linux 7.0-rc2 (2026-03-01 15:39:31 -0800)
>
> are available in the Git repository at:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/westeri/thunderbolt.git tags/thunderbolt-for-v7.1-rc1
Pulled and pushed out, thanks.
greg k-h
^ permalink raw reply
* [bug report] usb: gadget: f_hid: don't call cdev_init while cdev in use
From: Dan Carpenter @ 2026-04-10 10:15 UTC (permalink / raw)
To: Michael Zimmermann; +Cc: linux-usb
Hello Michael Zimmermann,
Commit 81ebd43cc0d6 ("usb: gadget: f_hid: don't call cdev_init while
cdev in use") from Mar 27, 2026 (linux-next), leads to the following
Smatch static checker warning:
drivers/usb/gadget/function/f_hid.c:1282 hidg_bind()
warn: missing error code here? 'cdev_alloc()' failed. 'status' = '0'
drivers/usb/gadget/function/f_hid.c
1263 if (status)
1264 goto fail;
1265
1266 hidg->write_pending = 1;
1267 hidg->req = NULL;
1268
1269 INIT_WORK(&hidg->work, get_report_workqueue_handler);
1270 hidg->workqueue = alloc_workqueue("report_work",
1271 WQ_FREEZABLE | WQ_MEM_RECLAIM | WQ_PERCPU,
1272 1);
1273
1274 if (!hidg->workqueue) {
1275 status = -ENOMEM;
1276 goto fail_free_descs;
1277 }
1278
1279 /* create char device */
1280 hidg->cdev = cdev_alloc();
1281 if (!hidg->cdev)
--> 1282 goto fail_free_all;
status = -ENOMEM;
1283 hidg->cdev->ops = &f_hidg_fops;
1284
1285 status = cdev_device_add(hidg->cdev, &hidg->dev);
1286 if (status)
1287 goto fail_free_all;
1288
1289 return 0;
1290 fail_free_all:
1291 destroy_workqueue(hidg->workqueue);
1292 fail_free_descs:
1293 usb_free_all_descriptors(f);
1294 fail:
1295 ERROR(f->config->cdev, "hidg_bind FAILED\n");
1296 if (hidg->req != NULL)
1297 free_ep_req(hidg->in_ep, hidg->req);
1298
1299 usb_ep_free_request(c->cdev->gadget->ep0, hidg->get_req);
1300 hidg->get_req = NULL;
1301
1302 return status;
1303 }
This email is a free service from the Smatch-CI project [smatch.sf.net].
regards,
dan carpenter
^ permalink raw reply
* Re: [PATCH v2 1/2] mfd: nct6694: Switch to devm_mfd_add_devices() and drop IDA
From: Ming Yu @ 2026-04-10 9:59 UTC (permalink / raw)
To: Bartosz Golaszewski
Cc: tmyu0, linusw, linux, andi.shyti, lee, mkl, mailhol,
alexandre.belloni, wim, linux-kernel, linux-gpio, linux-i2c,
linux-can, netdev, linux-watchdog, linux-hwmon, linux-rtc,
linux-usb
In-Reply-To: <CAMRc=MeJL_po8HuBa4btVowR-e0i2FyzbDgNVo2u54iPKyuvWw@mail.gmail.com>
Hi Bart, all,
Thanks for the review.
Bartosz Golaszewski <brgl@kernel.org> 於 2026年4月8日週三 下午3:25寫道：
>
> On Wed, Apr 8, 2026 at 7:31 AM <a0282524688@gmail.com> wrote:
> >
> > From: Ming Yu <a0282524688@gmail.com>
> >
> > Currently, the nct6694 core driver uses mfd_add_hotplug_devices()
> > and an IDA to manage subdevice IDs.
> >
> > Switch the core implementation to use the managed
> > devm_mfd_add_devices() API, which simplifies the error handling and
> > device lifecycle management. Concurrently, drop the custom IDA
> > implementation and transition to using pdev->id.
> >
> > Signed-off-by: Ming Yu <a0282524688@gmail.com>
> > ---
>
> This does result in a nice code shrink but I'd split this commit into
> two: one switching to using MFD_CELL_BASIC() with hard-coded devices
> IDs and one completing the transition to devres.
>
You are right that this change is trying to do too much at once, and
splitting it as you suggested would make the series much cleaner.
After looking more closely at the ID handling and hotplug
implications, I realized that switching to devm_mfd_add_devices() and
dropping the IDA is not a good fit for this driver. The current
mfd_add_hotplug_devices() path uses PLATFORM_DEVID_AUTO, which gives
globally unique device IDs and avoids sysfs name collisions. If we
switch to devm_mfd_add_devices() with fixed IDs, multiple identical
NCT6694 devices can end up registering subdevices with the same
platform device names, which would break hotplug support when more
than one device is present.
So I think it is better not to pursue this direction further.
For the next revision, I will drop this part of the change and keep
the existing MFD core logic, including the IDA usage. The series will
focus on adding the nct6694-hif MFD driver only, and I will add the
IDA initialization there as needed.
Thanks again for the suggestion and review.
Best regards,
Ming
^ permalink raw reply
* [PATCH] usb: dwc3: Fix GUID register programming order
From: Selvarasu Ganesan @ 2026-04-10 6:47 UTC (permalink / raw)
To: Thinh.Nguyen, gregkh, paulz, balbi, linux-usb, linux-kernel
Cc: jh0801.jung, akash.m5, h10.kim, alim.akhtar, thiagu.r,
muhammed.ali, Selvarasu Ganesan, stable, Pritam Manohar Sutar
In-Reply-To: <CGME20260410070245epcas5p49355581dcb9f629641c9914ce4ce80ec@epcas5p4.samsung.com>
The Linux Version Code is currently written to the GUID register before
dwc3_core_soft_reset() is executed. Since the core soft reset clears the
GUID register back to its default value, the version information is
subsequently lost.
Move the GUID register programming to occur after the core soft reset
has completed to ensure the value persists.
Fixes: fa0ea13e9f1c ("usb: dwc3: core: write LINUX_VERSION_CODE to our GUID register")
Cc: stable@vger.kernel.org
Reported-by: Pritam Manohar Sutar <pritam.sutar@samsung.com>
Signed-off-by: Selvarasu Ganesan <selvarasu.g@samsung.com>
---
drivers/usb/dwc3/core.c | 12 ++++++------
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c
index 161a4d58b2cec..0d3c7e7b2262f 100644
--- a/drivers/usb/dwc3/core.c
+++ b/drivers/usb/dwc3/core.c
@@ -1341,12 +1341,6 @@ int dwc3_core_init(struct dwc3 *dwc)
hw_mode = DWC3_GHWPARAMS0_MODE(dwc->hwparams.hwparams0);
- /*
- * Write Linux Version Code to our GUID register so it's easy to figure
- * out which kernel version a bug was found.
- */
- dwc3_writel(dwc, DWC3_GUID, LINUX_VERSION_CODE);
-
ret = dwc3_phy_setup(dwc);
if (ret)
return ret;
@@ -1378,6 +1372,12 @@ int dwc3_core_init(struct dwc3 *dwc)
if (ret)
goto err_exit_phy;
+ /*
+ * Write Linux Version Code to our GUID register so it's easy to figure
+ * out which kernel version a bug was found.
+ */
+ dwc3_writel(dwc, DWC3_GUID, LINUX_VERSION_CODE);
+
dwc3_core_setup_global_control(dwc);
dwc3_core_num_eps(dwc);
--
2.34.1
^ permalink raw reply related
* [GIT PULL] USB4/Thunderbolt changes for v7.1 merge window
From: Mika Westerberg @ 2026-04-10 6:25 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: Yehezkel Bernat, Lukas Wunner, Andreas Noever, linux-usb,
Mika Westerberg
Hi Greg,
The following changes since commit 11439c4635edd669ae435eec308f4ab8a0804808:
Linux 7.0-rc2 (2026-03-01 15:39:31 -0800)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/westeri/thunderbolt.git tags/thunderbolt-for-v7.1-rc1
for you to fetch changes up to 498c05821bb42f70e9bf6512c3dec4aa821815d0:
thunderbolt: tunnel: Simplify allocation (2026-04-07 09:00:26 +0200)
----------------------------------------------------------------
thunderbolt: Changes for v7.1 merge window
This includes following USB4/Thunderbolt changes for the v7.1 merge
window:
- Disable CL-states for Titan Ridge based devices with older firmware.
- MAINTAINER update.
- Simplify allocation of various structures with kzalloc_flex().
All these have been in linux-next with no reported issues.
----------------------------------------------------------------
Dave Hansen (1):
MAINTAINERS: Remove bouncing maintainer, Mika takes over DMA test driver
Rene Sapiens (2):
thunderbolt: Read router NVM version before applying quirks
thunderbolt: Disable CLx on Titan Ridge-based devices with old firmware
Rosen Penev (3):
thunderbolt: dma_port: kmalloc_array + kzalloc to flex
thunderbolt: Use kzalloc_flex() for struct tb_path allocation
thunderbolt: tunnel: Simplify allocation
MAINTAINERS | 2 +-
drivers/thunderbolt/dma_port.c | 15 +++------------
drivers/thunderbolt/path.c | 28 +++++++---------------------
drivers/thunderbolt/quirks.c | 7 +++++++
drivers/thunderbolt/switch.c | 30 ++++++++++++++++++++++++++----
drivers/thunderbolt/tb.h | 5 +++--
drivers/thunderbolt/tunnel.c | 10 ++--------
drivers/thunderbolt/tunnel.h | 5 +++--
8 files changed, 52 insertions(+), 50 deletions(-)
^ permalink raw reply
* Re: [PATCH net-next 2/9] r8152: Add support for RTL8157 SRAM access and ADV indirect access
From: Birger Koblitz @ 2026-04-10 6:11 UTC (permalink / raw)
To: kernel test robot, Andrew Lunn, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni
Cc: llvm, oe-kbuild-all, netdev, linux-usb, linux-kernel
In-Reply-To: <202604101309.B9mdviRN-lkp@intel.com>
On 10/04/2026 07:17, kernel test robot wrote:
> Hi Birger,
>
> kernel test robot noticed the following build warnings:
>
> [auto build test WARNING on 5c9e55fecf9365890c64f14761a80f9413a3b1d1]
>
> url: https://github.com/intel-lab-lkp/linux/commits/Birger-Koblitz/r8152-Add-support-for-RTL8157-RX-TX-descriptor-format/20260315-014044
> base: 5c9e55fecf9365890c64f14761a80f9413a3b1d1
> patch link: https://lore.kernel.org/r/20260314-rtl8157_next-v1-2-9ba77b428afd%40birger-koblitz.de
> patch subject: [PATCH net-next 2/9] r8152: Add support for RTL8157 SRAM access and ADV indirect access
This refers to the initial version of the patch, possibly v1, but v7 was applied, which did not even
have this particular patch. This is probably a configuration issue of what the robot sees.
Birger
^ permalink raw reply
* Re: [PATCH net-next 2/9] r8152: Add support for RTL8157 SRAM access and ADV indirect access
From: kernel test robot @ 2026-04-10 5:17 UTC (permalink / raw)
To: Birger Koblitz, Andrew Lunn, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni
Cc: llvm, oe-kbuild-all, netdev, linux-usb, linux-kernel,
Birger Koblitz
In-Reply-To: <20260314-rtl8157_next-v1-2-9ba77b428afd@birger-koblitz.de>
Hi Birger,
kernel test robot noticed the following build warnings:
[auto build test WARNING on 5c9e55fecf9365890c64f14761a80f9413a3b1d1]
url: https://github.com/intel-lab-lkp/linux/commits/Birger-Koblitz/r8152-Add-support-for-RTL8157-RX-TX-descriptor-format/20260315-014044
base: 5c9e55fecf9365890c64f14761a80f9413a3b1d1
patch link: https://lore.kernel.org/r/20260314-rtl8157_next-v1-2-9ba77b428afd%40birger-koblitz.de
patch subject: [PATCH net-next 2/9] r8152: Add support for RTL8157 SRAM access and ADV indirect access
config: sparc64-allmodconfig (https://download.01.org/0day-ci/archive/20260410/202604101309.B9mdviRN-lkp@intel.com/config)
compiler: clang version 23.0.0git (https://github.com/llvm/llvm-project c80443cd37b2e2788cba67ffa180a6331e5f0791)
reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20260410/202604101309.B9mdviRN-lkp@intel.com/reproduce)
If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <lkp@intel.com>
| Closes: https://lore.kernel.org/oe-kbuild-all/202604101309.B9mdviRN-lkp@intel.com/
All warnings (new ones prefixed by >>):
>> drivers/net/usb/r8152.c:1682:6: warning: variable 'ret' is used uninitialized whenever 'if' condition is false [-Wsometimes-uninitialized]
1682 | if (i == 10)
| ^~~~~~~
drivers/net/usb/r8152.c:1685:9: note: uninitialized use occurs here
1685 | return ret;
| ^~~
drivers/net/usb/r8152.c:1682:2: note: remove the 'if' if its condition is always true
1682 | if (i == 10)
| ^~~~~~~~~~~~
1683 | ret = -ETIMEDOUT;
drivers/net/usb/r8152.c:1672:12: note: initialize the variable 'ret' to silence this warning
1672 | int i, ret;
| ^
| = 0
drivers/net/usb/r8152.c:1757:12: warning: unused function 'rtl_bmu_clr_bits' [-Wunused-function]
1757 | static int rtl_bmu_clr_bits(struct r8152 *tp, u16 addr, u32 clear)
| ^~~~~~~~~~~~~~~~
drivers/net/usb/r8152.c:1788:12: warning: unused function 'rtl_ip_clr_bits' [-Wunused-function]
1788 | static int rtl_ip_clr_bits(struct r8152 *tp, u16 addr, u32 clear)
| ^~~~~~~~~~~~~~~
drivers/net/usb/r8152.c:1793:12: warning: unused function 'rtl_ip_set_bits' [-Wunused-function]
1793 | static int rtl_ip_set_bits(struct r8152 *tp, u16 addr, u32 set)
| ^~~~~~~~~~~~~~~
drivers/net/usb/r8152.c:1810:13: warning: unused function 'sram_write_w0w1' [-Wunused-function]
1810 | static void sram_write_w0w1(struct r8152 *tp, u16 addr, u16 clear, u16 set)
| ^~~~~~~~~~~~~~~
drivers/net/usb/r8152.c:1824:13: warning: unused function 'sram2_write_w0w1' [-Wunused-function]
1824 | static void sram2_write_w0w1(struct r8152 *tp, u16 addr, u16 clear, u16 set)
| ^~~~~~~~~~~~~~~~
drivers/net/usb/r8152.c:9807:12: warning: unused function 'r8157_desc_init' [-Wunused-function]
9807 | static int r8157_desc_init(struct r8152 *tp)
| ^~~~~~~~~~~~~~~
7 warnings generated.
vim +1682 drivers/net/usb/r8152.c
1669
1670 static int wait_cmd_ready(struct r8152 *tp, u16 cmd)
1671 {
1672 int i, ret;
1673
1674 for (i = 0; i < 10; i++) {
1675 u16 ocp_data = ocp_read_word(tp, MCU_TYPE_USB, cmd);
1676
1677 if (!(ocp_data & ADV_CMD_BUSY))
1678 break;
1679 usleep_range(1000, 2000);
1680 }
1681
> 1682 if (i == 10)
1683 ret = -ETIMEDOUT;
1684
1685 return ret;
1686 }
1687
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
^ permalink raw reply
* [Bug 221340] uas driver hangs and causes usb reset
From: bugzilla-daemon @ 2026-04-10 4:56 UTC (permalink / raw)
To: linux-usb
In-Reply-To: <bug-221340-208809@https.bugzilla.kernel.org/>
https://bugzilla.kernel.org/show_bug.cgi?id=221340
Michał Pecio (michal.pecio@gmail.com) changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |michal.pecio@gmail.com
--- Comment #3 from Michał Pecio (michal.pecio@gmail.com) ---
There is also Unmap/Read sub-channel in this log.
By "hang", do you mean that no I/O happens for 30 seconds or some other time
before these messages show up?
BTW, if you run (as root)
echo 'func handle_tx_event +p' >/proc/dynamic_debug/control
do you see anything new appear in dmesg at this time?
That would point to some "action" at xHCI layer, though I suppose it's also
possible that nothing interesting happens and the device simply never responds
to some commands under some circumstances.
--
You may reply to this email to add a comment.
You are receiving this mail because:
You are watching the assignee of the bug.
^ permalink raw reply
* Re: [PATCH v5 2/3] media: uvcvideo: add UVC_QUIRK_CTRL_THROTTLE for fragile firmware
From: Michal Pecio @ 2026-04-10 4:47 UTC (permalink / raw)
To: Jeffrey Hein
Cc: Ricardo Ribalda, Alan Stern, Laurent Pinchart, Hans de Goede,
Greg Kroah-Hartman, linux-media, linux-usb, stable
In-Reply-To: <CAD5VvzCVxn6ehen4vzbzJzm3Akc-0BREhMZrfsffXTz782jQcw@mail.gmail.com>
On Thu, 9 Apr 2026 17:24:36 -0700, Jeffrey Hein wrote:
> So wBytesPerInterval (8) is indeed 8x smaller than wMaxPacketSize
> (64), matching what you saw in the third-party listing.
Technically it's a spec violation if a device claims 8 bytes but
respons with a single packet larger than that to a 16 byte (or any
other) URB. Though no problems were known to result until last month.
It seems most host controllers ignore byte per interval on interrupt.
> Note that lsusb -vv does not decode wBytesPerInterval for this
> endpoint -- the value above was parsed from the raw descriptor bytes
> in sysfs. The full lsusb -vv (934 lines) is now in the repo:
It does decode it, but you need the latest usbutils version 019.
And there should be no need for lsusb -vv, just lsusb -v.
I think the output pasted into v6 patch was truncated.
Regards,
Michal
^ permalink raw reply
* Re: [PATCH] usb: dwc2: exit clock_gating when stopping udc caused deadlock
From: xiaoxiao_li @ 2026-04-10 3:36 UTC (permalink / raw)
To: gregkh; +Cc: hminas, linux-kernel, linux-usb, lxxstone
In-Reply-To: <2026031116-canine-blimp-94ae@gregkh>
Sorry for the unclear explanation.
This is caused by the patch modification ba78c2b3254c usb: dwc2: also exit clock_gating when stopping udc while suspended.
before this patch, the dwc2_gadget_exit_clock_gating was used in the IRQ handler,
and the handler would immediately acquire the lock with a spin_lock upon entering the function.
However, dwc2_gadget_exit_clock_gating do unlocks first and then relocks after done.
This modification is used in a normal flow, causing a deadlock to occur whenever this function is called.
^ permalink raw reply
* [PATCH v7 2/2] media: uvcvideo: add Razer Kiyo Pro to device info table
From: JP Hein @ 2026-04-10 0:28 UTC (permalink / raw)
To: Laurent Pinchart, Hans de Goede, Greg Kroah-Hartman
Cc: linux-media, linux-usb, Ricardo Ribalda, Michal Pecio, JP Hein
In-Reply-To: <20260410002831.1046407-1-jp@jphein.com>
Add a device entry for the Razer Kiyo Pro (1532:0e05) with quirks to
work around firmware bugs that crash the xHCI host controller:
UVC_QUIRK_CTRL_THROTTLE - rate-limit control transfers to prevent
firmware lockup under sustained load
UVC_QUIRK_DISABLE_AUTOSUSPEND - prevent runtime suspend
UVC_QUIRK_NO_RESET_RESUME - skip post-reset reinitialization
The firmware (v1.5.0.1) has two failure modes: it stalls endpoints
under rapid control transfers (~25 without delay), and it fails to
reinitialize properly after USB power state transitions. Both can
cascade into xHCI controller death, disconnecting all USB devices on
the bus.
Bug reproduced on two separate Kiyo Pro units running simultaneously,
confirming the issue is not unit-specific.
lsusb -vv:
Bus 002 Device 002: ID 1532:0e05 Razer USA, Ltd Razer Kiyo Pro
Device Descriptor:
bLength 18
bDescriptorType 1
bcdUSB 3.20
bDeviceClass 239 Miscellaneous Device
bDeviceSubClass 2 [unknown]
bDeviceProtocol 1 Interface Association
bMaxPacketSize0 9
idVendor 0x1532 Razer USA, Ltd
idProduct 0x0e05 Razer Kiyo Pro
bcdDevice 8.21
iManufacturer 1 Razer Inc
iProduct 2 Razer Kiyo Pro
iSerial 0
bNumConfigurations 1
Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength 0x05b4
bNumInterfaces 4
bConfigurationValue 1
iConfiguration 0
bmAttributes 0x80
(Bus Powered)
MaxPower 896mA
Interface Association:
bLength 8
bDescriptorType 11
bFirstInterface 0
bInterfaceCount 2
bFunctionClass 14 Video
bFunctionSubClass 3 Video Interface Collection
bFunctionProtocol 0
iFunction 0
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 0
bAlternateSetting 0
bNumEndpoints 1
bInterfaceClass 14 Video
bInterfaceSubClass 1 Video Control
bInterfaceProtocol 0
iInterface 0
VideoControl Interface Descriptor:
bLength 13
bDescriptorType 36
bDescriptorSubtype 1 (HEADER)
bcdUVC 1.00
wTotalLength 0x0069
dwClockFrequency 30.000000MHz
bInCollection 1
baInterfaceNr( 0) 1
VideoControl Interface Descriptor:
bLength 9
bDescriptorType 36
bDescriptorSubtype 3 (OUTPUT_TERMINAL)
bTerminalID 4
wTerminalType 0x0101 USB Streaming
bAssocTerminal 0
bSourceID 2
iTerminal 0
VideoControl Interface Descriptor:
bLength 27
bDescriptorType 36
bDescriptorSubtype 6 (EXTENSION_UNIT)
bUnitID 2
guidExtensionCode {2c49d16a-32b8-4485-3ea8-643a152362f2}
bNumControls 6
bNrInPins 1
baSourceID( 0) 6
bControlSize 2
bmControls( 0) 0x3f
bmControls( 1) 0x00
iExtension 0
VideoControl Interface Descriptor:
bLength 27
bDescriptorType 36
bDescriptorSubtype 6 (EXTENSION_UNIT)
bUnitID 6
guidExtensionCode {23e49ed0-1178-4f31-ae52-d2fb8a8d3b48}
bNumControls 5
bNrInPins 1
baSourceID( 0) 3
bControlSize 2
bmControls( 0) 0xff
bmControls( 1) 0x7f
iExtension 0
VideoControl Interface Descriptor:
bLength 18
bDescriptorType 36
bDescriptorSubtype 2 (INPUT_TERMINAL)
bTerminalID 1
wTerminalType 0x0201 Camera Sensor
bAssocTerminal 0
iTerminal 0
wObjectiveFocalLengthMin 0
wObjectiveFocalLengthMax 0
wOcularFocalLength 0
bControlSize 3
bmControls 0x00020a2e
Auto-Exposure Mode
Auto-Exposure Priority
Exposure Time (Absolute)
Focus (Absolute)
Zoom (Absolute)
PanTilt (Absolute)
Focus, Auto
VideoControl Interface Descriptor:
bLength 11
bDescriptorType 36
bDescriptorSubtype 5 (PROCESSING_UNIT)
Warning: Descriptor too short
bUnitID 3
bSourceID 1
wMaxMultiplier 0
bControlSize 2
bmControls 0x0000175b
Brightness
Contrast
Saturation
Sharpness
White Balance Temperature
Backlight Compensation
Gain
Power Line Frequency
White Balance Temperature, Auto
iProcessing 0
bmVideoStandards 0xff
None
NTSC - 525/60
PAL - 625/50
SECAM - 625/50
NTSC - 625/50
PAL - 525/60
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x85 EP 5 IN
bmAttributes 3
Transfer Type Interrupt
Synch Type None
Usage Type Data
wMaxPacketSize 0x0040 1x 64 bytes
bInterval 8
bMaxBurst 0
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 1
bAlternateSetting 0
bNumEndpoints 0
bInterfaceClass 14 Video
bInterfaceSubClass 2 Video Streaming
bInterfaceProtocol 0
iInterface 0
VideoStreaming Interface Descriptor:
bLength 17
bDescriptorType 36
bDescriptorSubtype 1 (INPUT_HEADER)
bNumFormats 4
wTotalLength 0x03e6
bEndpointAddress 0x81 EP 1 IN
bmInfo 0
bTerminalLink 4
bStillCaptureMethod 0
bTriggerSupport 0
bTriggerUsage 0
bControlSize 1
bmaControls( 0) 0
bmaControls( 1) 0
bmaControls( 2) 0
bmaControls( 3) 0
VideoStreaming Interface Descriptor:
bLength 27
bDescriptorType 36
bDescriptorSubtype 4 (FORMAT_UNCOMPRESSED)
bFormatIndex 1
bNumFrameDescriptors 4
guidFormat {32595559-0000-0010-8000-00aa00389b71}
bBitsPerPixel 16
bDefaultFrameIndex 1
bAspectRatioX 0
bAspectRatioY 0
bmInterlaceFlags 0x00
Interlaced stream or variable: No
Fields per frame: 2 fields
Field 1 first: No
Field pattern: Field 1 only
bCopyProtect 0
VideoStreaming Interface Descriptor:
bLength 54
bDescriptorType 36
bDescriptorSubtype 5 (FRAME_UNCOMPRESSED)
bFrameIndex 1
bmCapabilities 0x00
Still image unsupported
wWidth 640
wHeight 480
dwMinBitRate 294912000
dwMaxBitRate 294912000
dwMaxVideoFrameBufferSize 614400
dwDefaultFrameInterval 166666
bFrameIntervalType 7
dwFrameInterval( 0) 166666
dwFrameInterval( 1) 333333
dwFrameInterval( 2) 416666
dwFrameInterval( 3) 500000
dwFrameInterval( 4) 666666
dwFrameInterval( 5) 1000000
dwFrameInterval( 6) 2000000
VideoStreaming Interface Descriptor:
bLength 54
bDescriptorType 36
bDescriptorSubtype 5 (FRAME_UNCOMPRESSED)
bFrameIndex 7
bmCapabilities 0x00
Still image unsupported
wWidth 640
wHeight 360
dwMinBitRate 221184000
dwMaxBitRate 221184000
dwMaxVideoFrameBufferSize 460800
dwDefaultFrameInterval 166666
bFrameIntervalType 7
dwFrameInterval( 0) 166666
dwFrameInterval( 1) 333333
dwFrameInterval( 2) 416666
dwFrameInterval( 3) 500000
dwFrameInterval( 4) 666666
dwFrameInterval( 5) 1000000
dwFrameInterval( 6) 2000000
VideoStreaming Interface Descriptor:
bLength 54
bDescriptorType 36
bDescriptorSubtype 5 (FRAME_UNCOMPRESSED)
bFrameIndex 11
bmCapabilities 0x00
Still image unsupported
wWidth 1280
wHeight 720
dwMinBitRate 884736000
dwMaxBitRate 884736000
dwMaxVideoFrameBufferSize 1843200
dwDefaultFrameInterval 166666
bFrameIntervalType 7
dwFrameInterval( 0) 166666
dwFrameInterval( 1) 333333
dwFrameInterval( 2) 416666
dwFrameInterval( 3) 500000
dwFrameInterval( 4) 666666
dwFrameInterval( 5) 1000000
dwFrameInterval( 6) 2000000
VideoStreaming Interface Descriptor:
bLength 54
bDescriptorType 36
bDescriptorSubtype 5 (FRAME_UNCOMPRESSED)
bFrameIndex 13
bmCapabilities 0x00
Still image unsupported
wWidth 1920
wHeight 1080
dwMinBitRate 1990656000
dwMaxBitRate 1990656000
dwMaxVideoFrameBufferSize 4147200
dwDefaultFrameInterval 166666
bFrameIntervalType 7
dwFrameInterval( 0) 166666
dwFrameInterval( 1) 333333
dwFrameInterval( 2) 416666
dwFrameInterval( 3) 500000
dwFrameInterval( 4) 666666
dwFrameInterval( 5) 1000000
dwFrameInterval( 6) 2000000
VideoStreaming Interface Descriptor:
bLength 6
bDescriptorType 36
bDescriptorSubtype 13 (COLORFORMAT)
bColorPrimaries 1 (BT.709,sRGB)
bTransferCharacteristics 1 (BT.709)
bMatrixCoefficients 4 (SMPTE 170M (BT.601))
VideoStreaming Interface Descriptor:
bLength 11
bDescriptorType 36
bDescriptorSubtype 6 (FORMAT_MJPEG)
bFormatIndex 2
bNumFrameDescriptors 4
bFlags 0
Fixed-size samples: No
bDefaultFrameIndex 1
bAspectRatioX 0
bAspectRatioY 0
bmInterlaceFlags 0x00
Interlaced stream or variable: No
Fields per frame: 1 fields
Field 1 first: No
Field pattern: Field 1 only
bCopyProtect 0
VideoStreaming Interface Descriptor:
bLength 54
bDescriptorType 36
bDescriptorSubtype 7 (FRAME_MJPEG)
bFrameIndex 1
bmCapabilities 0x00
Still image unsupported
wWidth 640
wHeight 480
dwMinBitRate 294912000
dwMaxBitRate 294912000
dwMaxVideoFrameBufferSize 614400
dwDefaultFrameInterval 166666
bFrameIntervalType 7
dwFrameInterval( 0) 166666
dwFrameInterval( 1) 333333
dwFrameInterval( 2) 416666
dwFrameInterval( 3) 500000
dwFrameInterval( 4) 666666
dwFrameInterval( 5) 1000000
dwFrameInterval( 6) 2000000
VideoStreaming Interface Descriptor:
bLength 54
bDescriptorType 36
bDescriptorSubtype 7 (FRAME_MJPEG)
bFrameIndex 7
bmCapabilities 0x00
Still image unsupported
wWidth 640
wHeight 360
dwMinBitRate 221184000
dwMaxBitRate 221184000
dwMaxVideoFrameBufferSize 460800
dwDefaultFrameInterval 166666
bFrameIntervalType 7
dwFrameInterval( 0) 166666
dwFrameInterval( 1) 333333
dwFrameInterval( 2) 416666
dwFrameInterval( 3) 500000
dwFrameInterval( 4) 666666
dwFrameInterval( 5) 1000000
dwFrameInterval( 6) 2000000
VideoStreaming Interface Descriptor:
bLength 54
bDescriptorType 36
bDescriptorSubtype 7 (FRAME_MJPEG)
bFrameIndex 11
bmCapabilities 0x00
Still image unsupported
wWidth 1280
wHeight 720
dwMinBitRate 884736000
dwMaxBitRate 884736000
dwMaxVideoFrameBufferSize 1843200
dwDefaultFrameInterval 166666
bFrameIntervalType 7
dwFrameInterval( 0) 166666
dwFrameInterval( 1) 333333
dwFrameInterval( 2) 416666
dwFrameInterval( 3) 500000
dwFrameInterval( 4) 666666
dwFrameInterval( 5) 1000000
dwFrameInterval( 6) 2000000
VideoStreaming Interface Descriptor:
bLength 54
bDescriptorType 36
bDescriptorSubtype 7 (FRAME_MJPEG)
bFrameIndex 13
bmCapabilities 0x00
Still image unsupported
wWidth 1920
wHeight 1080
dwMinBitRate 1990656000
dwMaxBitRate 1990656000
dwMaxVideoFrameBufferSize 4147200
dwDefaultFrameInterval 166666
bFrameIntervalType 7
dwFrameInterval( 0) 166666
dwFrameInterval( 1) 333333
dwFrameInterval( 2) 416666
dwFrameInterval( 3) 500000
dwFrameInterval( 4) 666666
dwFrameInterval( 5) 1000000
dwFrameInterval( 6) 2000000
VideoStreaming Interface Descriptor:
bLength 6
bDescriptorType 36
bDescriptorSubtype 13 (COLORFORMAT)
bColorPrimaries 1 (BT.709,sRGB)
bTransferCharacteristics 1 (BT.709)
bMatrixCoefficients 4 (SMPTE 170M (BT.601))
VideoStreaming Interface Descriptor:
bLength 28
bDescriptorType 36
bDescriptorSubtype 16 (FORMAT_FRAME_BASED)
bFormatIndex 3
bNumFrameDescriptors 4
guidFormat {34363248-0000-0010-8000-00aa00389b71}
bBitsPerPixel 16
bDefaultFrameIndex 1
bAspectRatioX 0
bAspectRatioY 0
bmInterlaceFlags 0x00
Interlaced stream or variable: No
Fields per frame: 2 fields
Field 1 first: No
Field pattern: Field 1 only
bCopyProtect 0
bVariableSize 1
VideoStreaming Interface Descriptor:
bLength 54
bDescriptorType 36
bDescriptorSubtype 17 (FRAME_FRAME_BASED)
bFrameIndex 1
bmCapabilities 0x00
Still image unsupported
wWidth 640
wHeight 480
dwMinBitRate 251658240
dwMaxBitRate 503316480
dwDefaultFrameInterval 166666
bFrameIntervalType 7
dwBytesPerLine 0
dwFrameInterval( 0) 166666
dwFrameInterval( 1) 333333
dwFrameInterval( 2) 416666
dwFrameInterval( 3) 500000
dwFrameInterval( 4) 666666
dwFrameInterval( 5) 1000000
dwFrameInterval( 6) 2000000
VideoStreaming Interface Descriptor:
bLength 54
bDescriptorType 36
bDescriptorSubtype 17 (FRAME_FRAME_BASED)
bFrameIndex 9
bmCapabilities 0x00
Still image unsupported
wWidth 640
wHeight 360
dwMinBitRate 251658240
dwMaxBitRate 503316480
dwDefaultFrameInterval 166666
bFrameIntervalType 7
dwBytesPerLine 0
dwFrameInterval( 0) 166666
dwFrameInterval( 1) 333333
dwFrameInterval( 2) 416666
dwFrameInterval( 3) 500000
dwFrameInterval( 4) 666666
dwFrameInterval( 5) 1000000
dwFrameInterval( 6) 2000000
VideoStreaming Interface Descriptor:
bLength 54
bDescriptorType 36
bDescriptorSubtype 17 (FRAME_FRAME_BASED)
bFrameIndex 15
bmCapabilities 0x00
Still image unsupported
wWidth 1280
wHeight 720
dwMinBitRate 251658240
dwMaxBitRate 503316480
dwDefaultFrameInterval 166666
bFrameIntervalType 7
dwBytesPerLine 0
dwFrameInterval( 0) 166666
dwFrameInterval( 1) 333333
dwFrameInterval( 2) 416666
dwFrameInterval( 3) 500000
dwFrameInterval( 4) 666666
dwFrameInterval( 5) 1000000
dwFrameInterval( 6) 2000000
VideoStreaming Interface Descriptor:
bLength 54
bDescriptorType 36
bDescriptorSubtype 17 (FRAME_FRAME_BASED)
bFrameIndex 17
bmCapabilities 0x00
Still image unsupported
wWidth 1920
wHeight 1080
dwMinBitRate 251658240
dwMaxBitRate 503316480
dwDefaultFrameInterval 166666
bFrameIntervalType 7
dwBytesPerLine 0
dwFrameInterval( 0) 166666
dwFrameInterval( 1) 333333
dwFrameInterval( 2) 416666
dwFrameInterval( 3) 500000
dwFrameInterval( 4) 666666
dwFrameInterval( 5) 1000000
dwFrameInterval( 6) 2000000
VideoStreaming Interface Descriptor:
bLength 6
bDescriptorType 36
bDescriptorSubtype 13 (COLORFORMAT)
bColorPrimaries 1 (BT.709,sRGB)
bTransferCharacteristics 1 (BT.709)
bMatrixCoefficients 4 (SMPTE 170M (BT.601))
VideoStreaming Interface Descriptor:
bLength 27
bDescriptorType 36
bDescriptorSubtype 4 (FORMAT_UNCOMPRESSED)
bFormatIndex 4
bNumFrameDescriptors 4
guidFormat {3231564e-0000-0010-8000-00aa00389b71}
bBitsPerPixel 12
bDefaultFrameIndex 1
bAspectRatioX 0
bAspectRatioY 0
bmInterlaceFlags 0x00
Interlaced stream or variable: No
Fields per frame: 2 fields
Field 1 first: No
Field pattern: Field 1 only
bCopyProtect 0
VideoStreaming Interface Descriptor:
bLength 54
bDescriptorType 36
bDescriptorSubtype 5 (FRAME_UNCOMPRESSED)
bFrameIndex 1
bmCapabilities 0x00
Still image unsupported
wWidth 640
wHeight 480
dwMinBitRate 221184000
dwMaxBitRate 221184000
dwMaxVideoFrameBufferSize 460800
dwDefaultFrameInterval 166666
bFrameIntervalType 7
dwFrameInterval( 0) 166666
dwFrameInterval( 1) 333333
dwFrameInterval( 2) 416666
dwFrameInterval( 3) 500000
dwFrameInterval( 4) 666666
dwFrameInterval( 5) 1000000
dwFrameInterval( 6) 2000000
VideoStreaming Interface Descriptor:
bLength 54
bDescriptorType 36
bDescriptorSubtype 5 (FRAME_UNCOMPRESSED)
bFrameIndex 2
bmCapabilities 0x00
Still image unsupported
wWidth 640
wHeight 360
dwMinBitRate 165888000
dwMaxBitRate 165888000
dwMaxVideoFrameBufferSize 345600
dwDefaultFrameInterval 166666
bFrameIntervalType 7
dwFrameInterval( 0) 166666
dwFrameInterval( 1) 333333
dwFrameInterval( 2) 416666
dwFrameInterval( 3) 500000
dwFrameInterval( 4) 666666
dwFrameInterval( 5) 1000000
dwFrameInterval( 6) 2000000
VideoStreaming Interface Descriptor:
bLength 54
bDescriptorType 36
bDescriptorSubtype 5 (FRAME_UNCOMPRESSED)
bFrameIndex 3
bmCapabilities 0x00
Still image unsupported
wWidth 1280
wHeight 720
dwMinBitRate 663552000
dwMaxBitRate 663552000
dwMaxVideoFrameBufferSize 1382400
dwDefaultFrameInterval 166666
bFrameIntervalType 7
dwFrameInterval( 0) 166666
dwFrameInterval( 1) 333333
dwFrameInterval( 2) 416666
dwFrameInterval( 3) 500000
dwFrameInterval( 4) 666666
dwFrameInterval( 5) 1000000
dwFrameInterval( 6) 2000000
VideoStreaming Interface Descriptor:
bLength 54
bDescriptorType 36
bDescriptorSubtype 5 (FRAME_UNCOMPRESSED)
bFrameIndex 4
bmCapabilities 0x00
Still image unsupported
wWidth 1920
wHeight 1080
dwMinBitRate 1492992000
dwMaxBitRate 1492992000
dwMaxVideoFrameBufferSize 3110400
dwDefaultFrameInterval 166666
bFrameIntervalType 7
dwFrameInterval( 0) 166666
dwFrameInterval( 1) 333333
dwFrameInterval( 2) 416666
dwFrameInterval( 3) 500000
dwFrameInterval( 4) 666666
dwFrameInterval( 5) 1000000
dwFrameInterval( 6) 2000000
VideoStreaming Interface Descriptor:
bLength 6
bDescriptorType 36
bDescriptorSubtype 13 (COLORFORMAT)
bColorPrimaries 1 (BT.709,sRGB)
bTransferCharacteristics 1 (BT.709)
bMatrixCoefficients 4 (SMPTE 170M (BT.601))
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 1
bAlternateSetting 1
bNumEndpoints 1
bInterfaceClass 14 Video
bInterfaceSubClass 2 Video Streaming
bInterfaceProtocol 0
iInterface 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x81 EP 1 IN
bmAttributes 5
Transfer Type Isochronous
Synch Type Asynchronous
Usage Type Data
wMaxPacketSize 0x0400 1x 1024 bytes
bInterval 1
bMaxBurst 0
Mult 2
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 1
bAlternateSetting 2
bNumEndpoints 1
bInterfaceClass 14 Video
bInterfaceSubClass 2 Video Streaming
bInterfaceProtocol 0
iInterface 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x81 EP 1 IN
bmAttributes 5
Transfer Type Isochronous
Synch Type Asynchronous
Usage Type Data
wMaxPacketSize 0x0400 1x 1024 bytes
bInterval 1
bMaxBurst 10
Mult 2
Interface Association:
bLength 8
bDescriptorType 11
bFirstInterface 2
bInterfaceCount 2
bFunctionClass 1 Audio
bFunctionSubClass 2 Streaming
bFunctionProtocol 0
iFunction 0
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 2
bAlternateSetting 0
bNumEndpoints 0
bInterfaceClass 1 Audio
bInterfaceSubClass 1 Control Device
bInterfaceProtocol 0
iInterface 0
AudioControl Interface Descriptor:
bLength 9
bDescriptorType 36
bDescriptorSubtype 1 (HEADER)
bcdADC 1.00
wTotalLength 0x0026
bInCollection 1
baInterfaceNr(0) 3
AudioControl Interface Descriptor:
bLength 12
bDescriptorType 36
bDescriptorSubtype 2 (INPUT_TERMINAL)
bTerminalID 1
wTerminalType 0x0201 Microphone
bAssocTerminal 0
bNrChannels 2
wChannelConfig 0x0003
Left Front (L)
Right Front (R)
iChannelNames 0
iTerminal 0
AudioControl Interface Descriptor:
bLength 9
bDescriptorType 36
bDescriptorSubtype 3 (OUTPUT_TERMINAL)
bTerminalID 3
wTerminalType 0x0101 USB Streaming
bAssocTerminal 0
bSourceID 5
iTerminal 0
AudioControl Interface Descriptor:
bLength 8
bDescriptorType 36
bDescriptorSubtype 6 (FEATURE_UNIT)
bUnitID 5
bSourceID 1
bControlSize 1
bmaControls(0) 0x03
Mute Control
Volume Control
iFeature 0
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 3
bAlternateSetting 0
bNumEndpoints 0
bInterfaceClass 1 Audio
bInterfaceSubClass 2 Streaming
bInterfaceProtocol 0
iInterface 0
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 3
bAlternateSetting 1
bNumEndpoints 1
bInterfaceClass 1 Audio
bInterfaceSubClass 2 Streaming
bInterfaceProtocol 0
iInterface 0
AudioStreaming Interface Descriptor:
bLength 7
bDescriptorType 36
bDescriptorSubtype 1 (AS_GENERAL)
bTerminalLink 3
bDelay 2 frames
wFormatTag 0x0001 PCM
AudioStreaming Interface Descriptor:
bLength 11
bDescriptorType 36
bDescriptorSubtype 2 (FORMAT_TYPE)
bFormatType 1 (FORMAT_TYPE_I)
bNrChannels 2
bSubframeSize 2
bBitResolution 16
bSamFreqType 1 Discrete
tSamFreq[ 0] 48000
Endpoint Descriptor:
bLength 9
bDescriptorType 5
bEndpointAddress 0x82 EP 2 IN
bmAttributes 5
Transfer Type Isochronous
Synch Type Asynchronous
Usage Type Data
wMaxPacketSize 0x00c4 1x 196 bytes
bInterval 4
bRefresh 0
bSynchAddress 0
bMaxBurst 0
AudioStreaming Endpoint Descriptor:
bLength 7
bDescriptorType 37
bDescriptorSubtype 1 (EP_GENERAL)
bmAttributes 0x01
Sampling Frequency
bLockDelayUnits 0 Undefined
wLockDelay 0x0000
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 3
bAlternateSetting 2
bNumEndpoints 1
bInterfaceClass 1 Audio
bInterfaceSubClass 2 Streaming
bInterfaceProtocol 0
iInterface 0
AudioStreaming Interface Descriptor:
bLength 7
bDescriptorType 36
bDescriptorSubtype 1 (AS_GENERAL)
bTerminalLink 3
bDelay 2 frames
wFormatTag 0x0001 PCM
AudioStreaming Interface Descriptor:
bLength 11
bDescriptorType 36
bDescriptorSubtype 2 (FORMAT_TYPE)
bFormatType 1 (FORMAT_TYPE_I)
bNrChannels 2
bSubframeSize 2
bBitResolution 16
bSamFreqType 1 Discrete
tSamFreq[ 0] 16000
Endpoint Descriptor:
bLength 9
bDescriptorType 5
bEndpointAddress 0x82 EP 2 IN
bmAttributes 5
Transfer Type Isochronous
Synch Type Asynchronous
Usage Type Data
wMaxPacketSize 0x0044 1x 68 bytes
bInterval 4
bRefresh 0
bSynchAddress 0
bMaxBurst 0
AudioStreaming Endpoint Descriptor:
bLength 7
bDescriptorType 37
bDescriptorSubtype 1 (EP_GENERAL)
bmAttributes 0x01
Sampling Frequency
bLockDelayUnits 0 Undefined
wLockDelay 0x0000
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 3
bAlternateSetting 3
bNumEndpoints 1
bInterfaceClass 1 Audio
bInterfaceSubClass 2 Streaming
bInterfaceProtocol 0
iInterface 0
AudioStreaming Interface Descriptor:
bLength 7
bDescriptorType 36
bDescriptorSubtype 1 (AS_GENERAL)
bTerminalLink 3
bDelay 2 frames
wFormatTag 0x0001 PCM
AudioStreaming Interface Descriptor:
bLength 11
bDescriptorType 36
bDescriptorSubtype 2 (FORMAT_TYPE)
bFormatType 1 (FORMAT_TYPE_I)
bNrChannels 2
bSubframeSize 2
bBitResolution 16
bSamFreqType 1 Discrete
tSamFreq[ 0] 24000
Endpoint Descriptor:
bLength 9
bDescriptorType 5
bEndpointAddress 0x82 EP 2 IN
bmAttributes 5
Transfer Type Isochronous
Synch Type Asynchronous
Usage Type Data
wMaxPacketSize 0x0064 1x 100 bytes
bInterval 4
bRefresh 0
bSynchAddress 0
bMaxBurst 0
AudioStreaming Endpoint Descriptor:
bLength 7
bDescriptorType 37
bDescriptorSubtype 1 (EP_GENERAL)
bmAttributes 0x01
Sampling Frequency
bLockDelayUnits 0 Undefined
wLockDelay 0x0000
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 3
bAlternateSetting 4
bNumEndpoints 1
bInterfaceClass 1 Audio
bInterfaceSubClass 2 Streaming
bInterfaceProtocol 0
iInterface 0
AudioStreaming Interface Descriptor:
bLength 7
bDescriptorType 36
bDescriptorSubtype 1 (AS_GENERAL)
bTerminalLink 3
bDelay 2 frames
wFormatTag 0x0001 PCM
AudioStreaming Interface Descriptor:
bLength 11
bDescriptorType 36
bDescriptorSubtype 2 (FORMAT_TYPE)
bFormatType 1 (FORMAT_TYPE_I)
bNrChannels 2
bSubframeSize 2
bBitResolution 16
bSamFreqType 1 Discrete
tSamFreq[ 0] 32000
Endpoint Descriptor:
bLength 9
bDescriptorType 5
bEndpointAddress 0x82 EP 2 IN
bmAttributes 5
Transfer Type Isochronous
Synch Type Asynchronous
Usage Type Data
wMaxPacketSize 0x0084 1x 132 bytes
bInterval 4
bRefresh 0
bSynchAddress 0
bMaxBurst 0
AudioStreaming Endpoint Descriptor:
bLength 7
bDescriptorType 37
bDescriptorSubtype 1 (EP_GENERAL)
bmAttributes 0x01
Sampling Frequency
bLockDelayUnits 0 Undefined
wLockDelay 0x0000
Binary Object Store Descriptor:
bLength 5
bDescriptorType 15
wTotalLength 0x0016
bNumDeviceCaps 2
USB 2.0 Extension Device Capability:
bLength 7
bDescriptorType 16
bDevCapabilityType 2
bmAttributes 0x00000006
BESL Link Power Management (LPM) Supported
SuperSpeed USB Device Capability:
bLength 10
bDescriptorType 16
bDevCapabilityType 3
bmAttributes 0x00
wSpeedsSupported 0x000e
Device can operate at Full Speed (12Mbps)
Device can operate at High Speed (480Mbps)
Device can operate at SuperSpeed (5Gbps)
bFunctionalitySupport 2
Lowest fully-functional device speed is High Speed (480Mbps)
bU1DevExitLat 10 micro seconds
bU2DevExitLat 256 micro seconds
Device Status: 0x0000
(Bus Powered)
Signed-off-by: JP Hein <jp@jphein.com>
---
drivers/media/usb/uvc/uvc_driver.c | 16 ++++++++++++++++
1 file changed, 16 insertions(+)
diff --git a/drivers/media/usb/uvc/uvc_driver.c b/drivers/media/usb/uvc/uvc_driver.c
index 775bede..9b6df8e 100644
--- a/drivers/media/usb/uvc/uvc_driver.c
+++ b/drivers/media/usb/uvc/uvc_driver.c
@@ -2880,6 +2880,22 @@ static const struct usb_device_id uvc_ids[] = {
.bInterfaceSubClass = 1,
.bInterfaceProtocol = 0,
.driver_info = (kernel_ulong_t)&uvc_quirk_probe_minmax },
+
+ /*
+ * Razer Kiyo Pro -- firmware crashes under rapid control transfers
+ * and on LPM/autosuspend resume, cascading into xHCI controller
+ * death that disconnects all USB devices on the bus.
+ */
+ { .match_flags = USB_DEVICE_ID_MATCH_DEVICE
+ | USB_DEVICE_ID_MATCH_INT_INFO,
+ .idVendor = 0x1532,
+ .idProduct = 0x0e05,
+ .bInterfaceClass = USB_CLASS_VIDEO,
+ .bInterfaceSubClass = 1,
+ .bInterfaceProtocol = 0,
+ .driver_info = UVC_INFO_QUIRK(UVC_QUIRK_CTRL_THROTTLE
+ | UVC_QUIRK_DISABLE_AUTOSUSPEND
+ | UVC_QUIRK_NO_RESET_RESUME) },
/* Kurokesu C1 PRO */
{ .match_flags = USB_DEVICE_ID_MATCH_DEVICE
| USB_DEVICE_ID_MATCH_INT_INFO,
--
2.43.0
^ permalink raw reply related
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