* [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-07 13:18 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 #20 from manauer.uel@gmail.com ---
> The "spurious event" noise is likely from SuperSpeed device 4-1.1.2 whose
> Bulk IN URBs may trigger it even on properly working hardware.
Good to know. I looked up 4-1.1.2, it turned out to be the Ethernet adapter
from the USB dongle.
> I see nothing obviously wrong here, it looks like some weird HW problem.
The sequence looks correct on paper, the cancellation goes through cleanly and
the endpoint is left in running state with the dequeue pointer advanced past
the old URB. Yet no new transfer ever arrives.
> BTW, I see that the endpoint of interest has 1ms interval too, longer
> interval is on the second endpoint of this mouse.
Yes, that matches the lsusb output.
> If you would like to play with intervals, see drivers/usb/host/xhci-mem.c
> function xhci_parse_frame_interval(). Replace ep->desc.bInterval with any
> number like 1 or 10, units are milliseconds.
I built and tested two patched kernels.
Forcing 10ms: the mouse works without any workaround at all.
Forcing 1ms: the mouse does not work. The udev workaround still fixes it.
So the interval does matter. With 10ms the problem does not occur in the first
place, with 1ms it behaves the same as on the stock kernel.
One thing that does not fit this pattern: the Logitech Lightspeed Receiver
(046d:c539) has 3 interfaces all polling at 1ms, yet it works on its own
without any workaround. It also makes wired mice work alongside it on the stock
kernel.
I looked into this a bit. The receiver is not handled by usbhid but by the
logitech-djreceiver driver (hid-logitech-dj). That driver has its own
hid_ll_driver with open and close callbacks that are essentially empty. When
udev opens and closes the hidraw device, nothing happens at the USB level, so
no URB is cancelled. This might be why the ASM1042A never gets into the broken
state.
--
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: typec: ucsi: skip connector validation before init
From: Heikki Krogerus @ 2026-04-07 12:26 UTC (permalink / raw)
To: Nathan Rebello; +Cc: gregkh, linux-usb, linux-kernel, tiwai, stable
In-Reply-To: <20260407063958.863-1-nathan.c.rebello@gmail.com>
On Tue, Apr 07, 2026 at 02:39:58AM -0400, Nathan Rebello wrote:
> Notifications can arrive before ucsi_init() has populated
> ucsi->cap.num_connectors via GET_CAPABILITY. At that point
> num_connectors is still 0, causing all valid connector numbers to be
> incorrectly rejected as bogus.
>
> Skip the bounds check when num_connectors is 0 (not yet initialized).
> Pre-init notifications are already handled safely by the early-event
> guard in ucsi_connector_change().
>
> Reported-by: Takashi Iwai <tiwai@suse.de>
> Fixes: d2d8c17ac01a ("usb: typec: ucsi: validate connector number in ucsi_notify_common()")
> Cc: stable@vger.kernel.org
> Signed-off-by: Nathan Rebello <nathan.c.rebello@gmail.com>
Acked-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
> ---
> drivers/usb/typec/ucsi/ucsi.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/usb/typec/ucsi/ucsi.c b/drivers/usb/typec/ucsi/ucsi.c
> index b77910152399..7df3a7b94a40 100644
> --- a/drivers/usb/typec/ucsi/ucsi.c
> +++ b/drivers/usb/typec/ucsi/ucsi.c
> @@ -43,7 +43,8 @@ void ucsi_notify_common(struct ucsi *ucsi, u32 cci)
> return;
>
> if (UCSI_CCI_CONNECTOR(cci)) {
> - if (UCSI_CCI_CONNECTOR(cci) <= ucsi->cap.num_connectors)
> + if (!ucsi->cap.num_connectors ||
> + UCSI_CCI_CONNECTOR(cci) <= ucsi->cap.num_connectors)
> ucsi_connector_change(ucsi, UCSI_CCI_CONNECTOR(cci));
> else
> dev_err(ucsi->dev, "bogus connector number in CCI: %lu\n",
> --
> 2.43.0.windows.1
--
heikki
^ permalink raw reply
* Re: [PATCH v10 6/6] usb: typec: tcpm/tcpci_maxim: deprecate WAR for setting charger mode
From: Heikki Krogerus @ 2026-04-07 12:24 UTC (permalink / raw)
To: Amit Sunil Dhamne
Cc: André Draszik, Lee Jones, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Greg Kroah-Hartman, Jagan Sridharan, Mark Brown,
Matti Vaittinen, Andrew Morton, Sebastian Reichel, Peter Griffin,
Tudor Ambarus, Alim Akhtar, linux-kernel, devicetree, linux-usb,
linux-pm, linux-arm-kernel, linux-samsung-soc, RD Babiera,
Kyle Tso
In-Reply-To: <017b8552-87e2-4409-ae34-9a3ab7365a68@google.com>
Hi Amit,
On Thu, Apr 02, 2026 at 11:47:30AM -0700, Amit Sunil Dhamne wrote:
> Hi Heikki,
>
> On 4/2/26 7:33 AM, Heikki Krogerus wrote:
> > Hi Amit,
> >
> > > +static int get_vbus_regulator_handle(struct max_tcpci_chip *chip)
> > > +{
> > > + if (IS_ERR_OR_NULL(chip->vbus_reg)) {
> > > + chip->vbus_reg = devm_regulator_get_exclusive(chip->dev,
> > > + "vbus");
> > Sorry to go back to this, but why can't you just get the regulator in
> > max_tcpci_probe()?
>
> Thanks for calling this out. This was an intentional design decision to
> break a circular dependency.
>
> The charger driver is guaranteed to probe after the TCPC driver due to a
> power supply dependency (the TCPC is a supplier of power for the Battery
> Charger). However, the charger driver is also the regulator provider for
> VBUS out (when Type-C goes into source mode).
>
> Because of this, the regulator handle will not be available during the TCPC
> driver's probe. If we tried to fetch it in max_tcpci_probe() and returned
> -EPROBE_DEFER, it would create a probe deadlock, as the charger would then
> never probe. Therefore, I made the decision to get the regulator handle
> lazily and on-demand.
Got it. Thanks for the explanation!
--
heikki
^ permalink raw reply
* Re: [PATCH v1 2/2] usb: typec: cros_ec_ucsi: Load driver from OF and ACPI definitions
From: Heikki Krogerus @ 2026-04-07 12:22 UTC (permalink / raw)
To: Jameson Thies
Cc: robh, krzk+dt, conor+dt, abhishekpandit, bleung, akuchynski,
gregkh, devicetree, chrome-platform, linux-usb, linux-kernel
In-Reply-To: <20260403223357.1896403-3-jthies@google.com>
On Fri, Apr 03, 2026 at 10:33:27PM +0000, Jameson Thies wrote:
> Add support for cros_ec_ucsi to load based on "google,cros-ec-ucsi"
> compatible devices and "GOOG0021" ACPI nodes.
>
> Signed-off-by: Jameson Thies <jthies@google.com>
Reviewed-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
> ---
> drivers/usb/typec/ucsi/cros_ec_ucsi.c | 26 ++++++++++++++++++++++++--
> 1 file changed, 24 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/usb/typec/ucsi/cros_ec_ucsi.c b/drivers/usb/typec/ucsi/cros_ec_ucsi.c
> index 6bca2dce211c..251aa7251ce6 100644
> --- a/drivers/usb/typec/ucsi/cros_ec_ucsi.c
> +++ b/drivers/usb/typec/ucsi/cros_ec_ucsi.c
> @@ -5,11 +5,13 @@
> * Copyright 2024 Google LLC.
> */
>
> +#include <linux/acpi.h>
> #include <linux/container_of.h>
> #include <linux/dev_printk.h>
> #include <linux/jiffies.h>
> #include <linux/mod_devicetable.h>
> #include <linux/module.h>
> +#include <linux/of.h>
> #include <linux/platform_data/cros_ec_commands.h>
> #include <linux/platform_data/cros_usbpd_notify.h>
> #include <linux/platform_data/cros_ec_proto.h>
> @@ -257,7 +259,6 @@ static void cros_ucsi_destroy(struct cros_ucsi_data *udata)
> static int cros_ucsi_probe(struct platform_device *pdev)
> {
> struct device *dev = &pdev->dev;
> - struct cros_ec_dev *ec_data = dev_get_drvdata(dev->parent);
> struct cros_ucsi_data *udata;
> int ret;
>
> @@ -265,9 +266,16 @@ static int cros_ucsi_probe(struct platform_device *pdev)
> if (!udata)
> return -ENOMEM;
>
> + /* ACPI and OF FW nodes for cros_ec_ucsi are children of the ChromeOS EC. If the
> + * cros_ec_ucsi device has an ACPI or OF FW node, its parent is the ChromeOS EC device.
> + * Platforms without a FW node for cros_ec_ucsi may add it as a subdevice of cros_ec_dev.
> + */
> udata->dev = dev;
> + if (is_acpi_device_node(dev->fwnode) || is_of_node(dev->fwnode))
> + udata->ec = dev_get_drvdata(dev->parent);
> + else
> + udata->ec = ((struct cros_ec_dev *)dev_get_drvdata(dev->parent))->ec_dev;
>
> - udata->ec = ec_data->ec_dev;
> if (!udata->ec)
> return dev_err_probe(dev, -ENODEV, "couldn't find parent EC device\n");
>
> @@ -348,10 +356,24 @@ static const struct platform_device_id cros_ucsi_id[] = {
> };
> MODULE_DEVICE_TABLE(platform, cros_ucsi_id);
>
> +static const struct acpi_device_id cros_ec_ucsi_acpi_device_ids[] = {
> + { "GOOG0021", 0 },
> + { }
> +};
> +MODULE_DEVICE_TABLE(acpi, cros_ec_ucsi_acpi_device_ids);
> +
> +static const struct of_device_id cros_ucsi_of_match[] = {
> + { .compatible = "google,cros-ec-ucsi", },
> + {}
> +};
> +MODULE_DEVICE_TABLE(of, cros_ucsi_of_match);
> +
> static struct platform_driver cros_ucsi_driver = {
> .driver = {
> .name = KBUILD_MODNAME,
> .pm = &cros_ucsi_pm_ops,
> + .acpi_match_table = cros_ec_ucsi_acpi_device_ids,
> + .of_match_table = cros_ucsi_of_match,
> },
> .id_table = cros_ucsi_id,
> .probe = cros_ucsi_probe,
> --
> 2.53.0.1213.gd9a14994de-goog
--
heikki
^ permalink raw reply
* Re: [PATCH v1] usb: typec: ucsi: Set usb mode on partner change
From: Heikki Krogerus @ 2026-04-07 12:21 UTC (permalink / raw)
To: Jameson Thies
Cc: linux-usb, linux-kernel, dmitry.baryshkov, bleung, gregkh,
akuchynski, abhishekpandit
In-Reply-To: <20260402182438.867396-1-jthies@google.com>
Thu, Apr 02, 2026 at 06:24:38PM +0000, Jameson Thies kirjoitti:
> Currently the partner usb_mode is only set in ucsi_register_partner().
> If the partner enters USB4 operation after it is registered, this is not
> reported to the typec class. The UCSI spec states that the Connector
> Partner Changed bit can represent a Connector Partner Flags change. When
> handling a UCSI partner change, check the partner flags for USB4
> operation.
>
> Signed-off-by: Jameson Thies <jthies@google.com>
Reviewed-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
> ---
> drivers/usb/typec/ucsi/ucsi.c | 6 ++++++
> 1 file changed, 6 insertions(+)
>
> diff --git a/drivers/usb/typec/ucsi/ucsi.c b/drivers/usb/typec/ucsi/ucsi.c
> index fe1fb8a68a1d..e6fd2e2eba94 100644
> --- a/drivers/usb/typec/ucsi/ucsi.c
> +++ b/drivers/usb/typec/ucsi/ucsi.c
> @@ -1182,6 +1182,12 @@ static void ucsi_partner_change(struct ucsi_connector *con)
> if (UCSI_CONSTAT(con, PARTNER_FLAG_USB))
> typec_set_mode(con->port, TYPEC_STATE_USB);
> }
> +
> + if (((con->ucsi->version >= UCSI_VERSION_3_0 &&
> + UCSI_CONSTAT(con, PARTNER_FLAG_USB4_GEN4)) ||
> + (con->ucsi->version >= UCSI_VERSION_2_0 &&
> + UCSI_CONSTAT(con, PARTNER_FLAG_USB4_GEN3))) && con->partner)
> + typec_partner_set_usb_mode(con->partner, USB_MODE_USB4);
> }
>
> if ((!UCSI_CONSTAT(con, PARTNER_FLAG_USB)) &&
--
heikki
^ permalink raw reply
* Re: [PATCH] usb: typec: altmode: Fix altmode to handle multiple parners
From: Heikki Krogerus @ 2026-04-07 12:17 UTC (permalink / raw)
To: François Scala; +Cc: linux-usb
In-Reply-To: <8cef8b26-71ce-4fdf-a514-111d9760634c@scala.name>
Hi François,
Thank you for the info.
On Thu, Apr 02, 2026 at 08:10:09PM +0200, François Scala wrote:
> Hi,
>
> On 02/04/2026 15.26, Heikki Krogerus wrote:
> > No. You can not have more than a single partner per mode. Let's figure
> > out the root issue. Please check the svids of the partner altmodes:
> >
> > grep . /sys/class/typec/port0-partner/port0-partner.*/svid
>
> /sys/class/typec/port2-partner/port2-partner.0/svid:8087
> /sys/class/typec/port2-partner/port2-partner.1/svid:8087
Okay, the other svid should almost certainly be ff01 (the DisplayPort
Alternate Mode), most likely the second one (port2-partner.1). 8087 is
the Thunderbolt Alternate Mode, and it should now be always companied
by the DisplayPort Alternate Mode.
> kworker/5:2-321 [005] ..... 465.001617: ucsi_connector_change:
> port3 status: change=4000, opmode=4, connected=1, sourcing=1,
> partner_flags=1, partner_type=2, request_data_obj=00000000, BC status=1
> kworker/5:2-321 [005] ..... 465.111779: ucsi_connector_change:
> port3 status: change=0060, opmode=3, connected=1, sourcing=1,
> partner_flags=1, partner_type=2, request_data_obj=13800000, BC status=1
> kworker/8:1-174 [008] ..... 465.429999: ucsi_connector_change:
> port3 status: change=1000, opmode=5, connected=1, sourcing=0,
> partner_flags=1, partner_type=2, request_data_obj=13800000, BC status=1
> kworker/8:1-174 [008] ..... 465.532708: ucsi_connector_change:
> port3 status: change=0060, opmode=3, connected=1, sourcing=0,
> partner_flags=1, partner_type=2, request_data_obj=42c4b12c, BC status=1
> kworker/10:1-178 [010] ..... 465.883679: ucsi_connector_change:
> port3 status: change=0060, opmode=3, connected=1, sourcing=0,
> partner_flags=1, partner_type=2, request_data_obj=42c7a9ea, BC status=1
> kworker/3:0-13120 [003] ..... 466.330330: ucsi_connector_change:
> port3 status: change=0060, opmode=3, connected=1, sourcing=0,
> partner_flags=1, partner_type=2, request_data_obj=82c7d1f4, BC status=1
> kworker/u64:2-356 [005] ..... 466.890372: ucsi_register_altmode:
> partner alt mode: svid 8087, mode 1 vdo 8087a843
Here the vdo seems to be corrupted in the response to the
GET_ALTERNATE_MODES command.
As you can see, the first 16-bits in the vdo is clearly the TBT svid
again even though the vdo should contain the actual Vendor Defined Object
for the TBT alt mode.
> kworker/u64:2-356 [005] ..... 467.005141: ucsi_register_altmode:
> partner alt mode: svid 8087, mode 2 vdo 1
And here the firmware is returning the TBT SVID again for the second
time, now with vdo that looks almost valid to me. This should not
happen.
The responses to the GET_ALTERNATE_MODES look similar to what we see
on some of the Dell laptops. The response seems almost as if it's
customised some how. It's almost as if the first run of the command
will return some kind of a list of the SVIDs, and the standard
responses start only after the second run of the command.
> > For acpidump you need the acpica-tools installed:
> >
> > acpidump -o my_acpi.dump
>
> The file is quite large, how can I share it ? Or do you need a specific part
> ?
>
> -rw-r--r-- 1 fs fs 4.7M Apr 2 19:05 acpi-port3-20260402.dump
It does not look that big. Compress and send to me (drop the list if
you prefer)?
I still have no idea which system are you running? Can you send the
dmesg output from freshly booted machine?
thanks,
--
heikki
^ permalink raw reply
* Re: [PATCH v5 8/9] driver core: Replace dev->of_node_reused with dev_of_node_reused()
From: Johan Hovold @ 2026-04-07 9:07 UTC (permalink / raw)
To: Douglas Anderson
Cc: Greg Kroah-Hartman, Rafael J . Wysocki, Danilo Krummrich,
Alan Stern, Alexey Kardashevskiy, Eric Dumazet, Leon Romanovsky,
Christoph Hellwig, Robin Murphy, maz, Alexander Lobakin,
Saravana Kannan, 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: <20260406162231.v5.8.I806b8636cd3724f6cd1f5e199318ab8694472d90@changeid>
On Mon, Apr 06, 2026 at 04:23:01PM -0700, Doug Anderson wrote:
> 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.
This flag is only set before registering a device with driver core so
there is no issue using the existing bitfield here (with the caveat that
PCI pwrctrl may have gotten that wrong). I haven't checked the other
flags, but I assume most of them work the same way.
But apart from the commit message being misleading, switching to using
atomic ops and accessors for consistency is fine.
> 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).
> 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)
These two uses are broken currently though and should be using
device_set_of_node_from_dev() so that an extra reference is taken to
balance the one dropped by the platform bus code.
I'll send two fixes to Mark, any merge conflict should be trivial to
fixup.
Reviewed-by: Johan Hovold <johan@kernel.org>
Johan
^ permalink raw reply
* [PATCH] usb: gadget: f_ncm: validate minimum block_len in ncm_unwrap_ntb()
From: Greg Kroah-Hartman @ 2026-04-07 9:02 UTC (permalink / raw)
To: linux-usb; +Cc: linux-kernel, Greg Kroah-Hartman, stable
The block_len read from the host-supplied NTB header is checked against
ntb_max but has no lower bound. When block_len is smaller than
opts->ndp_size, the bounds check of:
ndp_index > (block_len - opts->ndp_size)
will underflow producing a huge unsigned value that ndp_index can never
exceed, defeating the check entirely.
The same underflow occurs in the datagram index checks against block_len
- opts->dpe_size. With those checks neutered, a malicious USB host can
choose ndp_index and datagram offsets that point past the actual
transfer, and the skb_put_data() copies adjacent kernel memory into the
network skb.
Fix this by rejecting block lengths that cannot hold at least the NTB
header plus one NDP. This will make block_len - opts->ndp_size and
block_len - opts->dpe_size both well-defined.
Commit 8d2b1a1ec9f5 ("CDC-NCM: avoid overflow in sanity checking") fixed
a related class of issues on the host side of NCM.
Fixes: 2b74b0a04d3e ("USB: gadget: f_ncm: add bounds checks to ncm_unwrap_ntb()")
Cc: stable <stable@kernel.org>
Assisted-by: gregkh_clanker_t1000
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/usb/gadget/function/f_ncm.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/usb/gadget/function/f_ncm.c b/drivers/usb/gadget/function/f_ncm.c
index a6fa5ed3d6cb..c5bf8a448d64 100644
--- a/drivers/usb/gadget/function/f_ncm.c
+++ b/drivers/usb/gadget/function/f_ncm.c
@@ -1210,8 +1210,8 @@ static int ncm_unwrap_ntb(struct gether *port,
block_len = get_ncm(&tmp, opts->block_length);
/* (d)wBlockLength */
- if (block_len > ntb_max) {
- INFO(port->func.config->cdev, "OUT size exceeded\n");
+ if ((block_len < opts->nth_size + opts->ndp_size) || (block_len > ntb_max)) {
+ INFO(port->func.config->cdev, "Bad block length: %#X\n", block_len);
goto err;
}
--
2.53.0
^ permalink raw reply related
* Re: [PATCH v5 0/9] driver core: Fix some race conditions
From: Marek Szyprowski @ 2026-04-07 8:57 UTC (permalink / raw)
To: Douglas Anderson, Greg Kroah-Hartman, Rafael J . Wysocki,
Danilo Krummrich, Alan Stern
Cc: Leon Romanovsky, Christoph Hellwig, Robin Murphy, driver-core,
iommu, linux-acpi, linux-arm-kernel, linux-kernel, linux-mm,
linux-pci, linux-usb, linux
In-Reply-To: <20260406232444.3117516-1-dianders@chromium.org>
On 07.04.2026 01:22, Douglas Anderson wrote:
> 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.
The dma-mapping related bits are probably not race prone, but if you plan
to refactor that part I won't object.
Acked-by: Marek Szyprowski
> 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(-)
>
Best regards
--
Marek Szyprowski, PhD
Samsung R&D Institute Poland
^ permalink raw reply
* [PATCH] usb: gadget: f_phonet: fix skb frags[] overflow in pn_rx_complete()
From: Greg Kroah-Hartman @ 2026-04-07 8:55 UTC (permalink / raw)
To: linux-usb; +Cc: linux-kernel, Greg Kroah-Hartman, stable
A broken/bored/mean USB host can overflow the skb_shared_info->frags[]
array on a Linux gadget exposing a Phonet function by sending an
unbounded sequence of full-page OUT transfers.
pn_rx_complete() finalizes the skb only when req->actual < req->length,
where req->length is set to PAGE_SIZE by the gadget. If the host always
sends exactly PAGE_SIZE bytes per transfer, fp->rx.skb will never be
reset and each completion will add another fragment via
skb_add_rx_frag(). Once nr_frags exceeds MAX_SKB_FRAGS (default 17),
subsequent frag stores overwrite memory adjacent to the shinfo on the
heap.
Drop the skb and account a length error when the frag limit is reached,
matching the fix applied in t7xx by commit f0813bcd2d9d ("net: wwan:
t7xx: fix potential skb->frags overflow in RX path").
Fixes: 9732d5232335 ("Phonet: USB CDC Phonet function for gadget framework")
Cc: stable <stable@kernel.org>
Assisted-by: gregkh_clanker_t1000
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/usb/gadget/function/f_phonet.c | 9 +++++++++
1 file changed, 9 insertions(+)
diff --git a/drivers/usb/gadget/function/f_phonet.c b/drivers/usb/gadget/function/f_phonet.c
index 2c007790ead2..b1ee9a7c2e94 100644
--- a/drivers/usb/gadget/function/f_phonet.c
+++ b/drivers/usb/gadget/function/f_phonet.c
@@ -333,6 +333,15 @@ static void pn_rx_complete(struct usb_ep *ep, struct usb_request *req)
if (unlikely(!skb))
break;
+ if (unlikely(skb_shinfo(skb)->nr_frags >= MAX_SKB_FRAGS)) {
+ /* Frame count from host exceeds frags[] capacity */
+ dev_kfree_skb_any(skb);
+ if (fp->rx.skb == skb)
+ fp->rx.skb = NULL;
+ dev->stats.rx_length_errors++;
+ break;
+ }
+
if (skb->len == 0) { /* First fragment */
skb->protocol = htons(ETH_P_PHONET);
skb_reset_mac_header(skb);
--
2.53.0
^ permalink raw reply related
* Re: [PATCH] usb: gadget: f_hid: Add missing error code
From: Michael Zimmermann @ 2026-04-07 8:14 UTC (permalink / raw)
To: Ethan Tidmore
Cc: gregkh, peter, mhklinux, linuxhid, danisjiang, kees,
hoff.benjamin.k, linux-usb, linux-kernel
In-Reply-To: <20260402180008.64233-1-ethantidmore06@gmail.com>
On Thu, Apr 2, 2026 at 8:00 PM Ethan Tidmore <ethantidmore06@gmail.com> wrote:
>
> Currently in cdev_alloc() error path no error code is assigned.
>
> Assign error code '-ENOMEM'.
>
> Detected by Smatch:
> drivers/usb/gadget/function/f_hid.c:1291 hidg_bind()
> warn: missing error code 'status'
>
> Fixes: 81ebd43cc0d6d ("usb: gadget: f_hid: don't call cdev_init while cdev in use")
> Signed-off-by: Ethan Tidmore <ethantidmore06@gmail.com>
> ---
> drivers/usb/gadget/function/f_hid.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/usb/gadget/function/f_hid.c b/drivers/usb/gadget/function/f_hid.c
> index e0c3f39ee95e..c5a12a6760ea 100644
> --- a/drivers/usb/gadget/function/f_hid.c
> +++ b/drivers/usb/gadget/function/f_hid.c
> @@ -1278,8 +1278,10 @@ static int hidg_bind(struct usb_configuration *c, struct usb_function *f)
>
> /* create char device */
> hidg->cdev = cdev_alloc();
> - if (!hidg->cdev)
> + if (!hidg->cdev) {
> + status = -ENOMEM;
> goto fail_free_all;
> + }
> hidg->cdev->ops = &f_hidg_fops;
>
> status = cdev_device_add(hidg->cdev, &hidg->dev);
> --
> 2.53.0
>
Reviewed-by: Michael Zimmermann <sigmaepsilon92@gmail.com>
^ permalink raw reply
* Re: [PATCH v5 8/9] driver core: Replace dev->of_node_reused with dev_of_node_reused()
From: Manivannan Sadhasivam @ 2026-04-07 7:27 UTC (permalink / raw)
To: Douglas Anderson
Cc: Greg Kroah-Hartman, Rafael J . Wysocki, Danilo Krummrich,
Alan Stern, Alexey Kardashevskiy, Johan Hovold, Eric Dumazet,
Leon Romanovsky, Christoph Hellwig, Robin Murphy, maz,
Alexander Lobakin, Saravana Kannan, 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, netdev, pabeni, robh
In-Reply-To: <20260406162231.v5.8.I806b8636cd3724f6cd1f5e199318ab8694472d90@changeid>
On Mon, Apr 06, 2026 at 04:23:01PM -0700, Douglas Anderson wrote:
> 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>
Acked-by: Manivannan Sadhasivam <mani@kernel.org> # PCI_PWRCTRL
- Mani
> ---
> 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
* Re: [PATCH v3] USB: serial: option: add Telit Cinterion FN990A MBIM composition
From: Johan Hovold @ 2026-04-07 7:15 UTC (permalink / raw)
To: Fabio Porcedda; +Cc: Greg Kroah-Hartman, linux-usb, Daniele Palmas, stable
In-Reply-To: <20260402095727.108281-1-fabio.porcedda@gmail.com>
On Thu, Apr 02, 2026 at 11:57:27AM +0200, Fabio Porcedda wrote:
> Add the following Telit Cinterion FN990A MBIM composition:
>
> 0x1074: MBIM + tty (AT/NMEA) + tty (AT) + tty (AT) + tty (diag) +
> DPL (Data Packet Logging) + adb
> Cc: stable@vger.kernel.org
> Signed-off-by: Fabio Porcedda <fabio.porcedda@gmail.com>
> ---
> v3:
> - Added the full output of usb-devices
> - Link to v2: https://lore.kernel.org/linux-usb/20260402083722.100973-1-fabio.porcedda@gmail.com
>
> v2:
> - Added "Cc: stable@vger.kernel.org"
> - Link to v1: https://lore.kernel.org/linux-usb/20260402082747.98441-1-fabio.porcedda@gmail.com
Now applied, thanks.
Johan
^ 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-07 7:13 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 #19 from Michał Pecio (michal.pecio@gmail.com) ---
The "spurious event" noise is likely from SuperSpeed device 4-1.1.2 whose Bulk
IN URBs may trigger it even on properly working hardware. The driver isn't very
good at telling apart certain valid and invalid events, it just logs them all.
Mouse interrupt endpoint has an URB at 1267010, cycle bit 1 as expected.
0 0x0000000001267000: Buffer 0000000000000000 length 0 TD size 0 intr 0 type
'No-Op' flags b:i:i:c:s:i:e:C
0 0x0000000001267010: Buffer 000000000125e700 length 10 TD size 0 intr 0 type
'Normal' flags b:i:I:c:s:I:e:C
Cancellation commands, Set TR Dequeue to 1267010 with cycle 1.
0 0x0000000001201950: Stop Ring Command: slot 7 sp 0 ep 3 flags C
0 0x0000000001201960: Set TR Dequeue Pointer Command: deq 0000000001267011
stream 0 slot 7 ep 3 flags C
Their completion events have been overwritten by SuperSpeed device activity,
but no sign of problems was seen in logs.
Endpoint is running so the doorbell has been rung after 1267010 submission.
0x000000000125d060: State running mult 1 max P. Streams 0 interval 1000 us max
ESIT payload 10 CErr 3 Type Int IN burst 0 maxp 10 deq 0000000001267011 avg trb
len 10, virt_state:0x0
I see nothing obviously wrong here, it looks like some weird HW problem.
BTW, I see that the endpoint of interest has 1ms interval too, longer interval
is on the second endpoint of this mouse. IDK if it matters anyway.
If you would like to play with intervals, see drivers/usb/host/xhci-mem.c
function xhci_parse_frame_interval(). Replace ep->desc.bInterval with any
number like 1 or 10, units are milliseconds. Leave *8 unchanged.
--
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: [PATCHv2] thunderbolt: tunnel: simplify allocation
From: Mika Westerberg @ 2026-04-07 7:02 UTC (permalink / raw)
To: Rosen Penev
Cc: linux-usb, Andreas Noever, Mika Westerberg, Yehezkel Bernat,
Kees Cook, Gustavo A. R. Silva, open list,
open list:KERNEL HARDENING (not covered by other areas):Keyword:b__counted_by(_le|_be)?b
In-Reply-To: <20260401214726.3911-1-rosenp@gmail.com>
On Wed, Apr 01, 2026 at 02:47:26PM -0700, Rosen Penev wrote:
> Use a flexible array member and kzalloc_flex to combine allocations.
>
> Add __counted_by for extra runtime analysis. Move counting variable
> assignment after allocation. kzalloc_flex with GCC >= 15 does this
> automatically.
>
> Signed-off-by: Rosen Penev <rosenp@gmail.com>
Applied to thunderbolt.git/next, thanks!
^ permalink raw reply
* Re: [PATCH] usb: typec: ucsi: skip connector validation before init
From: Takashi Iwai @ 2026-04-07 6:52 UTC (permalink / raw)
To: Nathan Rebello
Cc: gregkh, heikki.krogerus, linux-usb, linux-kernel, tiwai, stable
In-Reply-To: <20260407063958.863-1-nathan.c.rebello@gmail.com>
On Tue, 07 Apr 2026 08:39:58 +0200,
Nathan Rebello wrote:
>
> Notifications can arrive before ucsi_init() has populated
> ucsi->cap.num_connectors via GET_CAPABILITY. At that point
> num_connectors is still 0, causing all valid connector numbers to be
> incorrectly rejected as bogus.
>
> Skip the bounds check when num_connectors is 0 (not yet initialized).
> Pre-init notifications are already handled safely by the early-event
> guard in ucsi_connector_change().
>
> Reported-by: Takashi Iwai <tiwai@suse.de>
> Fixes: d2d8c17ac01a ("usb: typec: ucsi: validate connector number in ucsi_notify_common()")
> Cc: stable@vger.kernel.org
> Signed-off-by: Nathan Rebello <nathan.c.rebello@gmail.com>
> ---
> drivers/usb/typec/ucsi/ucsi.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/usb/typec/ucsi/ucsi.c b/drivers/usb/typec/ucsi/ucsi.c
> index b77910152399..7df3a7b94a40 100644
> --- a/drivers/usb/typec/ucsi/ucsi.c
> +++ b/drivers/usb/typec/ucsi/ucsi.c
> @@ -43,7 +43,8 @@ void ucsi_notify_common(struct ucsi *ucsi, u32 cci)
> return;
>
> if (UCSI_CCI_CONNECTOR(cci)) {
> - if (UCSI_CCI_CONNECTOR(cci) <= ucsi->cap.num_connectors)
> + if (!ucsi->cap.num_connectors ||
> + UCSI_CCI_CONNECTOR(cci) <= ucsi->cap.num_connectors)
> ucsi_connector_change(ucsi, UCSI_CCI_CONNECTOR(cci));
> else
> dev_err(ucsi->dev, "bogus connector number in CCI: %lu\n",
Confirmed that it fixes my case.
Tested-by: Takashi Iwai <tiwai@suse.de>
Thanks!
Takashi
^ permalink raw reply
* [PATCH] usb: typec: ucsi: skip connector validation before init
From: Nathan Rebello @ 2026-04-07 6:39 UTC (permalink / raw)
To: gregkh, heikki.krogerus
Cc: linux-usb, linux-kernel, tiwai, stable, Nathan Rebello
Notifications can arrive before ucsi_init() has populated
ucsi->cap.num_connectors via GET_CAPABILITY. At that point
num_connectors is still 0, causing all valid connector numbers to be
incorrectly rejected as bogus.
Skip the bounds check when num_connectors is 0 (not yet initialized).
Pre-init notifications are already handled safely by the early-event
guard in ucsi_connector_change().
Reported-by: Takashi Iwai <tiwai@suse.de>
Fixes: d2d8c17ac01a ("usb: typec: ucsi: validate connector number in ucsi_notify_common()")
Cc: stable@vger.kernel.org
Signed-off-by: Nathan Rebello <nathan.c.rebello@gmail.com>
---
drivers/usb/typec/ucsi/ucsi.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/usb/typec/ucsi/ucsi.c b/drivers/usb/typec/ucsi/ucsi.c
index b77910152399..7df3a7b94a40 100644
--- a/drivers/usb/typec/ucsi/ucsi.c
+++ b/drivers/usb/typec/ucsi/ucsi.c
@@ -43,7 +43,8 @@ void ucsi_notify_common(struct ucsi *ucsi, u32 cci)
return;
if (UCSI_CCI_CONNECTOR(cci)) {
- if (UCSI_CCI_CONNECTOR(cci) <= ucsi->cap.num_connectors)
+ if (!ucsi->cap.num_connectors ||
+ UCSI_CCI_CONNECTOR(cci) <= ucsi->cap.num_connectors)
ucsi_connector_change(ucsi, UCSI_CCI_CONNECTOR(cci));
else
dev_err(ucsi->dev, "bogus connector number in CCI: %lu\n",
--
2.43.0.windows.1
^ permalink raw reply related
* Re: Spurious errors "ucsi_acpi USBC000:00: bogus connector number in CCI: 1" on 7.0-rc7
From: Nathan Rebello @ 2026-04-07 6:21 UTC (permalink / raw)
To: gregkh, tiwai; +Cc: linux-usb, linux-kernel, heikki.krogerus, Nathan Rebello
In-Reply-To: <2026040734-headfirst-tingly-e6ea@gregkh>
On Tue, Apr 07, 2026 at 07:58:00AM +0200, Greg Kroah-Hartman wrote:
> On Tue, Apr 07, 2026 at 07:38:50AM +0200, Takashi Iwai wrote:
> > Is this a firmware bug, or some missing piece in the code?
> > Judging from the message, it means that ucsi->cap.num_connectors is 0,
> > I suppose.
>
> Ugh, what's the odds this is an off-by-one error in the firmware? :)
>
> Nathan and Heikki, any ideas?
This isn't an off-by-one or firmware bug. Takashi is right that
num_connectors is 0. The validation checks against
ucsi->cap.num_connectors, but notifications can arrive before
ucsi_init() has populated that field via GET_CAPABILITY.
Pre-init notifications are already handled safely by the early-event
guard in ucsi_connector_change(), so the fix is to skip validation
when num_connectors hasn't been initialized yet.
Sending a fix shortly.
Thanks,
Nathan
^ permalink raw reply
* [PATCH v1] dt-bindings: usb: Fix EIC7700 USB reset's issue
From: caohang @ 2026-04-07 6:17 UTC (permalink / raw)
To: gregkh, robh, krzk+dt, conor+dt, Thinh.Nguyen, p.zabel,
linux-kernel, linux-usb, devicetree
Cc: ningyu, linmin, pinkesh.vaghela, Hang Cao
From: Hang Cao <caohang@eswincomputing.com>
The EIC7700 USB controller requires a USB PHY RESET operation.PHY RESET
operation was missed in the verification version, as it was performed in
ESWIN's U-Boot.
If a non-ESWIN provided loader is used, this issue will occur, resulting
in USB not work.This patch does not introduce any backward incompatibility
since the dts is not upstream yet.
Fixes: c640a4239db5 ("dt-bindings: usb: Add ESWIN EIC7700 USB controller")
Signed-off-by: Hang Cao <caohang@eswincomputing.com>
---
.../devicetree/bindings/usb/eswin,eic7700-usb.yaml | 7 ++++---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/Documentation/devicetree/bindings/usb/eswin,eic7700-usb.yaml b/Documentation/devicetree/bindings/usb/eswin,eic7700-usb.yaml
index 41c3b1b98991..658260619423 100644
--- a/Documentation/devicetree/bindings/usb/eswin,eic7700-usb.yaml
+++ b/Documentation/devicetree/bindings/usb/eswin,eic7700-usb.yaml
@@ -41,12 +41,13 @@ properties:
- const: usb_en
resets:
- maxItems: 2
+ maxItems: 3
reset-names:
items:
- const: vaux
- const: usb_rst
+ - const: usb_phy
eswin,hsp-sp-csr:
description:
@@ -85,8 +86,8 @@ examples:
interrupt-parent = <&plic>;
interrupts = <85>;
interrupt-names = "peripheral";
- resets = <&reset 84>, <&hspcrg 2>;
- reset-names = "vaux", "usb_rst";
+ resets = <&reset 84>, <&hspcrg 2>, <&hspcrg 4>;
+ reset-names = "vaux", "usb_rst", "usb_phy";
dr_mode = "peripheral";
maximum-speed = "high-speed";
phy_type = "utmi";
--
2.34.1
^ permalink raw reply related
* Re: Spurious errors "ucsi_acpi USBC000:00: bogus connector number in CCI: 1" on 7.0-rc7
From: Greg Kroah-Hartman @ 2026-04-07 5:58 UTC (permalink / raw)
To: Takashi Iwai; +Cc: linux-usb, linux-kernel, Nathan Rebello, Heikki Krogerus
In-Reply-To: <875x63gwid.wl-tiwai@suse.de>
On Tue, Apr 07, 2026 at 07:38:50AM +0200, Takashi Iwai wrote:
> Hi,
>
> since 7.0-rc7, I'm getting a few errors
> ucsi_acpi USBC000:00: bogus connector number in CCI: 1
> at boot of Thinkpad T14s Gen 6 AMD with a dock.
>
> Obviously this came from the commit d2d8c17ac01a ("usb: typec: ucsi:
> validate connector number in ucsi_notify_common()"), and reverting it
> made it gone away. I didn't notice anything practically broken either
> before or after the revert, though -- the USB devices connected on the
> dock keep working, at least.
>
> Is this a firmware bug, or some missing piece in the code?
> Judging from the message, it means that ucsi->cap.num_connectors is 0,
> I suppose.
Ugh, what's the odds this is an off-by-one error in the firmware? :)
Nathan and Heikki, any ideas?
thanks,
greg k-h
^ permalink raw reply
* Spurious errors "ucsi_acpi USBC000:00: bogus connector number in CCI: 1" on 7.0-rc7
From: Takashi Iwai @ 2026-04-07 5:38 UTC (permalink / raw)
To: linux-usb
Cc: linux-kernel, Nathan Rebello, Heikki Krogerus, Greg Kroah-Hartman
Hi,
since 7.0-rc7, I'm getting a few errors
ucsi_acpi USBC000:00: bogus connector number in CCI: 1
at boot of Thinkpad T14s Gen 6 AMD with a dock.
Obviously this came from the commit d2d8c17ac01a ("usb: typec: ucsi:
validate connector number in ucsi_notify_common()"), and reverting it
made it gone away. I didn't notice anything practically broken either
before or after the revert, though -- the USB devices connected on the
dock keep working, at least.
Is this a firmware bug, or some missing piece in the code?
Judging from the message, it means that ucsi->cap.num_connectors is 0,
I suppose.
thanks,
Takashi
^ permalink raw reply
* RE: [PATCH] usb: cdnsp: Add support for device-only configuration
From: Pawel Laszczak @ 2026-04-07 5:21 UTC (permalink / raw)
To: Peter Chen (CIX)
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: <adMNBsPYNg497Doa@nchen-desktop>
>
>
>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?
Theoretically, yes, but for a host-only configuration, we would typically
use the default xHCI driver instead. Since there isn't a separate
standalone driver for device-only mode in this IP, using no_drd
to force peripheral mode makes the most sense here.
Pawel
>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
* I need your help
From: Jisun Lee @ 2026-04-07 4:52 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
* Re: [PATCH v4] usbip: tools: add hint when no exported devices are found
From: Zongmin Zhou @ 2026-04-07 2:34 UTC (permalink / raw)
To: Shuah Khan
Cc: gregkh, i, linux-kernel, linux-usb, valentina.manea.m,
Zongmin Zhou
In-Reply-To: <83e82b09-a617-4e56-980c-563d8fba2045@linuxfoundation.org>
On 2026/4/7 05:12, Shuah Khan wrote:
> 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?
Shuah,
Actually, refresh_exported_devices() has more than two callers:
1. usbip_generic_driver_open() (called by both usbip_host_driver_open()
and usbip_device_driver_open() functions)
2. usbip_generic_refresh_device_list() (called via usbip_refresh_device_list
from process_request())
As we discussed earlier, placing the message in refresh_exported_devices()
covers all scenarios: usbipd startup, usbip list -r, and usbip attach.
usbip_generic_driver_open() is called only once at initialization.
Best regards,
Zongmin
>
> thanks,
> -- Shuah
^ permalink raw reply
* 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
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