* Re: [PATCH v4] usb: gadget: uvc: fix NULL pointer dereference during unbind race
From: Jimmy Hu (xWF) @ 2026-04-07 2:25 UTC (permalink / raw)
To: Roshan Binu Paul
Cc: gregkh@linuxfoundation.org, linux-usb@vger.kernel.org,
linux-kernel@vger.kernel.org
In-Reply-To: <MAYPR01MB10413B6654E013F981EAA7ED9EB51A@MAYPR01MB10413.INDPRD01.PROD.OUTLOOK.COM>
Hi Roshan,
Thank you very much for the detailed testing and the positive feedback!
It’s great to hear that the patch resolved the NULL pointer
dereference on the Xilinx ZynqMP platform, especially under the
SIGKILL stress tests. This confirms the robustness of the
synchronization logic across different environments.
For your information, Greg KH has already accepted this patch into the
usb-linus branch, and it should be headed to the mainline and stable
trees shortly.
I really appreciate the time you took to verify this fix.
Best regards,
Jimmy
On Thu, Apr 2, 2026 at 8:29 PM Roshan Binu Paul
<roshan.binu@dicortech.com> wrote:
>
> Hi Jimmy,
>
> I have tested this patch on a Xilinx ZynqMP platform running a custom
> UVC video streaming application.
>
> Test Environment
> ----------------
> Platform : Xilinx ZynqMP
> Kernel : 6.6.40-xilinx-g7c7280e64b31
> Application : Custom UVC video streaming application
> Base : PetaLinux 2024.2
>
> Verification
> ------------
> Confirmed patch is applied by checking for uvc_vdev_release symbol
> in /proc/kallsyms.
>
> Test Methodology
> ----------------
> 1. Start UVC video streaming application
> 2. Send SIGKILL to force terminate the application
> 3. Wait for application auto-restart
> 4. Check kernel messages for NULL pointer dereference or panic
> 5. Repeat for 10 cycles
>
> Test Results
> ------------
> SIGKILL stress test : 10/10 cycles (3 Reps) PASSED
> NULL pointer crashes: None observed
> Kernel panics : None observed
> System stability : Stable throughout testing
>
> Prior to this patch, we observed NULL pointer dereferences in
> usb_gadget_deactivate() when applications were force-killed during
> active streaming sessions. This patch resolves that issue.
>
> Tested-by: Roshan Binu Paul <roshan.binu@dicortech.com>
>
> Thanks for the fix.
>
> Best regards,
> Roshan Binu Paul
> DicorTech
^ permalink raw reply
* [PATCH] USB: of: Simplify with scoped for each OF child loop
From: Hans Zhang @ 2026-04-07 1:31 UTC (permalink / raw)
To: gregkh; +Cc: linux-usb, linux-kernel, Hans Zhang
Use scoped for-each loop when iterating over device nodes to make code a
bit simpler.
Signed-off-by: Hans Zhang <18255117159@163.com>
---
drivers/usb/core/of.c | 8 ++------
1 file changed, 2 insertions(+), 6 deletions(-)
diff --git a/drivers/usb/core/of.c b/drivers/usb/core/of.c
index 763e4122ed5b..a6ee20d8774e 100644
--- a/drivers/usb/core/of.c
+++ b/drivers/usb/core/of.c
@@ -79,17 +79,13 @@ EXPORT_SYMBOL_GPL(usb_of_has_combined_node);
static bool usb_of_has_devices_or_graph(const struct usb_device *hub)
{
const struct device_node *np = hub->dev.of_node;
- struct device_node *child;
if (of_graph_is_present(np))
return true;
- for_each_child_of_node(np, child) {
- if (of_property_present(child, "reg")) {
- of_node_put(child);
+ for_each_child_of_node_scoped(np, child)
+ if (of_property_present(child, "reg"))
return true;
- }
- }
return false;
}
base-commit: 591cd656a1bf5ea94a222af5ef2ee76df029c1d2
--
2.34.1
^ permalink raw reply related
* [PATCH v5 8/9] driver core: Replace dev->of_node_reused with dev_of_node_reused()
From: Douglas Anderson @ 2026-04-06 23:23 UTC (permalink / raw)
To: Greg Kroah-Hartman, Rafael J . Wysocki, Danilo Krummrich,
Alan Stern
Cc: Alexey Kardashevskiy, Johan Hovold, Eric Dumazet, Leon Romanovsky,
Christoph Hellwig, Robin Murphy, maz, Alexander Lobakin,
Saravana Kannan, Douglas Anderson, Mark Brown, alexander.stein,
andrew, andrew, andriy.shevchenko, astewart, bhelgaas, brgl,
davem, devicetree, driver-core, hkallweit1, jirislaby, joel, kees,
kuba, lgirdwood, linux-arm-kernel, linux-aspeed, linux-kernel,
linux-pci, linux-serial, linux-usb, linux, mani, netdev, pabeni,
robh
In-Reply-To: <20260406232444.3117516-1-dianders@chromium.org>
In C, bitfields are not necessarily safe to modify from multiple
threads without locking. Switch "of_node_reused" over to the "flags"
field so modifications are safe.
Cc: Johan Hovold <johan@kernel.org>
Acked-by: Mark Brown <broonie@kernel.org>
Reviewed-by: Rafael J. Wysocki (Intel) <rafael@kernel.org>
Reviewed-by: Danilo Krummrich <dakr@kernel.org>
Signed-off-by: Douglas Anderson <dianders@chromium.org>
---
Not fixing any known bugs; problem is theoretical and found by code
inspection. Change is done somewhat manually and only lightly tested
(mostly compile-time tested).
(no changes since v4)
Changes in v4:
- Use accessor functions for flags
Changes in v3:
- New
drivers/base/core.c | 2 +-
drivers/base/pinctrl.c | 2 +-
drivers/base/platform.c | 2 +-
drivers/net/pcs/pcs-xpcs-plat.c | 2 +-
drivers/of/device.c | 6 +++---
drivers/pci/of.c | 2 +-
drivers/pci/pwrctrl/core.c | 2 +-
drivers/regulator/bq257xx-regulator.c | 2 +-
drivers/regulator/rk808-regulator.c | 2 +-
drivers/tty/serial/serial_base_bus.c | 2 +-
drivers/usb/gadget/udc/aspeed-vhub/dev.c | 2 +-
include/linux/device.h | 7 ++++---
12 files changed, 17 insertions(+), 16 deletions(-)
diff --git a/drivers/base/core.c b/drivers/base/core.c
index 8a83d7c93361..30825bf83234 100644
--- a/drivers/base/core.c
+++ b/drivers/base/core.c
@@ -5283,7 +5283,7 @@ void device_set_of_node_from_dev(struct device *dev, const struct device *dev2)
{
of_node_put(dev->of_node);
dev->of_node = of_node_get(dev2->of_node);
- dev->of_node_reused = true;
+ dev_set_of_node_reused(dev);
}
EXPORT_SYMBOL_GPL(device_set_of_node_from_dev);
diff --git a/drivers/base/pinctrl.c b/drivers/base/pinctrl.c
index 6e250272c843..0bbc83231234 100644
--- a/drivers/base/pinctrl.c
+++ b/drivers/base/pinctrl.c
@@ -24,7 +24,7 @@ int pinctrl_bind_pins(struct device *dev)
{
int ret;
- if (dev->of_node_reused)
+ if (dev_of_node_reused(dev))
return 0;
dev->pins = devm_kzalloc(dev, sizeof(*(dev->pins)), GFP_KERNEL);
diff --git a/drivers/base/platform.c b/drivers/base/platform.c
index d44591d52e36..199e6fb25770 100644
--- a/drivers/base/platform.c
+++ b/drivers/base/platform.c
@@ -856,7 +856,7 @@ struct platform_device *platform_device_register_full(
pdev->dev.parent = pdevinfo->parent;
pdev->dev.fwnode = pdevinfo->fwnode;
pdev->dev.of_node = of_node_get(to_of_node(pdev->dev.fwnode));
- pdev->dev.of_node_reused = pdevinfo->of_node_reused;
+ dev_assign_of_node_reused(&pdev->dev, pdevinfo->of_node_reused);
if (pdevinfo->dma_mask) {
pdev->platform_dma_mask = pdevinfo->dma_mask;
diff --git a/drivers/net/pcs/pcs-xpcs-plat.c b/drivers/net/pcs/pcs-xpcs-plat.c
index b8c48f9effbf..f4b1b8246ce9 100644
--- a/drivers/net/pcs/pcs-xpcs-plat.c
+++ b/drivers/net/pcs/pcs-xpcs-plat.c
@@ -349,7 +349,7 @@ static int xpcs_plat_init_dev(struct dw_xpcs_plat *pxpcs)
* up later. Make sure DD-core is aware of the OF-node being re-used.
*/
device_set_node(&mdiodev->dev, fwnode_handle_get(dev_fwnode(dev)));
- mdiodev->dev.of_node_reused = true;
+ dev_set_of_node_reused(&mdiodev->dev);
/* Pass the data further so the DW XPCS driver core could use it */
mdiodev->dev.platform_data = (void *)device_get_match_data(dev);
diff --git a/drivers/of/device.c b/drivers/of/device.c
index f7e75e527667..be4e1584e0af 100644
--- a/drivers/of/device.c
+++ b/drivers/of/device.c
@@ -26,7 +26,7 @@
const struct of_device_id *of_match_device(const struct of_device_id *matches,
const struct device *dev)
{
- if (!matches || !dev->of_node || dev->of_node_reused)
+ if (!matches || !dev->of_node || dev_of_node_reused(dev))
return NULL;
return of_match_node(matches, dev->of_node);
}
@@ -192,7 +192,7 @@ ssize_t of_device_modalias(struct device *dev, char *str, ssize_t len)
{
ssize_t sl;
- if (!dev || !dev->of_node || dev->of_node_reused)
+ if (!dev || !dev->of_node || dev_of_node_reused(dev))
return -ENODEV;
sl = of_modalias(dev->of_node, str, len - 2);
@@ -254,7 +254,7 @@ int of_device_uevent_modalias(const struct device *dev, struct kobj_uevent_env *
{
int sl;
- if ((!dev) || (!dev->of_node) || dev->of_node_reused)
+ if ((!dev) || (!dev->of_node) || dev_of_node_reused(dev))
return -ENODEV;
/* Devicetree modalias is tricky, we add it in 2 steps */
diff --git a/drivers/pci/of.c b/drivers/pci/of.c
index 9f8eb5df279e..1f9b669abdb0 100644
--- a/drivers/pci/of.c
+++ b/drivers/pci/of.c
@@ -38,7 +38,7 @@ int pci_set_of_node(struct pci_dev *dev)
struct device *pdev __free(put_device) =
bus_find_device_by_of_node(&platform_bus_type, node);
if (pdev)
- dev->bus->dev.of_node_reused = true;
+ dev_set_of_node_reused(&dev->bus->dev);
device_set_node(&dev->dev, of_fwnode_handle(no_free_ptr(node)));
return 0;
diff --git a/drivers/pci/pwrctrl/core.c b/drivers/pci/pwrctrl/core.c
index 7754baed67f2..72963a92362a 100644
--- a/drivers/pci/pwrctrl/core.c
+++ b/drivers/pci/pwrctrl/core.c
@@ -39,7 +39,7 @@ static int pci_pwrctrl_notify(struct notifier_block *nb, unsigned long action,
* If we got here then the PCI device is the second after the
* power control platform device. Mark its OF node as reused.
*/
- dev->of_node_reused = true;
+ dev_set_of_node_reused(dev);
break;
}
diff --git a/drivers/regulator/bq257xx-regulator.c b/drivers/regulator/bq257xx-regulator.c
index dab8f1ab4450..40e0f1a7ae81 100644
--- a/drivers/regulator/bq257xx-regulator.c
+++ b/drivers/regulator/bq257xx-regulator.c
@@ -143,7 +143,7 @@ static int bq257xx_regulator_probe(struct platform_device *pdev)
struct regulator_config cfg = {};
pdev->dev.of_node = pdev->dev.parent->of_node;
- pdev->dev.of_node_reused = true;
+ dev_set_of_node_reused(&pdev->dev);
pdata = devm_kzalloc(&pdev->dev, sizeof(struct bq257xx_reg_data), GFP_KERNEL);
if (!pdata)
diff --git a/drivers/regulator/rk808-regulator.c b/drivers/regulator/rk808-regulator.c
index e66408f23bb6..8297d31cde9f 100644
--- a/drivers/regulator/rk808-regulator.c
+++ b/drivers/regulator/rk808-regulator.c
@@ -2115,7 +2115,7 @@ static int rk808_regulator_probe(struct platform_device *pdev)
int ret, i, nregulators;
pdev->dev.of_node = pdev->dev.parent->of_node;
- pdev->dev.of_node_reused = true;
+ dev_set_of_node_reused(&pdev->dev);
regmap = dev_get_regmap(pdev->dev.parent, NULL);
if (!regmap)
diff --git a/drivers/tty/serial/serial_base_bus.c b/drivers/tty/serial/serial_base_bus.c
index a12935f6b992..5f23284a8778 100644
--- a/drivers/tty/serial/serial_base_bus.c
+++ b/drivers/tty/serial/serial_base_bus.c
@@ -74,7 +74,7 @@ static int serial_base_device_init(struct uart_port *port,
dev->parent = parent_dev;
dev->bus = &serial_base_bus_type;
dev->release = release;
- dev->of_node_reused = true;
+ dev_set_of_node_reused(dev);
device_set_node(dev, fwnode_handle_get(dev_fwnode(parent_dev)));
diff --git a/drivers/usb/gadget/udc/aspeed-vhub/dev.c b/drivers/usb/gadget/udc/aspeed-vhub/dev.c
index 2ecd049dacc2..8b9449d16324 100644
--- a/drivers/usb/gadget/udc/aspeed-vhub/dev.c
+++ b/drivers/usb/gadget/udc/aspeed-vhub/dev.c
@@ -593,7 +593,7 @@ int ast_vhub_init_dev(struct ast_vhub *vhub, unsigned int idx)
d->gadget.max_speed = USB_SPEED_HIGH;
d->gadget.speed = USB_SPEED_UNKNOWN;
d->gadget.dev.of_node = vhub->pdev->dev.of_node;
- d->gadget.dev.of_node_reused = true;
+ dev_set_of_node_reused(&d->gadget.dev);
rc = usb_add_gadget_udc(d->port_dev, &d->gadget);
if (rc != 0)
diff --git a/include/linux/device.h b/include/linux/device.h
index 5b0fb6ad4c72..a79865a212e9 100644
--- a/include/linux/device.h
+++ b/include/linux/device.h
@@ -483,6 +483,8 @@ struct device_physical_location {
* driver/bus sync_state() callback.
* @DEV_FLAG_DMA_COHERENT: This particular device is dma coherent, even if the
* architecture supports non-coherent devices.
+ * @DEV_FLAG_OF_NODE_REUSED: Set if the device-tree node is shared with an
+ * ancestor device.
*/
enum struct_device_flags {
DEV_FLAG_READY_TO_PROBE = 0,
@@ -492,6 +494,7 @@ enum struct_device_flags {
DEV_FLAG_DMA_OPS_BYPASS = 4,
DEV_FLAG_STATE_SYNCED = 5,
DEV_FLAG_DMA_COHERENT = 6,
+ DEV_FLAG_OF_NODE_REUSED = 7,
DEV_FLAG_COUNT
};
@@ -573,8 +576,6 @@ enum struct_device_flags {
*
* @offline_disabled: If set, the device is permanently online.
* @offline: Set after successful invocation of bus type's .offline().
- * @of_node_reused: Set if the device-tree node is shared with an ancestor
- * device.
* @flags: DEV_FLAG_XXX flags. Use atomic bitfield operations to modify.
*
* At the lowest level, every device in a Linux system is represented by an
@@ -681,7 +682,6 @@ struct device {
bool offline_disabled:1;
bool offline:1;
- bool of_node_reused:1;
DECLARE_BITMAP(flags, DEV_FLAG_COUNT);
};
@@ -715,6 +715,7 @@ __create_dev_flag_accessors(dma_skip_sync, DEV_FLAG_DMA_SKIP_SYNC);
__create_dev_flag_accessors(dma_ops_bypass, DEV_FLAG_DMA_OPS_BYPASS);
__create_dev_flag_accessors(state_synced, DEV_FLAG_STATE_SYNCED);
__create_dev_flag_accessors(dma_coherent, DEV_FLAG_DMA_COHERENT);
+__create_dev_flag_accessors(of_node_reused, DEV_FLAG_OF_NODE_REUSED);
#undef __create_dev_flag_accessors
--
2.53.0.1213.gd9a14994de-goog
^ permalink raw reply related
* [PATCH v5 0/9] driver core: Fix some race conditions
From: Douglas Anderson @ 2026-04-06 23:22 UTC (permalink / raw)
To: Greg Kroah-Hartman, Rafael J . Wysocki, Danilo Krummrich,
Alan Stern
Cc: Alexey Kardashevskiy, Johan Hovold, Eric Dumazet, Leon Romanovsky,
Christoph Hellwig, Robin Murphy, maz, Alexander Lobakin,
Saravana Kannan, Douglas Anderson, Andrew Morton, Frank.Li,
Jason Gunthorpe, alex, alexander.stein, andre.przywara, andrew,
andrew, andriy.shevchenko, aou, ardb, astewart, bhelgaas, brgl,
broonie, catalin.marinas, chleroy, davem, david, devicetree,
dmaengine, driver-core, gbatra, gregory.clement, hkallweit1,
iommu, jirislaby, joel, joro, kees, kevin.brodsky, kuba, lenb,
lgirdwood, linux-acpi, linux-arm-kernel, linux-aspeed, linux-cxl,
linux-kernel, linux-mips, linux-mm, linux-pci, linux-riscv,
linux-serial, linux-snps-arc, linux-usb, linux, linuxppc-dev,
m.szyprowski, maddy, mani, miko.lenczewski, mpe, netdev, npiggin,
osalvador, oupton, pabeni, palmer, peter.ujfalusi, peterz, pjw,
robh, sebastian.hesselbarth, tglx, tsbogend, vgupta, vkoul, will,
willy, yangyicong, yeoreum.yun
The main goal of this series is to fix the observed bug talked about
in the first patch ("driver core: Don't let a device probe until it's
ready"). That patch fixes a problem that has been observed in the real
world and could land even if the rest of the patches are found
unacceptable or need to be spun.
That said, during patch review Danilo correctly pointed out that many
of the bitfield accesses in "struct device" are unsafe. I added a
bunch of patches in the series to address each one.
Danilo said he's most worried about "can_match", so I put that one
first. After that, I tried to transition bitfields to flags in reverse
order to when the bitfield was added.
Even if transitioning from bitfields to flags isn't truly needed for
correctness, it seems silly (and wasteful of space in struct device)
to have some in bitfields and some as flags. Thus I didn't spend time
for each bitfield showing that it's truly needed for correctness.
Transition was done semi manually. Presumably someone skilled at
coccinelle could do a better job, but I just used sed in a heavy-
handed manner and then reviewed/fixed the results, undoing anything my
script got wrong. My terrible/ugly script was:
var=can_match
caps="${var^^}"
for f in $(git grep -l "[>\.]${var}[^1-9_a-zA-Z\[]"); do
echo $f
sed -i~ -e "s/\([a-zA-Z_0-9\.>()-][a-zA-Z_0-9\.>()-]*\)->${var} = true/set_bit(DEV_FLAG_${caps}, \&\\1->flags)/" "$f"
sed -i~ -e "s/\([a-zA-Z_0-9\.>()-][a-zA-Z_0-9\.>()-]*\)\.${var} = true/dev_set_${caps}(\&\\1)/" "$f"
sed -i~ -e "s/\([a-zA-Z_0-9\.>()-][a-zA-Z_0-9\.>()-]*\)->${var} = false/clear_bit(DEV_FLAG_${caps}, \&\\1->flags)/" "$f"
sed -i~ -e "s/\([a-zA-Z_0-9\.>()-][a-zA-Z_0-9\.>()-]*\)\.${var} = false/dev_clear_${caps}(\&\\1)/" "$f"
sed -i~ -e "s/\([a-zA-Z_0-9\.>()-][a-zA-Z_0-9\.>()-]*\)->${var} = \([^;]*\)/assign_bit(DEV_FLAG_${caps}, \&\\1->flags, \\2)/" "$f"
sed -i~ -e "s/\([a-zA-Z_0-9\.>()-][a-zA-Z_0-9\.>()-]*\)\.${var} = \([^;]*\)/dev_assign_${caps}(\&\\1, \\2)/" "$f"
sed -i~ -e "s/\([a-zA-Z_0-9\.>()-][a-zA-Z_0-9\.>()-]*\)->${var}\([^1-9_a-zA-Z\[]\)/test_bit(DEV_FLAG_${caps}, \&\\1->flags)\\2/" "$f"
sed -i~ -e "s/\([a-zA-Z_0-9\.>()-][a-zA-Z_0-9\.>()-]*\)\.${var}\([^1-9_a-zA-Z\[]\)/dev_${caps}(\&\\1)\\2/" "$f"
done
From v3 to v4, I transitioned to accessor functions with another ugly
sed script. I had git format the old patches, then transformed them
with:
for f in *.patch; do
echo $f
sed -i~ -e "s/test_and_set_bit(DEV_FLAG_\([^,]*\), \&\(.*\)->flags)/dev_test_and_set_\\L\\1(\\2)/" "$f"
sed -i~ -e "s/test_and_set_bit(DEV_FLAG_\([^,]*\), \(.*\)\.flags)/dev_test_and_set_\\L\\1(\\2)/" "$f"
sed -i~ -e "s/test_bit(DEV_FLAG_\([^,]*\), \&\(.*\)->flags)/dev_\\L\\1(\\2)/" "$f"
sed -i~ -e "s/test_bit(DEV_FLAG_\([^,]*\), \(.*\)\.flags)/dev_\\L\\1(\\2)/" "$f"
sed -i~ -e "s/set_bit(DEV_FLAG_\([^,]*\), \&\(.*\)->flags)/dev_set_\\L\\1(\\2)/" "$f"
sed -i~ -e "s/set_bit(DEV_FLAG_\([^,]*\), \(.*\)\.flags)/dev_set_\\L\\1(\\2)/" "$f"
sed -i~ -e "s/clear_bit(DEV_FLAG_\([^,]*\), \&\(.*\)->flags)/dev_clear_\\L\\1(\\2)/" "$f"
sed -i~ -e "s/clear_bit(DEV_FLAG_\([^,]*\), \(.*\)\.flags)/dev_clear_\\L\\1(\\2)/" "$f"
sed -i~ -e "s/assign_bit(DEV_FLAG_\([^,]*\), \&\(.*\)->flags, \(.*\))/dev_assign_\\L\\1(\\2, \\3)/" "$f"
sed -i~ -e "s/assign_bit(DEV_FLAG_\([^,]*\), \(.*\)\.flags, \(.*\))/dev_assign_\\L\\1(\\2, \\3)/" "$f"
done
...and then did a few manual touchups for spacing.
I only marked the first patch as a "Fix" since it is the only one
fixing observed problems. Other patches could be considered fixes too
if folks want.
I tested the first patch in the series backported to kernel 6.6 on the
Pixel phone that was experiencing the race. I added extra printouts to
make sure that the problem was hitting / addressed. The rest of the
patches are tested with allmodconfig with arm32, arm64, ppc, and
x86. I boot tested on an arm64 Chromebook running mainline.
Changes in v5:
- ready_to_prove => ready_to_probe typo
- device_lock() while calling dev_set_ready_to_probe()
- Add comment before "can_match = true" from Danilo.
- undef __create_dev_flag_accessors
Changes in v4:
- Use accessor functions for flags
Changes in v3:
- Use a new "flags" bitfield
- Add missing \n in probe error message
Changes in v2:
- Instead of adjusting the ordering, use "ready_to_probe" flag
Douglas Anderson (9):
driver core: Don't let a device probe until it's ready
driver core: Replace dev->can_match with dev_can_match()
driver core: Replace dev->dma_iommu with dev_dma_iommu()
driver core: Replace dev->dma_skip_sync with dev_dma_skip_sync()
driver core: Replace dev->dma_ops_bypass with dev_dma_ops_bypass()
driver core: Replace dev->state_synced with dev_state_synced()
driver core: Replace dev->dma_coherent with dev_dma_coherent()
driver core: Replace dev->of_node_reused with dev_of_node_reused()
driver core: Replace dev->offline + ->offline_disabled with accessors
arch/arc/mm/dma.c | 4 +-
arch/arm/mach-highbank/highbank.c | 2 +-
arch/arm/mach-mvebu/coherency.c | 2 +-
arch/arm/mm/dma-mapping-nommu.c | 4 +-
arch/arm/mm/dma-mapping.c | 28 ++--
arch/arm64/kernel/cpufeature.c | 2 +-
arch/arm64/mm/dma-mapping.c | 2 +-
arch/mips/mm/dma-noncoherent.c | 2 +-
arch/powerpc/kernel/dma-iommu.c | 8 +-
.../platforms/pseries/hotplug-memory.c | 4 +-
arch/riscv/mm/dma-noncoherent.c | 2 +-
drivers/acpi/scan.c | 2 +-
drivers/base/core.c | 55 +++++---
drivers/base/cpu.c | 4 +-
drivers/base/dd.c | 36 ++++--
drivers/base/memory.c | 2 +-
drivers/base/pinctrl.c | 2 +-
drivers/base/platform.c | 2 +-
drivers/dma/ti/k3-udma-glue.c | 6 +-
drivers/dma/ti/k3-udma.c | 6 +-
drivers/iommu/dma-iommu.c | 9 +-
drivers/iommu/iommu.c | 5 +-
drivers/net/pcs/pcs-xpcs-plat.c | 2 +-
drivers/of/device.c | 6 +-
drivers/pci/of.c | 2 +-
drivers/pci/pwrctrl/core.c | 2 +-
drivers/regulator/bq257xx-regulator.c | 2 +-
drivers/regulator/rk808-regulator.c | 2 +-
drivers/tty/serial/serial_base_bus.c | 2 +-
drivers/usb/gadget/udc/aspeed-vhub/dev.c | 2 +-
include/linux/device.h | 122 ++++++++++++------
include/linux/dma-map-ops.h | 6 +-
include/linux/dma-mapping.h | 2 +-
include/linux/iommu-dma.h | 3 +-
kernel/cpu.c | 4 +-
kernel/dma/mapping.c | 12 +-
mm/hmm.c | 2 +-
37 files changed, 218 insertions(+), 142 deletions(-)
--
2.53.0.1213.gd9a14994de-goog
^ permalink raw reply
* Re: [PATCH v1 1/2] dt-bindings: chrome: Add cros-ec-ucsi compatibility to typec binding
From: Rob Herring (Arm) @ 2026-04-06 22:49 UTC (permalink / raw)
To: Jameson Thies
Cc: abhishekpandit, akuchynski, devicetree, chrome-platform, bleung,
conor+dt, linux-kernel, heikki.krogerus, linux-usb, krzk+dt,
gregkh
In-Reply-To: <20260403223357.1896403-2-jthies@google.com>
On Fri, 03 Apr 2026 22:33:26 +0000, Jameson Thies wrote:
> Chrome OS devices with discrete power delivery controllers (PDCs) allow
> the host to read port status and control port behavior through a USB
> Type-C Connector System Software (UCSI) interface with the embedded
> controller (EC). This uses a separate interface driver than other
> Chrome OS devices with a Type-C port manager in the EC FW. Those use
> a host command interface supported by cros-ec-typec. Add a cros-ec-ucsi
> compatibility string to the existing cros-ec-typec binding.
>
> Additionally, update maintainer list to reflect cros-ec-ucsi and
> cros-ec-typec driver maintainers.
>
> Signed-off-by: Jameson Thies <jthies@google.com>
> ---
> .../bindings/chrome/google,cros-ec-typec.yaml | 19 +++++++++++++++----
> 1 file changed, 15 insertions(+), 4 deletions(-)
>
Reviewed-by: Rob Herring (Arm) <robh@kernel.org>
^ permalink raw reply
* Re: [PATCH v4] usbip: tools: add hint when no exported devices are found
From: Shuah Khan @ 2026-04-06 21:12 UTC (permalink / raw)
To: Zongmin Zhou
Cc: gregkh, i, linux-kernel, linux-usb, valentina.manea.m,
Zongmin Zhou, Shuah Khan
In-Reply-To: <20260402083204.53179-1-min_halo@163.com>
On 4/2/26 02:32, Zongmin Zhou wrote:
> From: Zongmin Zhou <zhouzongmin@kylinos.cn>
>
> When refresh_exported_devices() finds no devices, it's helpful to
> inform users about potential causes. This could be due to:
>
> 1. The usbip driver module is not loaded.
> 2. No devices have been exported yet.
>
> Add an informational message to guide users when ndevs == 0.
>
> Also update the condition in usbip_host_driver_open() and
> usbip_device_driver_open() to check both ret and ndevs == 0,
> and change err() to info().
>
> Message visibility by scenario:
> - usbipd (console mode): Show on console/serial, this allows instant
> visibility for debugging.
> - usbipd -D (daemon mode): Message logged to syslog, can keep logs for
> later traceability in production. Also can use "journalctl -f" to
> trace on console.
>
> Suggested-by: Shuah Khan <skhan@linuxfoundation.org>
> Signed-off-by: Zongmin Zhou <zhouzongmin@kylinos.cn>
> ---
> Changes in v4:
> - Printing behavior adjusted as suggested.
> Changes in v3:
> - Just add an informational message when no devices are found.
> Changes in v2:
> - Use system calls directly instead of checking sysfs dir.
>
> tools/usb/usbip/libsrc/usbip_device_driver.c | 6 +++---
> tools/usb/usbip/libsrc/usbip_host_common.c | 3 +++
> tools/usb/usbip/libsrc/usbip_host_driver.c | 7 ++++---
> 3 files changed, 10 insertions(+), 6 deletions(-)
>
> diff --git a/tools/usb/usbip/libsrc/usbip_device_driver.c b/tools/usb/usbip/libsrc/usbip_device_driver.c
> index 927a151fa9aa..1dfbb76ab26c 100644
> --- a/tools/usb/usbip/libsrc/usbip_device_driver.c
> +++ b/tools/usb/usbip/libsrc/usbip_device_driver.c
> @@ -137,9 +137,9 @@ static int usbip_device_driver_open(struct usbip_host_driver *hdriver)
> INIT_LIST_HEAD(&hdriver->edev_list);
>
> ret = usbip_generic_driver_open(hdriver);
> - if (ret)
> - err("please load " USBIP_CORE_MOD_NAME ".ko and "
> - USBIP_DEVICE_DRV_NAME ".ko!");
> + if (ret || hdriver->ndevs == 0)
> + info("please load " USBIP_CORE_MOD_NAME ".ko and "
> + USBIP_DEVICE_DRV_NAME ".ko");
>
> return ret;
> }
> diff --git a/tools/usb/usbip/libsrc/usbip_host_common.c b/tools/usb/usbip/libsrc/usbip_host_common.c
> index ca78aa368476..01599cb2fa7b 100644
> --- a/tools/usb/usbip/libsrc/usbip_host_common.c
> +++ b/tools/usb/usbip/libsrc/usbip_host_common.c
> @@ -149,6 +149,9 @@ static int refresh_exported_devices(struct usbip_host_driver *hdriver)
> }
> }
>
> + if (hdriver->ndevs == 0)
> + info("Please load appropriate modules or export devices.");
Is this message needed here in refresh_exported_devices()?
usbip_host_driver_open() and usbip_device_driver_open(), the
only two callers of refresh_exported_devices() print info
message with this change?
thanks,
-- Shuah
^ permalink raw reply
* [Bug 221318] mice behind ASMedia ASM1042A via Thunderbolt 2 never produce input, most likely due to interrupt pipe idle window during enumeration
From: bugzilla-daemon @ 2026-04-06 20:11 UTC (permalink / raw)
To: linux-usb
In-Reply-To: <bug-221318-208809@https.bugzilla.kernel.org/>
https://bugzilla.kernel.org/show_bug.cgi?id=221318
--- Comment #18 from manauer.uel@gmail.com ---
One addition to the mouse comparison table. I checked the Logitech Lightspeed
Receiver, the wireless dongle that was observed earlier to make all other mice
work when plugged in alongside them and the wired mouse re-plugged ...
Logitech Lightspeed Receiver (046d:c539) 3 1ms/1ms/1ms yes
It has 3 interfaces, all polling at 1ms, which is exactly the same profile as
the failing mice. Yet it works on its own and somehow makes wired mice work
alongside it. This unfortunately does not fit the pattern from the previous
comment.
--
You may reply to this email to add a comment.
You are receiving this mail because:
You are watching the assignee of the bug.
^ permalink raw reply
* [Bug 221318] mice behind ASMedia ASM1042A via Thunderbolt 2 never produce input, most likely due to interrupt pipe idle window during enumeration
From: bugzilla-daemon @ 2026-04-06 20:06 UTC (permalink / raw)
To: linux-usb
In-Reply-To: <bug-221318-208809@https.bugzilla.kernel.org/>
https://bugzilla.kernel.org/show_bug.cgi?id=221318
--- Comment #17 from manauer.uel@gmail.com ---
> I could look at it out of curiosity, I think the simplest way is to
> zip -r debugfs.zip /sys/kernel/debug/usb/xhci/0000:0a:00.0
> shortly after it happens, should be enough if the bus isn't very busy.
I attached the zip file. It was captured by connecting the mouse without the
udev rule active and without the dongle, waiting about 10 seconds, then running
your suggested command.
sudo zip -r debugfs.zip /sys/kernel/debug/usb/xhci/0000:0a:00.0
> Weird. I think the receiver has a different polling rate (1ms?). Do you have
> more mice to check if it's a consistent pattern that things only work if at
> least one 1ms device is connected, or something stupid like that?
This was a surprise. It turns out there are mice that work fine without any
workaround. I swear, the four mice I originally tested were all Logitech plus
one no-name mouse from my partner, and none of them worked, which is why this
did not come up earlier.
Mouse Interfaces bInterval Works
Lenovo USB Optical (17ef:608d) 1 10ms yes
Microsoft Comfort 3000 (045e:077b) 1 10ms yes
Holtek MGK-15BU (04d9:1135) 1 10ms yes
Logitech G5 (046d:c049) 2 1ms/10ms no
Logitech G Pro Wireless (046d:c088) 3 1ms/1ms/1ms no (tested via
cable)
Logitech G403 ? ? no (not at
hand)
Another no-name mouse (partner's) ? ? no (not at
hand)
The working mice all have a single interface. The failing mice all have
multiple interfaces and at least one endpoint polling at 1ms. The G Pro
Wireless was connected via cable for this test. Its wireless dongle (046d:c539)
was not plugged in during any of these tests. That dongle is the same one that
was observed earlier to make all other mice work when plugged in alongside
them.
> Are you able to run a patched kernel? Lacking better ideas, I suppose we
> could force 1ms polling and see what happens (don't bother with usbhid
> mousepoll option - it doesn't work on xhci-hcd).
Sure, I can try running a patched kernel if you think it is worth it, just for
testing. I would not want to maintain a custom kernel long term, but a one-off
build to confirm a fix is fine. Given the data above though, forcing 1ms might
make things worse rather than better since 1ms seems to be what correlates with
failure. Would forcing 10ms on the failing mice be a more interesting test?
> Maybe, but you suggest to disable a power saving feature everywhere for the
> sake of one old questionable xHCI controller. Maybe there is a better way.
That is a fair point. If there is a more targeted fix, either in the ASM1042A
handling or scoped to the controller rather than all mice, that would obviously
be preferable. I am happy to test whatever approach you think makes more sense.
--
You may reply to this email to add a comment.
You are receiving this mail because:
You are watching the assignee of the bug.
^ permalink raw reply
* [Bug 221318] mice behind ASMedia ASM1042A via Thunderbolt 2 never produce input, most likely due to interrupt pipe idle window during enumeration
From: bugzilla-daemon @ 2026-04-06 19:56 UTC (permalink / raw)
To: linux-usb
In-Reply-To: <bug-221318-208809@https.bugzilla.kernel.org/>
https://bugzilla.kernel.org/show_bug.cgi?id=221318
--- Comment #16 from manauer.uel@gmail.com ---
Created attachment 309839
--> https://bugzilla.kernel.org/attachment.cgi?id=309839&action=edit
ASMedia ASM1042A debugfs state, captured ~10s after connecting non-working
Logitech G5 mouse
--
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
* [usb:usb-testing] BUILD SUCCESS 3723393cc284e09107c0f55c47458b75b29be2c3
From: kernel test robot @ 2026-04-06 19:51 UTC (permalink / raw)
To: Greg Kroah-Hartman; +Cc: linux-usb
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git usb-testing
branch HEAD: 3723393cc284e09107c0f55c47458b75b29be2c3 Merge tag 'v7.0-rc7' into usb-next
elapsed time: 736m
configs tested: 187
configs skipped: 25
The following configs have been built successfully.
More configs may be tested in the coming days.
tested configs:
alpha allnoconfig gcc-15.2.0
alpha allyesconfig gcc-15.2.0
alpha defconfig gcc-15.2.0
arc allmodconfig clang-16
arc allnoconfig gcc-15.2.0
arc allyesconfig clang-23
arc allyesconfig gcc-15.2.0
arc defconfig gcc-15.2.0
arc randconfig-001-20260406 gcc-10.5.0
arc randconfig-002-20260406 gcc-10.5.0
arm allnoconfig gcc-15.2.0
arm allyesconfig clang-16
arm defconfig gcc-15.2.0
arm randconfig-001-20260406 clang-17
arm randconfig-002-20260406 clang-23
arm randconfig-003-20260406 clang-23
arm randconfig-004-20260406 gcc-13.4.0
arm64 allmodconfig clang-19
arm64 allmodconfig clang-23
arm64 allnoconfig gcc-15.2.0
arm64 defconfig gcc-15.2.0
arm64 randconfig-001-20260406 gcc-10.5.0
arm64 randconfig-002-20260406 gcc-10.5.0
arm64 randconfig-003-20260406 gcc-10.5.0
arm64 randconfig-004-20260406 gcc-10.5.0
csky allmodconfig gcc-15.2.0
csky allnoconfig gcc-15.2.0
csky defconfig gcc-15.2.0
csky randconfig-001-20260406 gcc-10.5.0
csky randconfig-002-20260406 gcc-10.5.0
hexagon allmodconfig gcc-15.2.0
hexagon allnoconfig gcc-15.2.0
hexagon defconfig gcc-15.2.0
hexagon randconfig-001-20260406 clang-23
hexagon randconfig-002-20260406 clang-23
i386 allmodconfig clang-20
i386 allnoconfig gcc-15.2.0
i386 allyesconfig clang-20
i386 buildonly-randconfig-001-20260406 clang-20
i386 buildonly-randconfig-001-20260406 gcc-14
i386 buildonly-randconfig-002-20260406 clang-20
i386 buildonly-randconfig-002-20260406 gcc-14
i386 buildonly-randconfig-003-20260406 clang-20
i386 buildonly-randconfig-003-20260406 gcc-14
i386 buildonly-randconfig-004-20260406 gcc-14
i386 buildonly-randconfig-005-20260406 clang-20
i386 buildonly-randconfig-005-20260406 gcc-14
i386 buildonly-randconfig-006-20260406 gcc-13
i386 buildonly-randconfig-006-20260406 gcc-14
i386 defconfig gcc-15.2.0
i386 randconfig-001-20260406 clang-20
i386 randconfig-001-20260406 gcc-13
i386 randconfig-002-20260406 clang-20
i386 randconfig-002-20260406 gcc-13
i386 randconfig-003-20260406 clang-20
i386 randconfig-003-20260406 gcc-13
i386 randconfig-004-20260406 clang-20
i386 randconfig-004-20260406 gcc-13
i386 randconfig-005-20260406 clang-20
i386 randconfig-005-20260406 gcc-13
i386 randconfig-006-20260406 clang-20
i386 randconfig-007-20260406 clang-20
i386 randconfig-007-20260406 gcc-13
i386 randconfig-011-20260406 gcc-14
i386 randconfig-012-20260406 gcc-14
i386 randconfig-013-20260406 gcc-14
i386 randconfig-014-20260406 gcc-14
i386 randconfig-015-20260406 gcc-14
i386 randconfig-016-20260406 gcc-14
i386 randconfig-017-20260406 gcc-14
loongarch allmodconfig clang-19
loongarch allmodconfig clang-23
loongarch allnoconfig gcc-15.2.0
loongarch defconfig clang-19
loongarch randconfig-001-20260406 clang-23
loongarch randconfig-002-20260406 clang-23
m68k allmodconfig gcc-15.2.0
m68k allnoconfig gcc-15.2.0
m68k allyesconfig clang-16
m68k defconfig clang-19
m68k defconfig gcc-15.2.0
microblaze allnoconfig gcc-15.2.0
microblaze allyesconfig gcc-15.2.0
microblaze defconfig clang-19
microblaze defconfig gcc-15.2.0
mips allmodconfig gcc-15.2.0
mips allnoconfig gcc-15.2.0
mips allyesconfig gcc-15.2.0
mips loongson3_defconfig gcc-15.2.0
nios2 allmodconfig clang-23
nios2 allnoconfig clang-23
nios2 defconfig clang-19
nios2 defconfig gcc-15.2.0
nios2 randconfig-001-20260406 clang-23
nios2 randconfig-002-20260406 clang-23
openrisc allmodconfig clang-23
openrisc allnoconfig clang-23
openrisc defconfig gcc-15.2.0
parisc allmodconfig gcc-15.2.0
parisc allnoconfig clang-23
parisc allyesconfig gcc-15.2.0
parisc defconfig gcc-15.2.0
parisc randconfig-001-20260406 clang-23
parisc randconfig-002-20260406 clang-23
parisc64 defconfig clang-19
parisc64 defconfig gcc-15.2.0
powerpc allmodconfig gcc-15.2.0
powerpc allnoconfig clang-23
powerpc randconfig-001-20260406 clang-23
powerpc randconfig-002-20260406 clang-23
powerpc64 randconfig-001-20260406 clang-23
powerpc64 randconfig-002-20260406 clang-23
riscv allmodconfig clang-23
riscv allnoconfig clang-23
riscv allyesconfig clang-16
riscv defconfig gcc-15.2.0
riscv randconfig-001-20260406 gcc-8.5.0
riscv randconfig-002-20260406 gcc-8.5.0
s390 allmodconfig clang-18
s390 allnoconfig clang-23
s390 allyesconfig gcc-15.2.0
s390 defconfig gcc-15.2.0
s390 randconfig-001-20260406 gcc-8.5.0
s390 randconfig-002-20260406 gcc-8.5.0
sh allmodconfig gcc-15.2.0
sh allnoconfig clang-23
sh allyesconfig gcc-15.2.0
sh defconfig gcc-14
sh randconfig-001-20260406 gcc-8.5.0
sh randconfig-002-20260406 gcc-8.5.0
sparc allnoconfig clang-23
sparc defconfig gcc-15.2.0
sparc randconfig-001-20260406 gcc-11.5.0
sparc randconfig-002-20260406 gcc-15.2.0
sparc64 allmodconfig clang-23
sparc64 defconfig gcc-14
sparc64 randconfig-001-20260406 clang-23
sparc64 randconfig-002-20260406 gcc-12.5.0
um allmodconfig clang-19
um allnoconfig clang-23
um allyesconfig gcc-15.2.0
um defconfig gcc-14
um i386_defconfig gcc-14
um randconfig-001-20260406 clang-17
um randconfig-002-20260406 clang-23
um x86_64_defconfig gcc-14
x86_64 allmodconfig clang-20
x86_64 allnoconfig clang-23
x86_64 allyesconfig clang-20
x86_64 buildonly-randconfig-001-20260406 gcc-14
x86_64 buildonly-randconfig-002-20260406 gcc-14
x86_64 buildonly-randconfig-003-20260406 gcc-14
x86_64 buildonly-randconfig-004-20260406 gcc-14
x86_64 buildonly-randconfig-005-20260406 gcc-14
x86_64 buildonly-randconfig-006-20260406 gcc-14
x86_64 defconfig gcc-14
x86_64 kexec clang-20
x86_64 randconfig-001-20260406 gcc-14
x86_64 randconfig-002-20260406 gcc-14
x86_64 randconfig-003-20260406 gcc-14
x86_64 randconfig-004-20260406 gcc-14
x86_64 randconfig-005-20260406 gcc-14
x86_64 randconfig-006-20260406 gcc-14
x86_64 randconfig-011-20260406 gcc-14
x86_64 randconfig-012-20260406 clang-20
x86_64 randconfig-013-20260406 clang-20
x86_64 randconfig-014-20260406 gcc-14
x86_64 randconfig-015-20260406 clang-20
x86_64 randconfig-016-20260406 gcc-14
x86_64 randconfig-071-20260406 clang-20
x86_64 randconfig-072-20260406 clang-20
x86_64 randconfig-073-20260406 clang-20
x86_64 randconfig-074-20260406 clang-20
x86_64 randconfig-075-20260406 clang-20
x86_64 randconfig-075-20260406 gcc-13
x86_64 randconfig-076-20260406 clang-20
x86_64 rhel-9.4 clang-20
x86_64 rhel-9.4-bpf gcc-14
x86_64 rhel-9.4-func clang-20
x86_64 rhel-9.4-kselftests clang-20
x86_64 rhel-9.4-kunit gcc-14
x86_64 rhel-9.4-ltp gcc-14
x86_64 rhel-9.4-rust clang-20
xtensa allnoconfig clang-23
xtensa allyesconfig clang-23
xtensa randconfig-001-20260406 gcc-12.5.0
xtensa randconfig-002-20260406 gcc-13.4.0
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
^ permalink raw reply
* [Bug 221318] mice behind ASMedia ASM1042A via Thunderbolt 2 never produce input, most likely due to interrupt pipe idle window during enumeration
From: bugzilla-daemon @ 2026-04-06 15:35 UTC (permalink / raw)
To: linux-usb
In-Reply-To: <bug-221318-208809@https.bugzilla.kernel.org/>
https://bugzilla.kernel.org/show_bug.cgi?id=221318
--- Comment #15 from Michał Pecio (michal.pecio@gmail.com) ---
(In reply to manauer.uel from comment #14)
> Something I did not notice before appears in both new logs: after the Cancel
> URB and Set TR Deq sequence completes, the ASMedia controller generates
> these:
>
> xhci_hcd 0000:0a:00.0: Spurious event dma 0x00000000012c50b0, comp_code
> 13 after 13
> xhci_hcd 0000:0a:00.0: Spurious event dma 0x00000000012c50e0, comp_code
> 13 after 13
This may be valid HW behavior and sloppiness of the driver, if something is
submitting long and/or complex URBs, though I'm not sure what such URBs would
be doing on a bus with only hubs and HIDs. Or it may be a HW bug. Either way,
these pointers look like it comes from some other endpoint.
I could look at it out of curiosity, I think the simplest way is to
zip -r debugfs.zip /sys/kernel/debug/usb/xhci/0000:0a:00.0
shortly after it happens, should be enough if the bus isn't very busy.
Actually, if you upload this with the mouse recently connected and not working
we could inspect all those URBs and commands written to memory and check for
(or eliminate) most possible driver bugs. I suspect it's a HW bug.
> The wireless dongle itself also has Cancel URBs on ep 0x81 and ep 0x82
> during its own enumeration, but it recovers fine and no spurious events
> follow its cancellations. The wired mouse does not recover the same way.
Weird. I think the receiver has a different polling rate (1ms?). Do you have
more mice to check if it's a consistent pattern that things only work if at
least one 1ms device is connected, or something stupid like that?
Are you able to run a patched kernel? Lacking better ideas, I suppose we could
force 1ms polling and see what happens (don't bother with usbhid mousepoll
option - it doesn't work on xhci-hcd).
> Would it be possible to have a quirk that applies to a whole subset of
> devices (in this case mice), instead of one specific device only?
Maybe, but you suggest to disable a power saving feature everywhere for the
sake of one old questionable xHCI controller. Maybe there is a better way.
--
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
* [PATCH] usb: gadget: renesas_usb3: validate endpoint index in standard request handlers
From: Greg Kroah-Hartman @ 2026-04-06 15:09 UTC (permalink / raw)
To: linux-usb; +Cc: Greg Kroah-Hartman, stable
The GET_STATUS and SET/CLEAR_FEATURE handlers extract the endpoint
number from the host-supplied wIndex without any sort of validation.
Fix this up by validating the number of endpoints actually match up with
the number the device has before attempting to dereference a pointer
based on this math.
This is just like what was done in commit ee0d382feb44 ("usb: gadget:
aspeed_udc: validate endpoint index for ast udc") for the aspeed driver.
Fixes: 746bfe63bba3 ("usb: gadget: renesas_usb3: add support for Renesas USB3.0 peripheral controller")
Cc: stable <stable@kernel.org>
Assisted-by: gregkh_clanker_t1000
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/usb/gadget/udc/renesas_usb3.c | 7 ++++++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/drivers/usb/gadget/udc/renesas_usb3.c b/drivers/usb/gadget/udc/renesas_usb3.c
index b0b264d34919..2c9c3e935a5e 100644
--- a/drivers/usb/gadget/udc/renesas_usb3.c
+++ b/drivers/usb/gadget/udc/renesas_usb3.c
@@ -1669,6 +1669,10 @@ static bool usb3_std_req_get_status(struct renesas_usb3 *usb3,
break;
case USB_RECIP_ENDPOINT:
num = le16_to_cpu(ctrl->wIndex) & USB_ENDPOINT_NUMBER_MASK;
+ if (num >= usb3->num_usb3_eps) {
+ stall = true;
+ break;
+ }
usb3_ep = usb3_get_ep(usb3, num);
if (usb3_ep->halt)
status |= 1 << USB_ENDPOINT_HALT;
@@ -1781,7 +1785,8 @@ static bool usb3_std_req_feature_endpoint(struct renesas_usb3 *usb3,
struct renesas_usb3_ep *usb3_ep;
struct renesas_usb3_request *usb3_req;
- if (le16_to_cpu(ctrl->wValue) != USB_ENDPOINT_HALT)
+ if ((le16_to_cpu(ctrl->wValue) != USB_ENDPOINT_HALT) ||
+ (num >= usb3->num_usb3_eps))
return true; /* stall */
usb3_ep = usb3_get_ep(usb3, num);
--
2.53.0
^ permalink raw reply related
* [PATCH] usb: core: config: reverse the size check of the SSP isoc endpoint descriptor
From: Greg Kroah-Hartman @ 2026-04-06 14:18 UTC (permalink / raw)
To: linux-usb; +Cc: Greg Kroah-Hartman
Reverse the check of the size of the usb_ssp_isoc_ep_comp_descriptor
structure to be done before accessing the structure itself.
Functionally, this doesn't really do anything as the buffer is all
internal to the kernel, and reading off the end is just fine, but static
checking tools get picky when noticing that a potential read could be
made "outside" of an allocated buffer.
Not a bugfix, but a cleanup to keep tools from tripping over this
constantly and annoying me with their pointless reports.
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/usb/core/config.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/usb/core/config.c b/drivers/usb/core/config.c
index 6a1fd967e0a6..417140b012bb 100644
--- a/drivers/usb/core/config.c
+++ b/drivers/usb/core/config.c
@@ -54,8 +54,8 @@ static void usb_parse_ssp_isoc_endpoint_companion(struct device *ddev,
* follows the SuperSpeed Endpoint Companion descriptor
*/
desc = (struct usb_ssp_isoc_ep_comp_descriptor *) buffer;
- if (desc->bDescriptorType != USB_DT_SSP_ISOC_ENDPOINT_COMP ||
- size < USB_DT_SSP_ISOC_EP_COMP_SIZE) {
+ if (size < USB_DT_SSP_ISOC_EP_COMP_SIZE ||
+ desc->bDescriptorType != USB_DT_SSP_ISOC_ENDPOINT_COMP) {
dev_notice(ddev, "Invalid SuperSpeedPlus isoc endpoint companion"
"for config %d interface %d altsetting %d ep %d.\n",
cfgno, inum, asnum, ep->desc.bEndpointAddress);
--
2.53.0
^ permalink raw reply related
* [Bug 221318] mice behind ASMedia ASM1042A via Thunderbolt 2 never produce input, most likely due to interrupt pipe idle window during enumeration
From: bugzilla-daemon @ 2026-04-06 11:54 UTC (permalink / raw)
To: linux-usb
In-Reply-To: <bug-221318-208809@https.bugzilla.kernel.org/>
https://bugzilla.kernel.org/show_bug.cgi?id=221318
--- Comment #14 from manauer.uel@gmail.com ---
> One observation that might or might not be related I already mentioned in my
> initial report is that plugging in an unrelated wireless Logitech USB dongle
> into the monitor makes the wired mouse start working after replugging.
> Bizarre. Does it prevent the cancellation, or does it work despite it?
It works despite the cancellation. The Cancel URB on ep 0x81 still happens with
the dongle present, same as without it.
Note: I had to add a USB hub between the monitor and the mouse to have enough
ports for the dongle, so the mouse now shows up as 3-1.1.4 instead of 3-1.1.
The issue persists the same way through the hub. Current topology on the
ASMedia controller:
/: Bus 003.Port 001: Dev 001, Class=root_hub, Driver=xhci_hcd/2p, 480M
ID 1d6b:0002 Linux Foundation 2.0 root hub
|__ Port 001: Dev 002, If 0, Class=Hub, Driver=hub/4p, 480M
ID 043e:9a10 LG Electronics USA, Inc. 34UC88-B
|__ Port 001: Dev 005, If 0, Class=Hub, Driver=hub/5p, 480M
ID 0bda:5411 Realtek Semiconductor Corp. RTS5411 Hub
|__ Port 001: Dev 006, If 0, Class=Human Interface Device,
Driver=usbhid, 12M
ID fffe:0005
|__ Port 001: Dev 006, If 1, Class=Human Interface Device,
Driver=usbhid, 12M
ID fffe:0005
|__ Port 001: Dev 006, If 2, Class=Human Interface Device,
Driver=usbhid, 12M
ID fffe:0005
|__ Port 004: Dev 011, If 0, Class=Human Interface Device,
Driver=usbhid, 12M
ID 046d:c049 Logitech, Inc. G5 Laser Mouse
|__ Port 004: Dev 011, If 1, Class=Human Interface Device,
Driver=usbhid, 12M
ID 046d:c049 Logitech, Inc. G5 Laser Mouse
Something I did not notice before appears in both new logs: after the Cancel
URB and Set TR Deq sequence completes, the ASMedia controller generates these:
xhci_hcd 0000:0a:00.0: Spurious event dma 0x00000000012c50b0, comp_code 13
after 13
xhci_hcd 0000:0a:00.0: Spurious event dma 0x00000000012c50e0, comp_code 13
after 13
This appears both when the mouse does not work (no rule, no dongle) and when it
does work (dongle present). I do not know what to make of it, but it shows up
in both cases and not in the log with the udev rule active.
The wireless dongle itself also has Cancel URBs on ep 0x81 and ep 0x82 during
its own enumeration, but it recovers fine and no spurious events follow its
cancellations. The wired mouse does not recover the same way.
> Yes, I asked to try with and without workarounds, but the log shows multiple
> disconnections so I wasn't sure what's going on.
I think I replugged it multiple times per test, which made the logs harder to
read. I captured a cleaner second log without the udev rule and without the
dongle to have a baseline. Both logs are attached if useful.
> Yep. I tried the quirk here and it eliminates the cancellation. Without the
> quirk it happens when udev briefly opens and closes the mouse before the GUI
> does. The kernel can't do much about it, besides the quirk.
Would it be possible to have a quirk that applies to a whole subset of devices
(in this case mice), instead of one specific device only?
I am currently away for Easter break, but next weekend I will have access to a
second LG monitor from the same era that shows the same issue. I will check
whether it runs on the same controller.
--
You may reply to this email to add a comment.
You are receiving this mail because:
You are watching the assignee of the bug.
^ permalink raw reply
* [Bug 221318] mice behind ASMedia ASM1042A via Thunderbolt 2 never produce input, most likely due to interrupt pipe idle window during enumeration
From: bugzilla-daemon @ 2026-04-06 11:36 UTC (permalink / raw)
To: linux-usb
In-Reply-To: <bug-221318-208809@https.bugzilla.kernel.org/>
https://bugzilla.kernel.org/show_bug.cgi?id=221318
--- Comment #13 from manauer.uel@gmail.com ---
Created attachment 309833
--> https://bugzilla.kernel.org/attachment.cgi?id=309833&action=edit
dmesg -W with connection through Thunderbolt 2 dongle plugged in udev-rule off
--
You may reply to this email to add a comment.
You are receiving this mail because:
You are watching the assignee of the bug.
^ permalink raw reply
* [Bug 221318] mice behind ASMedia ASM1042A via Thunderbolt 2 never produce input, most likely due to interrupt pipe idle window during enumeration
From: bugzilla-daemon @ 2026-04-06 11:35 UTC (permalink / raw)
To: linux-usb
In-Reply-To: <bug-221318-208809@https.bugzilla.kernel.org/>
https://bugzilla.kernel.org/show_bug.cgi?id=221318
--- Comment #12 from manauer.uel@gmail.com ---
Created attachment 309832
--> https://bugzilla.kernel.org/attachment.cgi?id=309832&action=edit
dmesg -W with connection through Thunderbolt 2 udev-rule off only
--
You may reply to this email to add a comment.
You are receiving this mail because:
You are watching the assignee of the bug.
^ permalink raw reply
* [Bug 221318] mice behind ASMedia ASM1042A via Thunderbolt 2 never produce input, most likely due to interrupt pipe idle window during enumeration
From: bugzilla-daemon @ 2026-04-06 8:30 UTC (permalink / raw)
To: linux-usb
In-Reply-To: <bug-221318-208809@https.bugzilla.kernel.org/>
https://bugzilla.kernel.org/show_bug.cgi?id=221318
--- Comment #11 from Michał Pecio (michal.pecio@gmail.com) ---
(In reply to manauer.uel from comment #9)
> That would be bus 2, port 3 on the Intel controller, right? Checking sysfs
> says it is the Apple Internal Memory Card Reader (05ac:8406), the SD card
> slot built into the MacBook.
Right. Not sure what's happening here, but "rmmod usb-storage" would silence
it. But not a big deal, I filtered your logs with "grep -v 0000:00:14".
> I captured a new log with the rule enabled and replugged the mouse. I think
> with the udev rule active the cancellation disappears as far as I can see.
> The enumeration looks the same as before up to the point where the mouse is
> recognized and the hidraw nodes are created. After that, the ASMedia
> controller goes completely silent. No Cancel URB on ep 0x81, no split
> transaction error, nothing. Just the Intel slot 2 ep 2 stalls in the
> background as usual. The mouse works.
Yep. I tried the quirk here and it eliminates the cancellation. Without the
quirk it happens when udev briefly opens and closes the mouse before the GUI
does. The kernel can't do much about it, besides the quirk.
I failed to reproduce this bug on two ASM1042 (non-A) controllers I have. The
URB is canceled and later a new one is submitted and the mouse works.
> Some were definitely me replugging. But I cannot rule out that the device
> also disconnected on its own at some point before I pulled the cable. The
> split transaction error appeared very shortly before one of the disconnects,
> so it is possible both happened. I definitely followed your instruction
Yes, I asked to try with and without workarounds, but the log shows multiple
disconnections so I wasn't sure what's going on.
I suspect that Split Transaction Error on disconnection is seen when the mouse
works and not seen when it doesn't work. Because it looks like the next URB
submitted after cancellation is somehow ignored by the HC.
But I see nothing wrong here:
# usbhid unlinks its URB
[ 393.432235] xhci_hcd 0000:0a:00.0: Cancel URB 00000000ea33d4b2, dev 1.1, ep
0x81, starting at offset 0x1284000
# Stop Endpoint is queued (as it should) and succeeds on first try
[ 393.432243] xhci_hcd 0000:0a:00.0: // Ding dong!
[ 393.432340] xhci_hcd 0000:0a:00.0: Stopped on Transfer TRB for slot 3 ep 2
# Set TR Deq target pointer and cycle look right
[ 393.432700] xhci_hcd 0000:0a:00.0: Removing canceled TD starting at
0x1284000 (dma) in stream 0 URB 00000000ea33d4b2
[ 393.432706] xhci_hcd 0000:0a:00.0: Set TR Deq ptr 0x1284010, cycle 1
[ 393.432708] xhci_hcd 0000:0a:00.0: // Ding dong!
[ 393.432713] xhci_hcd 0000:0a:00.0: xhci_giveback_invalidated_tds: Keep
cancelled URB 00000000ea33d4b2 TD as cancel_status is 2
# and it completes successfully
[ 393.432864] xhci_hcd 0000:0a:00.0: Successful Set TR Deq Ptr cmd, deq =
@01284010
[ 393.432875] xhci_hcd 0000:0a:00.0: xhci_handle_cmd_set_deq: Giveback
cancelled URB 00000000ea33d4b2 TD
[ 393.432877] xhci_hcd 0000:0a:00.0: Giveback URB 00000000ea33d4b2, len = 0,
expected = 10, status = -115
# the doorbell likely isn't rung due to no URBs, it shouldn't matter anyway
[ 393.432881] xhci_hcd 0000:0a:00.0: xhci_handle_cmd_set_deq: All TDs cleared,
ring doorbell
> I already tried this with two different USB hub dongles placed between the
> monitor and the mouse. The behavior was identical. The problem persists
> regardless of which hub is in between, which made me think the issue is
> maybe with the ASMedia controller itself rather than the LG hub specifically.
Yes indeed, it's exactly why I thought about checking this.
> One observation that might or might not be related I already mentioned in my
> initial report is that plugging in an unrelated wireless Logitech USB dongle
> into the monitor makes the wired mouse start working after replugging.
Bizarre. Does it prevent the cancellation, or does it work despite it?
--
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
* I need your help
From: Jisun Lee @ 2026-04-06 8:07 UTC (permalink / raw)
To: linux-usb
Dear Beloved
My ex Husband Song Lee refuse to pay our divorce settlement
funds. I need your help to recover Assets from the bank for
healthcare and child support
purposes, diagnosed with (bladder cancer).
I need your advise and support
Thank You
Jisun Lee
^ permalink raw reply
* [Bug 221319] Certain operations via PCIe tunneling between an AMD USB4 host and a Thunderbolt-5 peripherals cause an instant reboot
From: bugzilla-daemon @ 2026-04-06 2:31 UTC (permalink / raw)
To: linux-usb
In-Reply-To: <bug-221319-208809@https.bugzilla.kernel.org/>
https://bugzilla.kernel.org/show_bug.cgi?id=221319
Mario Limonciello (AMD) (mario.limonciello@amd.com) changed:
What |Removed |Added
----------------------------------------------------------------------------
Component|USB |PCI
Assignee|drivers_usb@kernel-bugs.ker |drivers_pci@kernel-bugs.osd
|nel.org |l.org
--
You may reply to this email to add a comment.
You are receiving this mail because:
You are watching the assignee of the bug.
^ permalink raw reply
* [Bug 221319] Certain operations via PCIe tunneling between an AMD USB4 host and a Thunderbolt-5 peripherals cause an instant reboot
From: bugzilla-daemon @ 2026-04-06 2:31 UTC (permalink / raw)
To: linux-usb
In-Reply-To: <bug-221319-208809@https.bugzilla.kernel.org/>
https://bugzilla.kernel.org/show_bug.cgi?id=221319
--- Comment #6 from Mario Limonciello (AMD) (mario.limonciello@amd.com) ---
Here's the message that I was looking for:
> [ 1.657766] x86/amd: Previous system reset reason [0x08000800]: an
> uncorrected error caused a data fabric sync flood event
I suspect that there are some PCIe errors occurring either internal to the SoC
or (more likely) between the SoC and your new device. These are causing a
flood of problems, and then the BIOS eventually triggers an internal watchdog
that reboots the system.
Try adding this to your kernel command line and we'll see if there is anything
new from the PCI core about the issue:
> pcie_ports=native pcie_ecrc=on
--
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] usb: cdnsp: Add support for device-only configuration
From: Peter Chen (CIX) @ 2026-04-06 1:31 UTC (permalink / raw)
To: Pawel Laszczak
Cc: Roger Quadros, Greg Kroah-Hartman, Bjorn Helgaas,
linux-usb@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-pci@vger.kernel.org
In-Reply-To: <PH7PR07MB9538FCAFEBF0072EA5B5B815DD5EA@PH7PR07MB9538.namprd07.prod.outlook.com>
On 26-04-03 10:33:52, Pawel Laszczak wrote:
> >>
> >> + if (cdns->no_drd) {
> >> + cdns->version = CDNSP_CONTROLLER_V2;
> >> + cdns->dr_mode = USB_DR_MODE_PERIPHERAL;
> >
> >With "no_drd", are configurations fixed, no other options?
>
> Yes, no other option.
Is it possible for host-only configurations?
Peter
>
> Pawel
>
> >
> >> + return 0;
> >> + }
> >> +
> >> regs = devm_ioremap_resource(cdns->dev, &cdns->otg_res);
> >> if (IS_ERR(regs))
> >> return PTR_ERR(regs);
> >> diff --git a/include/linux/pci_ids.h b/include/linux/pci_ids.h index
> >> 406abf629be2..a931fb201402 100644
> >> --- a/include/linux/pci_ids.h
> >> +++ b/include/linux/pci_ids.h
> >> @@ -2424,6 +2424,7 @@
> >> #define PCI_DEVICE_ID_CDNS_USBSS 0x0100
> >> #define PCI_DEVICE_ID_CDNS_USB 0x0120
> >> #define PCI_DEVICE_ID_CDNS_USBSSP 0x0200
> >> +#define PCI_DEVICE_ID_CDNS_UDC_USBSSP 0x0400
> >>
> >> #define PCI_VENDOR_ID_ARECA 0x17d3
> >> #define PCI_DEVICE_ID_ARECA_1110 0x1110
> >>
> >> ---
> >> base-commit: 5196f2c98340297e1fdd36555285e991ceddf776
> >> change-id: 20260331-device_only-192d539430b5
> >>
> >> Best regards,
> >> --
> >> Pawel Laszczak <pawell@cadence.com>
> >>
> >>
> >
> >--
> >
> >Best regards,
> >Peter
--
Best regards,
Peter
^ permalink raw reply
* Re: [PATCH] usb: cdns3: attempt to fix Kconfig dependencies
From: Peter Chen (CIX) @ 2026-04-06 1:30 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Arnd Bergmann, Greg Kroah-Hartman, Pawel Laszczak, Roger Quadros,
linux-usb, linux-kernel
In-Reply-To: <e650e6c7-bd19-4c35-bcd2-0c53178feb8e@app.fastmail.com>
On 26-04-03 20:50:52, Arnd Bergmann wrote:
>
> > @@ -13,11 +13,13 @@ config USB_CDNS_HOST
> > bool
> > depends on USB=y || USB=USB_CDNS_SUPPORT
> >
> > -config CONFIG_USB_CDNS_PLATFORM
> > +config USB_CDNS_PLATFORM
> > tristate "Cadence USB3 generic platform support"
> > depends on USB_CDNSP || USB_CDNS3
> > depends on USB_CDNSP || !USB_CDNSP
> > depends on USB_CDNS3 || !USB_CDNS3
> > + depends on USB_CDNS3_GADGET || !USB_CDNS3_GADGET
> > + depends on USB_CDNSP_GADGET || !USB_CDNSP_GADGET
> > help
> > The platform driver support is needed on any SoC integrating
> > a variant of the Cadence USB3 or USBSSP dual-role controllers,
>
> The dependencies here are rather unwieldy, but it does look like
> this is the minimum set we need with the current code.
>
> The only other alternative I see would be to split up the
> platform driver support into separate modules for cdns3 and
> cdnsp as well, which would make the dependencies trivial but
> require reworking of the actual in a way that I haven't
> been able to figure out yet. If you are already integrating
> other changes for the next attempt, maybe you can try to
> come up with a solution for this as well.
Thanks for your suggestion, creating different platform driver
between cdns3 and cdnsp is the way we used at downstream, but
when I try to upstream cdsnp platform driver support, I find
the two platforms driver are 95% identical in content, so I
would like to keep one platform driver and one binding doc.
By the way, are there any randconfigs I could run to avoid
the similar break, of course, I will pass my local USB
randconfigs tests?
--
Best regards,
Peter
^ permalink raw reply
* [Bug 221319] Certain operations via PCIe tunneling between an AMD USB4 host and a Thunderbolt-5 peripherals cause an instant reboot
From: bugzilla-daemon @ 2026-04-06 0:52 UTC (permalink / raw)
To: linux-usb
In-Reply-To: <bug-221319-208809@https.bugzilla.kernel.org/>
https://bugzilla.kernel.org/show_bug.cgi?id=221319
--- Comment #5 from Morgwai Kotarbinski (foss@morgwai.pl) ---
@Mario, thanks for your reply! :)
I've had a look at the logs on the next boot, but cannot find anything
relevant. I've attached the dmesg output from the boot after and the systemd
journal from a reboot and the boot after: perhaps you will be able to find this
info there.
Otherwise please advise me if I need to add some kernel boot params or
configure some other log gathering or apply some patches to my kernel to
collect some more useful data: to be honest I don't know how to proceed further
from here on my own.
Thanks :)
--
You may reply to this email to add a comment.
You are receiving this mail because:
You are watching the assignee of the bug.
^ permalink raw reply
* [Bug 221319] Certain operations via PCIe tunneling between an AMD USB4 host and a Thunderbolt-5 peripherals cause an instant reboot
From: bugzilla-daemon @ 2026-04-06 0:41 UTC (permalink / raw)
To: linux-usb
In-Reply-To: <bug-221319-208809@https.bugzilla.kernel.org/>
https://bugzilla.kernel.org/show_bug.cgi?id=221319
--- Comment #4 from Morgwai Kotarbinski (foss@morgwai.pl) ---
Created attachment 309829
--> https://bugzilla.kernel.org/attachment.cgi?id=309829&action=edit
systemd journal from a deg2-induced reboot and the boot after
--
You may reply to this email to add a comment.
You are receiving this mail because:
You are watching the assignee of the bug.
^ permalink raw reply
* [Bug 221319] Certain operations via PCIe tunneling between an AMD USB4 host and a Thunderbolt-5 peripherals cause an instant reboot
From: bugzilla-daemon @ 2026-04-06 0:40 UTC (permalink / raw)
To: linux-usb
In-Reply-To: <bug-221319-208809@https.bugzilla.kernel.org/>
https://bugzilla.kernel.org/show_bug.cgi?id=221319
--- Comment #3 from Morgwai Kotarbinski (foss@morgwai.pl) ---
Created attachment 309828
--> https://bugzilla.kernel.org/attachment.cgi?id=309828&action=edit
dmesg log from the boot after a deg2-induced reboot
--
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
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