* Re: [PATCH] mm/slab: align kmalloc to cacheline when DMA API debugging is active
From: Harry Yoo (Oracle) @ 2026-03-27 6:37 UTC (permalink / raw)
To: Mikhail Gavrilov
Cc: vbabka, akpm, hao.li, cl, rientjes, roman.gushchin, linux-mm,
linux-kernel, linux-usb, stern, linux, andy.shevchenko, hch,
Jeff.kirsher
In-Reply-To: <20260327055846.248829-1-mikhail.v.gavrilov@gmail.com>
On Fri, Mar 27, 2026 at 10:58:46AM +0500, Mikhail Gavrilov wrote:
> When CONFIG_DMA_API_DEBUG is enabled, the DMA debug infrastructure
> tracks active mappings per cacheline and warns if two different DMA
> mappings share the same cacheline ("cacheline tracking EEXIST,
> overlapping mappings aren't supported").
>
> On x86_64, ARCH_KMALLOC_MINALIGN defaults to 8, so small kmalloc
> allocations (e.g. the 8-byte hub->buffer and hub->status in the USB
> hub driver) frequently land in the same 64-byte cacheline. When both
> are DMA-mapped, this triggers a false positive warning.
Is it feasible to suppress the warning if dma_get_cache_alignment() is
smaller than L1_CACHE_BYTES?
> This has been reported repeatedly since v5.14 (when the EEXIST check
> was added) across various USB host controllers and devices including
> xhci_hcd with USB hubs, USB audio devices, and USB ethernet adapters.
>
> Raise ARCH_KMALLOC_MINALIGN to L1_CACHE_BYTES when CONFIG_DMA_API_DEBUG
> is enabled, ensuring each kmalloc allocation occupies its own cacheline
> and eliminating the false positive.
>
> Verified with a kernel module reproducer that performs two kmalloc(8)
> allocations back-to-back and DMA-maps both:
>
> Before: allocations share a cacheline, EEXIST fires within ~50 pairs
> After: 64 pairs allocated, all in separate cachelines, no warning
>
> Fixes: 2b4bbc6231d7 ("dma-debug: report -EEXIST errors in add_dma_entry")
> Link: https://bugzilla.kernel.org/show_bug.cgi?id=215740
> Suggested-by: Alan Stern <stern@rowland.harvard.edu>
> Suggested-by: Guenter Roeck <linux@roeck-us.net>
> Tested-by: Jeff Kirsher <Jeff.kirsher@gmail.com>
> Tested-by: Mikhail Gavrilov <mikhail.v.gavrilov@gmail.com>
> Signed-off-by: Mikhail Gavrilov <mikhail.v.gavrilov@gmail.com>
--
Cheers,
Harry / Hyeonggon
^ permalink raw reply
* Re: [PATCH v2 1/3] usb: usbip: fix integer overflow in usbip_recv_iso()
From: Greg KH @ 2026-03-27 6:25 UTC (permalink / raw)
To: Nathan Rebello; +Cc: linux-usb, addcontent08, skhan, kyungtae.kim
In-Reply-To: <20260327043153.643-1-nathan.c.rebello@gmail.com>
On Fri, Mar 27, 2026 at 12:31:53AM -0400, Nathan Rebello wrote:
> Hi Kelvin,
>
> Your series hardens usbip_recv_iso() and usbip_pad_iso() against
> malicious number_of_packets values, but the bad value still lands in
> urb->number_of_packets via usbip_pack_ret_submit() before those
> checks run.
>
> The patch below validates at the source — in usbip_pack_ret_submit()
> before the overwrite — and checks against the original
> urb->number_of_packets (the actual allocation bound) rather than
> USBIP_MAX_ISO_PACKETS. This is a tighter check because the URB may
> have been allocated for far fewer than 1024 packets.
>
> This could complement your series as an additional layer, or stand
> alone. Would be glad to rework this however the maintainers see fit —
> whether folded into your series or submitted separately.
Please submit it separately, on top of that series, to make it easier to
review and apply.
thanks,
greg k-h
^ permalink raw reply
* [PATCH] mm/slab: align kmalloc to cacheline when DMA API debugging is active
From: Mikhail Gavrilov @ 2026-03-27 5:58 UTC (permalink / raw)
To: vbabka, harry.yoo, akpm
Cc: hao.li, cl, rientjes, roman.gushchin, linux-mm, linux-kernel,
linux-usb, stern, linux, andy.shevchenko, hch, Jeff.kirsher,
Mikhail Gavrilov
When CONFIG_DMA_API_DEBUG is enabled, the DMA debug infrastructure
tracks active mappings per cacheline and warns if two different DMA
mappings share the same cacheline ("cacheline tracking EEXIST,
overlapping mappings aren't supported").
On x86_64, ARCH_KMALLOC_MINALIGN defaults to 8, so small kmalloc
allocations (e.g. the 8-byte hub->buffer and hub->status in the USB
hub driver) frequently land in the same 64-byte cacheline. When both
are DMA-mapped, this triggers a false positive warning.
This has been reported repeatedly since v5.14 (when the EEXIST check
was added) across various USB host controllers and devices including
xhci_hcd with USB hubs, USB audio devices, and USB ethernet adapters.
Raise ARCH_KMALLOC_MINALIGN to L1_CACHE_BYTES when CONFIG_DMA_API_DEBUG
is enabled, ensuring each kmalloc allocation occupies its own cacheline
and eliminating the false positive.
Verified with a kernel module reproducer that performs two kmalloc(8)
allocations back-to-back and DMA-maps both:
Before: allocations share a cacheline, EEXIST fires within ~50 pairs
After: 64 pairs allocated, all in separate cachelines, no warning
Fixes: 2b4bbc6231d7 ("dma-debug: report -EEXIST errors in add_dma_entry")
Link: https://bugzilla.kernel.org/show_bug.cgi?id=215740
Suggested-by: Alan Stern <stern@rowland.harvard.edu>
Suggested-by: Guenter Roeck <linux@roeck-us.net>
Tested-by: Jeff Kirsher <Jeff.kirsher@gmail.com>
Tested-by: Mikhail Gavrilov <mikhail.v.gavrilov@gmail.com>
Signed-off-by: Mikhail Gavrilov <mikhail.v.gavrilov@gmail.com>
---
Reproducer module that triggers the bug reliably:
https://bugzilla.kernel.org/attachment.cgi?id=309769
include/linux/slab.h | 13 +++++++++++++
1 file changed, 13 insertions(+)
diff --git a/include/linux/slab.h b/include/linux/slab.h
index 15a60b501b95..f044956e17c1 100644
--- a/include/linux/slab.h
+++ b/include/linux/slab.h
@@ -536,6 +536,19 @@ static inline bool kmem_dump_obj(void *object) { return false; }
#endif
#endif
+/*
+ * Align memory allocations to cache lines if DMA API debugging is active
+ * to avoid false positive DMA overlapping error messages.
+ */
+#ifdef CONFIG_DMA_API_DEBUG
+#ifndef ARCH_KMALLOC_MINALIGN
+#define ARCH_KMALLOC_MINALIGN L1_CACHE_BYTES
+#elif ARCH_KMALLOC_MINALIGN < L1_CACHE_BYTES
+#undef ARCH_KMALLOC_MINALIGN
+#define ARCH_KMALLOC_MINALIGN L1_CACHE_BYTES
+#endif
+#endif
+
#ifndef ARCH_KMALLOC_MINALIGN
#define ARCH_KMALLOC_MINALIGN __alignof__(unsigned long long)
#elif ARCH_KMALLOC_MINALIGN > 8
--
2.53.0
^ permalink raw reply related
* Re: [PATCH v2 1/3] usb: usbip: fix integer overflow in usbip_recv_iso()
From: Nathan Rebello @ 2026-03-27 4:31 UTC (permalink / raw)
To: linux-usb; +Cc: addcontent08, gregkh, skhan, kyungtae.kim
In-Reply-To: <20260325104841.8282-1-addcontent08@gmail.com>
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 4092 bytes --]
Hi Kelvin,
Your series hardens usbip_recv_iso() and usbip_pad_iso() against
malicious number_of_packets values, but the bad value still lands in
urb->number_of_packets via usbip_pack_ret_submit() before those
checks run.
The patch below validates at the source — in usbip_pack_ret_submit()
before the overwrite — and checks against the original
urb->number_of_packets (the actual allocation bound) rather than
USBIP_MAX_ISO_PACKETS. This is a tighter check because the URB may
have been allocated for far fewer than 1024 packets.
This could complement your series as an additional layer, or stand
alone. Would be glad to rework this however the maintainers see fit —
whether folded into your series or submitted separately.
---
From: Nathan Rebello <nathan.c.rebello@gmail.com>
Subject: [PATCH] usbip: vhci: reject RET_SUBMIT with inflated
number_of_packets
When a USB/IP client receives a RET_SUBMIT response,
usbip_pack_ret_submit() unconditionally overwrites
urb->number_of_packets from the network PDU. This value is
subsequently used as the loop bound in usbip_recv_iso() and
usbip_pad_iso() to iterate over urb->iso_frame_desc[], a flexible
array whose size was fixed at URB allocation time based on the
*original* number_of_packets from the CMD_SUBMIT.
A malicious USB/IP server can set number_of_packets in the response
to a value larger than what was originally submitted, causing a heap
out-of-bounds write when usbip_recv_iso() writes to
urb->iso_frame_desc[i] beyond the allocated region.
KASAN confirmed this with kernel 7.0.0-rc5:
BUG: KASAN: slab-out-of-bounds in usbip_recv_iso+0x46a/0x640
Write of size 4 at addr ffff888106351d40 by task vhci_rx/69
The buggy address is located 0 bytes to the right of
allocated 320-byte region [ffff888106351c00, ffff888106351d40)
The server side (stub_rx.c) and gadget side (vudc_rx.c) already
validate number_of_packets in the CMD_SUBMIT path since commits
c6688ef9f297 ("usbip: fix stub_rx: harden CMD_SUBMIT path to handle
malicious input") and b78d830f0049 ("usbip: fix vudc_rx: harden
CMD_SUBMIT path to handle malicious input"). The server side validates
against USBIP_MAX_ISO_PACKETS because no URB exists yet at that point.
On the client side we have the original URB, so we can use the tighter
bound: the response must not exceed the original number_of_packets.
This mirrors the existing validation of actual_length against
transfer_buffer_length in usbip_recv_xbuff(), which checks the
response value against the original allocation size.
Fix this by checking rpdu->number_of_packets against
urb->number_of_packets in usbip_pack_ret_submit() before the
overwrite. On violation, clamp to zero so that usbip_recv_iso() and
usbip_pad_iso() safely return early.
Fixes: 0775a9cbc798 ("staging: usbip: vhci extension: modifications to the client side")
Cc: stable@vger.kernel.org
Signed-off-by: Nathan Rebello <nathan.c.rebello@gmail.com>
---
drivers/usb/usbip/usbip_common.c | 13 ++++++++++++-
1 file changed, 12 insertions(+), 1 deletion(-)
diff --git a/drivers/usb/usbip/usbip_common.c b/drivers/usb/usbip/usbip_common.c
--- a/drivers/usb/usbip/usbip_common.c
+++ b/drivers/usb/usbip/usbip_common.c
@@ -470,7 +470,18 @@ static void usbip_pack_ret_submit(struct usbip_header *pdu, struct urb *urb,
urb->status = rpdu->status;
urb->actual_length = rpdu->actual_length;
urb->start_frame = rpdu->start_frame;
- urb->number_of_packets = rpdu->number_of_packets;
+ /*
+ * The number_of_packets field determines the length of
+ * iso_frame_desc[], which is a flexible array allocated
+ * at URB creation time. A response must never claim more
+ * packets than originally submitted; doing so would cause
+ * an out-of-bounds write in usbip_recv_iso() and
+ * usbip_pad_iso(). Clamp to zero on violation so both
+ * functions safely return early.
+ */
+ if (rpdu->number_of_packets < 0 ||
+ rpdu->number_of_packets > urb->number_of_packets)
+ rpdu->number_of_packets = 0;
+ urb->number_of_packets = rpdu->number_of_packets;
urb->error_count = rpdu->error_count;
}
}
^ permalink raw reply
* Re: [PATCH] usb: gadget: u_ether: Fix race between gether_disconnect and eth_stop
From: Dayu Jiang @ 2026-03-27 2:52 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: Kuen-Han Tsai, David Brownell, linux-usb, linux-kernel, stable
In-Reply-To: <2026032614-most-opposing-4363@gregkh>
On Thu, Mar 26, 2026 at 11:35:31AM +0100, Greg Kroah-Hartman wrote:
> On Thu, Mar 26, 2026 at 03:53:13PM +0800, Dayu Jiang wrote:
> > On Wed, Mar 11, 2026 at 05:12:15PM +0800, Kuen-Han Tsai wrote:
> > > A race condition between gether_disconnect() and eth_stop() leads to a
> > > NULL pointer dereference. Specifically, if eth_stop() is triggered
> > > concurrently while gether_disconnect() is tearing down the endpoints,
> > > eth_stop() attempts to access the cleared endpoint descriptor, causing
> > > the following NPE:
> > >
> > > Unable to handle kernel NULL pointer dereference
> > > Call trace:
> > > __dwc3_gadget_ep_enable+0x60/0x788
> > > dwc3_gadget_ep_enable+0x70/0xe4
> > > usb_ep_enable+0x60/0x15c
> > > eth_stop+0xb8/0x108
> > >
> > > Because eth_stop() crashes while holding the dev->lock, the thread
> > > running gether_disconnect() fails to acquire the same lock and spins
> > > forever, resulting in a hardlockup:
> > >
> > > Core - Debugging Information for Hardlockup core(7)
> > > Call trace:
> > > queued_spin_lock_slowpath+0x94/0x488
> > > _raw_spin_lock+0x64/0x6c
> > > gether_disconnect+0x19c/0x1e8
> > > ncm_set_alt+0x68/0x1a0
> > > composite_setup+0x6a0/0xc50
> > >
> > Hi Greg,
> > Hit the same issue during NCM switch stress test.
> > Can you take a look at this patch and check if it’s ready for merge?
>
> This is already in my tree and in linux-next and will go to Linus this
> weekend.
Got it. Sorry for the multiple copies of the same email—our mail server had some issues and sent them repeatedly. My apologies for the noise.
>
> thanks,
>
> greg k-h
^ permalink raw reply
* Re: [PATCH] usb: gadget: u_ether: Fix race between gether_disconnect and eth_stop
From: Dayu Jiang @ 2026-03-27 2:44 UTC (permalink / raw)
To: Kuen-Han Tsai, Greg Kroah-Hartman; +Cc: linux-usb, linux-kernel, stable
In-Reply-To: <20260311-gether-disconnect-npe-v1-1-454966adf7c7@google.com>
On Wed, Mar 11, 2026 at 05:12:15PM +0800, Kuen-Han Tsai wrote:
> A race condition between gether_disconnect() and eth_stop() leads to a
> NULL pointer dereference. Specifically, if eth_stop() is triggered
> concurrently while gether_disconnect() is tearing down the endpoints,
> eth_stop() attempts to access the cleared endpoint descriptor, causing
> the following NPE:
>
> Unable to handle kernel NULL pointer dereference
> Call trace:
> __dwc3_gadget_ep_enable+0x60/0x788
> dwc3_gadget_ep_enable+0x70/0xe4
> usb_ep_enable+0x60/0x15c
> eth_stop+0xb8/0x108
>
> Because eth_stop() crashes while holding the dev->lock, the thread
> running gether_disconnect() fails to acquire the same lock and spins
> forever, resulting in a hardlockup:
>
> Core - Debugging Information for Hardlockup core(7)
> Call trace:
> queued_spin_lock_slowpath+0x94/0x488
> _raw_spin_lock+0x64/0x6c
> gether_disconnect+0x19c/0x1e8
> ncm_set_alt+0x68/0x1a0
> composite_setup+0x6a0/0xc50
>
> The root cause is that the clearing of dev->port_usb in
> gether_disconnect() is delayed until the end of the function.
>
> Move the clearing of dev->port_usb to the very beginning of
> gether_disconnect() while holding dev->lock. This cuts off the link
> immediately, ensuring eth_stop() will see dev->port_usb as NULL and
> safely bail out.
>
Hi Greg,
Hit the same issue during NCM switch stress test.
Can you take a look at this patch and check if it’s ready for merge?
Thanks,
Dayu Jiang
> Fixes: 2b3d942c4878 ("usb ethernet gadget: split out network core")
> Cc: stable@vger.kernel.org
> Signed-off-by: Kuen-Han Tsai <khtsai@google.com>
> ---
> drivers/usb/gadget/function/u_ether.c | 10 +++++-----
> 1 file changed, 5 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/usb/gadget/function/u_ether.c b/drivers/usb/gadget/function/u_ether.c
> index 338f6e2a85a9..2c970a0eafd9 100644
> --- a/drivers/usb/gadget/function/u_ether.c
> +++ b/drivers/usb/gadget/function/u_ether.c
> @@ -1246,6 +1246,11 @@ void gether_disconnect(struct gether *link)
>
> DBG(dev, "%s\n", __func__);
>
> + spin_lock(&dev->lock);
> + dev->port_usb = NULL;
> + link->is_suspend = false;
> + spin_unlock(&dev->lock);
> +
> netif_stop_queue(dev->net);
> netif_carrier_off(dev->net);
>
> @@ -1283,11 +1288,6 @@ void gether_disconnect(struct gether *link)
> dev->header_len = 0;
> dev->unwrap = NULL;
> dev->wrap = NULL;
> -
> - spin_lock(&dev->lock);
> - dev->port_usb = NULL;
> - link->is_suspend = false;
> - spin_unlock(&dev->lock);
> }
> EXPORT_SYMBOL_GPL(gether_disconnect);
>
>
> ---
> base-commit: 1be3b77de4eb89af8ae2fd6610546be778e25589
> change-id: 20260311-gether-disconnect-npe-5861d9831dff
>
> Best regards,
> --
> Kuen-Han Tsai <khtsai@google.com>
>
^ permalink raw reply
* Re: [PATCH] usb: gadget: u_ether: Fix race between gether_disconnect and eth_stop
From: Dayu Jiang @ 2026-03-27 2:36 UTC (permalink / raw)
To: Kuen-Han Tsai, Greg Kroah-Hartman
Cc: David Brownell, linux-usb, linux-kernel, stable
In-Reply-To: <20260311-gether-disconnect-npe-v1-1-454966adf7c7@google.com>
On Wed, Mar 11, 2026 at 05:12:15PM +0800, Kuen-Han Tsai wrote:
> A race condition between gether_disconnect() and eth_stop() leads to a
> NULL pointer dereference. Specifically, if eth_stop() is triggered
> concurrently while gether_disconnect() is tearing down the endpoints,
> eth_stop() attempts to access the cleared endpoint descriptor, causing
> the following NPE:
>
> Unable to handle kernel NULL pointer dereference
> Call trace:
> __dwc3_gadget_ep_enable+0x60/0x788
> dwc3_gadget_ep_enable+0x70/0xe4
> usb_ep_enable+0x60/0x15c
> eth_stop+0xb8/0x108
>
> Because eth_stop() crashes while holding the dev->lock, the thread
> running gether_disconnect() fails to acquire the same lock and spins
> forever, resulting in a hardlockup:
>
> Core - Debugging Information for Hardlockup core(7)
> Call trace:
> queued_spin_lock_slowpath+0x94/0x488
> _raw_spin_lock+0x64/0x6c
> gether_disconnect+0x19c/0x1e8
> ncm_set_alt+0x68/0x1a0
> composite_setup+0x6a0/0xc50
>
> The root cause is that the clearing of dev->port_usb in
> gether_disconnect() is delayed until the end of the function.
>
> Move the clearing of dev->port_usb to the very beginning of
> gether_disconnect() while holding dev->lock. This cuts off the link
> immediately, ensuring eth_stop() will see dev->port_usb as NULL and
> safely bail out.
>
Hi Greg,
Hit the same issue during NCM switch stress test.
Can you take a look at this patch and check if it’s ready for merge?
Thanks,
Dayu Jiang
> Fixes: 2b3d942c4878 ("usb ethernet gadget: split out network core")
> Cc: stable@vger.kernel.org
> Signed-off-by: Kuen-Han Tsai <khtsai@google.com>
> ---
> drivers/usb/gadget/function/u_ether.c | 10 +++++-----
> 1 file changed, 5 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/usb/gadget/function/u_ether.c b/drivers/usb/gadget/function/u_ether.c
> index 338f6e2a85a9..2c970a0eafd9 100644
> --- a/drivers/usb/gadget/function/u_ether.c
> +++ b/drivers/usb/gadget/function/u_ether.c
> @@ -1246,6 +1246,11 @@ void gether_disconnect(struct gether *link)
>
> DBG(dev, "%s\n", __func__);
>
> + spin_lock(&dev->lock);
> + dev->port_usb = NULL;
> + link->is_suspend = false;
> + spin_unlock(&dev->lock);
> +
> netif_stop_queue(dev->net);
> netif_carrier_off(dev->net);
>
> @@ -1283,11 +1288,6 @@ void gether_disconnect(struct gether *link)
> dev->header_len = 0;
> dev->unwrap = NULL;
> dev->wrap = NULL;
> -
> - spin_lock(&dev->lock);
> - dev->port_usb = NULL;
> - link->is_suspend = false;
> - spin_unlock(&dev->lock);
> }
> EXPORT_SYMBOL_GPL(gether_disconnect);
>
>
> ---
> base-commit: 1be3b77de4eb89af8ae2fd6610546be778e25589
> change-id: 20260311-gether-disconnect-npe-5861d9831dff
>
> Best regards,
> --
> Kuen-Han Tsai <khtsai@google.com>
>
^ permalink raw reply
* Re: [PATCH 2/2] USB: serial: pl2303: add new PID to support PL256X (TYPE_MP)
From: Charles Yeh @ 2026-03-27 2:29 UTC (permalink / raw)
To: Greg KH; +Cc: johan, linux-usb, charles-yeh, kernel test robot
In-Reply-To: <2026032549-zodiac-navigator-23ac@gregkh>
> just redo the original patch and send it as a v2 as the documentation describes
> how to do.
Thanks for the guidance.
I have updated the original patch and submitted it as v2 as requested.
Thanks,
Charles.
^ permalink raw reply
* [Bug 215740] kernel warning: DMA-API: xhci_hcd: cacheline tracking EEXIST, overlapping mappings aren't supported
From: bugzilla-daemon @ 2026-03-27 0:04 UTC (permalink / raw)
To: linux-usb
In-Reply-To: <bug-215740-208809@https.bugzilla.kernel.org/>
https://bugzilla.kernel.org/show_bug.cgi?id=215740
--- Comment #52 from Guenter Roeck (linux@roeck-us.net) ---
#51: ounds good. I'd suggest to go ahead.
--
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 v3 1/2] usb: core: use dedicated spinlock for offload state
From: Mathias Nyman @ 2026-03-26 23:58 UTC (permalink / raw)
To: Guan-Yu Lin, gregkh, mathias.nyman, perex, tiwai, quic_wcheng,
broonie, arnd, xiaopei01, wesley.cheng, hannelotta, sakari.ailus,
eadavis, stern, amardeep.rai, xu.yang_2, andriy.shevchenko,
nkapron
Cc: linux-usb, linux-kernel, linux-sound, stable
In-Reply-To: <20260324203851.4091193-2-guanyulin@google.com>
Hi
On 3/24/26 22:38, Guan-Yu Lin wrote:
> Replace the coarse USB device lock with a dedicated offload_lock
> spinlock to reduce contention during offload operations. Use
> offload_pm_locked to synchronize with PM transitions and replace
> the legacy offload_at_suspend flag.
>
> Optimize usb_offload_get/put by switching from auto-resume/suspend
> to pm_runtime_get_if_active(). This ensures offload state is only
> modified when the device is already active, avoiding unnecessary
> power transitions.
>
> Cc: stable@vger.kernel.org
> Fixes: ef82a4803aab ("xhci: sideband: add api to trace sideband usage")
> Signed-off-by: Guan-Yu Lin <guanyulin@google.com>
> ---
> diff --git a/drivers/usb/core/offload.c b/drivers/usb/core/offload.c
> index 7c699f1b8d2b..c24945294d7e 100644
> --- a/drivers/usb/core/offload.c
> +++ b/drivers/usb/core/offload.c
> @@ -25,33 +25,30 @@
> */
> int usb_offload_get(struct usb_device *udev)
> {
> - int ret;
> + int ret = 0;
>
> - usb_lock_device(udev);
> - if (udev->state == USB_STATE_NOTATTACHED) {
> - usb_unlock_device(udev);
> + if (!usb_get_dev(udev))
> return -ENODEV;
> - }
>
> - if (udev->state == USB_STATE_SUSPENDED ||
> - udev->offload_at_suspend) {
> - usb_unlock_device(udev);
> - return -EBUSY;
> + if (pm_runtime_get_if_active(&udev->dev) != 1) {
> + ret = -EBUSY;
> + goto err_rpm;
> }
>
> - /*
> - * offload_usage could only be modified when the device is active, since
> - * it will alter the suspend flow of the device.
> - */
> - ret = usb_autoresume_device(udev);
> - if (ret < 0) {
> - usb_unlock_device(udev);
> - return ret;
> + spin_lock(&udev->offload_lock);
> +
> + if (udev->offload_pm_locked) {
Could we get rid of 'udev->offload_pm_locked' and 'usb_offload_set_pm_locked()'
by calling a synchronous pm_runtime_get_sync() or pm_runtime_resume_and_get()?
This way we can ensure udev->offload_usage isn't modified mid runtime suspend or
resume as resume is guaranteed to have finished and suspend won't be called,
at least not for the runtime case.
> + ret = -EAGAIN;
> + goto err;
> }
>
> udev->offload_usage++;
> - usb_autosuspend_device(udev);
> - usb_unlock_device(udev);
> +
> +err:
> + spin_unlock(&udev->offload_lock);
> + pm_runtime_put_autosuspend(&udev->dev);
> +err_rpm:
> + usb_put_dev(udev);
>
> return ret;
> }
> @@ -69,35 +66,32 @@ EXPORT_SYMBOL_GPL(usb_offload_get);
> */
> int usb_offload_put(struct usb_device *udev)
> {
> - int ret;
> + int ret = 0;
>
> - usb_lock_device(udev);
> - if (udev->state == USB_STATE_NOTATTACHED) {
> - usb_unlock_device(udev);
> + if (!usb_get_dev(udev))
> return -ENODEV;
> - }
>
> - if (udev->state == USB_STATE_SUSPENDED ||
> - udev->offload_at_suspend) {
> - usb_unlock_device(udev);
> - return -EBUSY;
> + if (pm_runtime_get_if_active(&udev->dev) != 1) {
> + ret = -EBUSY;
> + goto err_rpm;
> }
>
> - /*
> - * offload_usage could only be modified when the device is active, since
> - * it will alter the suspend flow of the device.
> - */
> - ret = usb_autoresume_device(udev);
> - if (ret < 0) {
> - usb_unlock_device(udev);
> - return ret;
> + spin_lock(&udev->offload_lock);
> +
> + if (udev->offload_pm_locked) {
> + ret = -EAGAIN;
> + goto err;
Ending up here is about unlucky timing, i.e. usb_offload_put() is called while
device is pretending to suspend/resume. Result here is that udev->offload_usage is
not decremented, and usb device won't properly suspend anymore even if device is
no longer offloaded.
> }
>
> /* Drop the count when it wasn't 0, ignore the operation otherwise. */
> if (udev->offload_usage)
> udev->offload_usage--;
> - usb_autosuspend_device(udev);
> - usb_unlock_device(udev);
> +
> +err:
> + spin_unlock(&udev->offload_lock);
> + pm_runtime_put_autosuspend(&udev->dev);
> +err_rpm:
> + usb_put_dev(udev);
>
> return ret;
> }
> @@ -112,25 +106,52 @@ EXPORT_SYMBOL_GPL(usb_offload_put);
> * management.
> *
> * The caller must hold @udev's device lock. In addition, the caller should
> - * ensure downstream usb devices are all either suspended or marked as
> - * "offload_at_suspend" to ensure the correctness of the return value.
> + * ensure downstream usb devices are all marked as "offload_pm_locked" to
> + * ensure the correctness of the return value.
> *
> * Returns true on any offload activity, false otherwise.
> */
> bool usb_offload_check(struct usb_device *udev) __must_hold(&udev->dev->mutex)
> {
> struct usb_device *child;
> - bool active;
> + bool active = false;
> int port1;
>
> + spin_lock(&udev->offload_lock);
> + if (udev->offload_usage)
> + active = true;
> + spin_unlock(&udev->offload_lock);
> +> + if (active)
> + return true;
Not sure what the purpose of the spinlock is above
> +
> usb_hub_for_each_child(udev, port1, child) {
> usb_lock_device(child);
> active = usb_offload_check(child);
> usb_unlock_device(child);
> +
> if (active)
> - return true;
> + break;
> }
>
> - return !!udev->offload_usage;
> + return active;
> }
> EXPORT_SYMBOL_GPL(usb_offload_check);
> +
> +/**
> + * usb_offload_set_pm_locked - set the PM lock state of a USB device
> + * @udev: the USB device to modify
> + * @locked: the new lock state
> + *
> + * Setting @locked to true prevents offload_usage from being modified. This
> + * ensures that offload activities cannot be started or stopped during critical
> + * power management transitions, maintaining a stable state for the duration
> + * of the transition.
> + */
> +void usb_offload_set_pm_locked(struct usb_device *udev, bool locked)
> +{
> + spin_lock(&udev->offload_lock);
> + udev->offload_pm_locked = locked;
> + spin_unlock(&udev->offload_lock);
>
spinlock usage unclear here as well
Thanks
Mathias
^ permalink raw reply
* Re: [PATCH v3 1/1] usb: dwc3: Add optional VBUS regulator support to SpacemiT K1
From: Thinh Nguyen @ 2026-03-26 23:25 UTC (permalink / raw)
To: Chukun Pan
Cc: Thinh Nguyen, Yixun Lan, Ze Huang, Greg Kroah-Hartman,
linux-riscv@lists.infradead.org, linux-kernel@vger.kernel.org,
linux-usb@vger.kernel.org, spacemit@lists.linux.dev
In-Reply-To: <20260326100010.3588454-2-amadeus@jmu.edu.cn>
On Thu, Mar 26, 2026, Chukun Pan wrote:
> Some SpacemiT K1 boards (like OrangePi R2S) provide USB VBUS
> through a controllable regulator. Add support for the optional
> vbus-supply property so the regulator can be properly managed
> in host mode instead of left always-on. Note that this doesn't
> apply to USB Hub downstream ports with different VBUS supplies.
>
> The enabled and disabled actions of the regulator are handled
> automatically by devm_regulator_get_enable_optional().
>
> Signed-off-by: Chukun Pan <amadeus@jmu.edu.cn>
> ---
> drivers/usb/dwc3/dwc3-generic-plat.c | 23 ++++++++++++++++++++++-
> 1 file changed, 22 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/usb/dwc3/dwc3-generic-plat.c b/drivers/usb/dwc3/dwc3-generic-plat.c
> index e846844e0023..64f5e9f20663 100644
> --- a/drivers/usb/dwc3/dwc3-generic-plat.c
> +++ b/drivers/usb/dwc3/dwc3-generic-plat.c
> @@ -12,6 +12,8 @@
> #include <linux/reset.h>
> #include <linux/regmap.h>
> #include <linux/mfd/syscon.h>
> +#include <linux/regulator/consumer.h>
> +#include <linux/usb/otg.h>
> #include "glue.h"
>
> #define EIC7700_HSP_BUS_FILTER_EN BIT(0)
> @@ -69,6 +71,20 @@ static int dwc3_eic7700_init(struct dwc3_generic *dwc3g)
> return 0;
> }
>
> +static int dwc3_spacemit_k1_init(struct dwc3_generic *dwc3g)
> +{
> + struct device *dev = dwc3g->dev;
> +
> + if (usb_get_dr_mode(dev) == USB_DR_MODE_HOST) {
> + int ret = devm_regulator_get_enable_optional(dev, "vbus");
> +
> + if (ret && ret != -ENODEV)
> + return dev_err_probe(dev, ret, "failed to enable VBUS\n");
> + }
> +
> + return 0;
> +}
> +
> static int dwc3_generic_probe(struct platform_device *pdev)
> {
> const struct dwc3_generic_config *plat_config;
> @@ -201,6 +217,11 @@ static const struct dev_pm_ops dwc3_generic_dev_pm_ops = {
> dwc3_generic_runtime_idle)
> };
>
> +static const struct dwc3_generic_config spacemit_k1_dwc3 = {
> + .init = dwc3_spacemit_k1_init,
> + .properties = DWC3_DEFAULT_PROPERTIES,
> +};
> +
> static const struct dwc3_generic_config fsl_ls1028_dwc3 = {
> .properties.gsbuscfg0_reqinfo = 0x2222,
> };
> @@ -211,7 +232,7 @@ static const struct dwc3_generic_config eic7700_dwc3 = {
> };
>
> static const struct of_device_id dwc3_generic_of_match[] = {
> - { .compatible = "spacemit,k1-dwc3", },
> + { .compatible = "spacemit,k1-dwc3", &spacemit_k1_dwc3},
> { .compatible = "fsl,ls1028a-dwc3", &fsl_ls1028_dwc3},
> { .compatible = "eswin,eic7700-dwc3", &eic7700_dwc3},
> { /* sentinel */ }
> --
> 2.34.1
>
Acked-by: Thinh Nguyen <Thinh.Nguyen@synopsys.com>
BR,
Thinh
^ permalink raw reply
* Re: [RFC PATCH 1/2] xhci: prevent automatic endpoint restart after stall or error
From: Thinh Nguyen @ 2026-03-26 23:24 UTC (permalink / raw)
To: Mathias Nyman
Cc: Thinh Nguyen, linux-usb@vger.kernel.org,
stern@rowland.harvard.edu, michal.pecio@gmail.com,
oneukum@suse.com, niklas.neronin@linux.intel.com
In-Reply-To: <9cf4008e-2d12-4025-809a-8d9371f45dac@linux.intel.com>
On Thu, Mar 26, 2026, Mathias Nyman wrote:
> On 3/26/26 03:19, Thinh Nguyen wrote:
> > On Wed, Mar 25, 2026, Mathias Nyman wrote:
> > > On 3/25/26 03:52, Thinh Nguyen wrote:
> > > > On Mon, Mar 23, 2026, Mathias Nyman wrote:
> > > > > Avoid automatically restarting bulk or interrupt transfers after a
> > > > > URB is given back due to stall or error.
> > > > >
> > > > > Introduce a 'TD_TAINTED' state for pending TDs queued on a endpoint when
> > > > > it halted. The actual TD the endpoint halted on is marked TD_HALTED,
> > > > > and its URB is given back with proper EPROTO or EPIPE error code.
> > > > >
> > > > > Don't automatically restart an endpoint if the next queued TD after
> > > > > the TD_HALTED one is marked tainted.
> > > >
> > > > Sounds good for -EPROTO, but will a clear-halt ring the corresponding
> > > > the endpoint's doorbell for STALL endpoint?
> > > >
> > >
> > > With this change xhci would not restart the stalled endpoint after a clear-halt
> > > request. The first usb_enqueue() call after clear-halt would start it.
> > >
> > > Could make sense to restart the endpoint after a clear-halt, and just add a small
> > > debug message if the next queued URB is marked 'tainted'.
> > >
> >
> > The -EPROTO should be handled differently than -EPIPE. A STALL endpoint
> > is part of a normal usb flow. Should the class driver submit a new URB
> > while the endpoint is STALL, we would always expect a STALL error
> > response after the endpoint is restarted. That's not the case with
> > -EPROTO where the data may be corrupted and/or the host and device are
> > out of sync. We should not continue until the class driver do some
> > recovery. IMHO, we can keep the handling of -EPIPE how it was before.
> > Let the xHC tell whether the STALL error still persists instead of
> > managing it by the xhci driver.
> >
> I agree that that we should restart the endpoint if class/core enqueues a new
> URB _after_ xhci gave back an URB with EPIPE after endpoint STALL.
>
> But I don't think we should restart the ring to continue processing URBs that
> were queued before the endpoint stalled. This would prevent the class/core
> from even attempting to retire the pending URBs, something USB2.0 spec,
> '5.8.5 Bulk Transfer Data Sequences' requires:
>
> "If a halt condition is detected on a bulk pipe due to transmission errors or
> a STALL handshake being returned from the endpoint, all pending IRPs are
> retired. Removal of the halt condition is achieved via software intervention
> through a separate control pipe."
>
Fair point. Then the core will need to track the endpoint's STALL state
and parse the clear-halt request to know which endpoint and when to
clear the STALL before it can accept new URB. So the first usb_enqueue()
call after clear-halt can start the endpoint again. The xhci will also
need to have access to this state.
Currently you have the xhci driver to "retire" the halted URBs. However,
you also noted that class/core may attempt to retire the pending URBs.
Who's expected to handle the retirement here?
On a separate note, will you plan to implement the clear-halt for EPROTO
in xhci?
Thanks!
Thinh
^ permalink raw reply
* [Bug 215740] kernel warning: DMA-API: xhci_hcd: cacheline tracking EEXIST, overlapping mappings aren't supported
From: bugzilla-daemon @ 2026-03-26 19:46 UTC (permalink / raw)
To: linux-usb
In-Reply-To: <bug-215740-208809@https.bugzilla.kernel.org/>
https://bugzilla.kernel.org/show_bug.cgi?id=215740
Mikhail (mikhail.v.gavrilov@gmail.com) changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |mikhail.v.gavrilov@gmail.co
| |m
--- Comment #51 from Mikhail (mikhail.v.gavrilov@gmail.com) ---
Created attachment 309769
--> https://bugzilla.kernel.org/attachment.cgi?id=309769&action=edit
dma_cacheline_eexist_repro.mod.c
I hit this exact warning on 7.0-rc5 with an ASUS USB Audio device
(0b05:1a5c) on AMD B650E (ROG STRIX B650E-I) + xhci_hcd 0000:0c:00.0.
Same stack trace through snd_usb_ctl_msg -> usb_control_msg ->
usb_hcd_map_urb_for_dma -> dma_map_phys -> add_dma_entry -> EEXIST.
I tested Guenter's patch from comment #43 (ARCH_KMALLOC_MINALIGN =
L1_CACHE_BYTES when CONFIG_DMA_API_DEBUG) and can confirm it fixes
the issue.
I also wrote a kernel module reproducer that triggers the bug reliably
on demand, without needing to wait for a specific USB device to be
plugged in during boot. The module does exactly what hub_configure()
does: two kmalloc(8) allocations back-to-back, then DMA-maps both.
On x86_64 with ARCH_KMALLOC_MINALIGN=8, they land in the same
64-byte cacheline within ~50 attempts, triggering the EEXIST warning.
Before fix:
dma_repro: pair 53: buf_a=ffff8881c8f9eb80 buf_b=ffff8881c8f9eba0
-- SAME cacheline 119793582!
DMA-API: cacheline tracking EEXIST, overlapping mappings aren't
supported
After fix (ARCH_KMALLOC_MINALIGN >= L1_CACHE_BYTES):
dma_repro: no same-cacheline pair found in 64 attempts
(ARCH_KMALLOC_MINALIGN may already be >= cache_line_size)
I can submit a formal patch based on Guenter's fix if nobody objects.
Reproducer module source attached.
--
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 v2] usbip: tools: Add usbip host driver availability check
From: Shuah Khan @ 2026-03-26 18:43 UTC (permalink / raw)
To: Greg KH, Zongmin Zhou
Cc: i, linux-kernel, linux-usb, valentina.manea.m, Zongmin Zhou,
Shuah Khan
In-Reply-To: <2026032615-donated-chaps-9eac@gregkh>
On 3/26/26 02:43, Greg KH wrote:
> On Thu, Mar 26, 2026 at 11:10:02AM +0800, Zongmin Zhou wrote:
>>
>> On 2026/3/25 16:58, Greg KH wrote:
>>> On Wed, Mar 25, 2026 at 10:26:34AM +0800, Zongmin Zhou wrote:
>>>> From: Zongmin Zhou <zhouzongmin@kylinos.cn>
>>>>
>>>> Currently, usbip_generic_driver_open() doesn't verify that the required
>>>> kernel module (usbip-host or usbip-vudc) is actually loaded.
>>>> The function returns success even when no driver is present,
>>>> leading to usbipd daemon run success without driver loaded.
>>>>
>>>> So add a check function to ensure usbip host driver has been loaded.
>>>>
>>>> Suggested-by: Shuah Khan <skhan@linuxfoundation.org>
>>>> Signed-off-by: Zongmin Zhou <zhouzongmin@kylinos.cn>
>>>> ---
>>>> Changes in v2:
>>>> - Use system calls directly instead of checking sysfs dir.
>>>>
>>>> tools/usb/usbip/libsrc/usbip_device_driver.c | 7 +++++--
>>>> tools/usb/usbip/libsrc/usbip_host_driver.c | 8 ++++++--
>>>> 2 files changed, 11 insertions(+), 4 deletions(-)
>>>>
>>>> diff --git a/tools/usb/usbip/libsrc/usbip_device_driver.c b/tools/usb/usbip/libsrc/usbip_device_driver.c
>>>> index 927a151fa9aa..45ab647ef241 100644
>>>> --- a/tools/usb/usbip/libsrc/usbip_device_driver.c
>>>> +++ b/tools/usb/usbip/libsrc/usbip_device_driver.c
>>>> @@ -136,10 +136,13 @@ static int usbip_device_driver_open(struct usbip_host_driver *hdriver)
>>>> hdriver->ndevs = 0;
>>>> INIT_LIST_HEAD(&hdriver->edev_list);
>>>> - ret = usbip_generic_driver_open(hdriver);
>>>> - if (ret)
>>>> + if (system("/sbin/lsmod | grep -q usbip_vudc")){
>>> What happens if the module is built into the kernel?
>>>
>>>> err("please load " USBIP_CORE_MOD_NAME ".ko and "
>>>> USBIP_DEVICE_DRV_NAME ".ko!");
>>>> + return -1;
>>>> + }
>>>> +
>>>> + ret = usbip_generic_driver_open(hdriver);
>>>> return ret;
>>>> }
>>>> diff --git a/tools/usb/usbip/libsrc/usbip_host_driver.c b/tools/usb/usbip/libsrc/usbip_host_driver.c
>>>> index 573e73ec36bd..f0ac941d4f6e 100644
>>>> --- a/tools/usb/usbip/libsrc/usbip_host_driver.c
>>>> +++ b/tools/usb/usbip/libsrc/usbip_host_driver.c
>>>> @@ -31,10 +31,14 @@ static int usbip_host_driver_open(struct usbip_host_driver *hdriver)
>>>> hdriver->ndevs = 0;
>>>> INIT_LIST_HEAD(&hdriver->edev_list);
>>>> - ret = usbip_generic_driver_open(hdriver);
>>>> - if (ret)
>>>> + if (system("/sbin/lsmod | grep -q usbip_host")){
>>> Same here, what happens if it is built in?
>> Thank you for pointing this out.
>> I apologize for not considering the built-in module case.
>>
>> You are right that using lsmod | grep would incorrectly fail when usbip_host
>> is built into the kernel (CONFIG_USBIP_HOST=y).
>> Usbip has always been built as a loadable module (.ko) by default, which led
>> to this oversight.
>>
>> To address this issue, would the following approach be acceptable?
>
> Wait, what "issue" are you trying to fix here? Why can't you just check
> for opening the correct device node when the host opens the file and if
> that fails, report an error? Doesn't that happen today already?
>
The problem Zongmin is trying fix ish when usbipd starts, it looks for
exported if any - if it doesn't find any it assumes there aren't any
exported and doesn't detect that usbip_host driver isn't loaded.
refresh_exported_devices() doesn't have the logic and it shouldn't
include that logic because this hook is called periodically to
refresh the list of exported devices. Starting usbipd and loading
the driver are distinct steps and without any dependencies.
This patch he is trying to add that detection so a message can be printed
to say "load the driver".
A message can be added easily to cover two cases:
1. usbip_host driver isn't loaded
2. There are no exported devices.
refresh_exported_devices() will not find any devices in both
of the above scenarios. It isn't an error if it can't find
any exported devices.
An informational message when refresh_exported_devices()
when it doesn't find any devices could help users.
Zongmin,
Would adding a message that says
"Check if usbip_host driver is loaded or export devices"
solve the problem of hard to debug problem you are addressing here?
thanks,
-- Shuah
^ permalink raw reply
* Re: [PATCH 6/6] usbip: vhci_sysfs: Use safer strscpy() instead of strcpy()
From: Shuah Khan @ 2026-03-26 18:19 UTC (permalink / raw)
To: 艾超, gregkh
Cc: b-liu, johan, badhri, heikki.krogerus, valentina.manea.m, shuah,
i, tiwai, kees, christophe.jaillet, prashanth.k, khtsai, tglx,
mingo, linux-usb, linux-kernel, Shuah Khan, Dan Carpenter
In-Reply-To: <7990xi1aonqb-79968wxve9t0@nsmail8.2--kylin--1>
On 3/25/26 04:57, 艾超 wrote:
> Dear Shuah:
>
> Test Report for [usbip: vhci_sysfs: Use safer strscpy() instead of strcpy()]
> Environment:
> Kernel Version: v6.12.76+ (with patch applied)
> Hardware/QEMU: Thinkpad E15
> Conclusion:
> The longth of the name is MAX_STATUS_NAME+1 = 17, used the strcpy copy "status-abcdefghijklmnopqrstuvwxyz1234567890" in name and used strscpy copy "status-abcdefghi" in name.
> Tested-by: Aichao@kylinos.cn
>
Thank you for the report.
Acked-by: Shuah Khan <skhan@linuxfoundation.org>
Greg, Please pick this patch up.
thanks,
-- Shuah
^ permalink raw reply
* Re: [PATCH] usb: gadget: u_ether: Fix NULL pointer deref in eth_get_drvinfo
From: David Heidelberg @ 2026-03-26 16:37 UTC (permalink / raw)
To: Kuen-Han Tsai, Greg Kroah-Hartman
Cc: Val Packett, linux-usb, linux-kernel, stable
In-Reply-To: <20260316-eth-null-deref-v1-1-07005f33be85@google.com>
On 16/03/2026 08:49, Kuen-Han Tsai wrote:
> Commit ec35c1969650 ("usb: gadget: f_ncm: Fix net_device lifecycle with
> device_move") reparents the gadget device to /sys/devices/virtual during
> unbind, clearing the gadget pointer. If the userspace tool queries on
> the surviving interface during this detached window, this leads to a
> NULL pointer dereference.
>
> Unable to handle kernel NULL pointer dereference
> Call trace:
> eth_get_drvinfo+0x50/0x90
> ethtool_get_drvinfo+0x5c/0x1f0
> __dev_ethtool+0xaec/0x1fe0
> dev_ethtool+0x134/0x2e0
> dev_ioctl+0x338/0x560
>
> Add a NULL check for dev->gadget in eth_get_drvinfo(). When detached,
> skip copying the fw_version and bus_info strings, which is natively
> handled by ethtool_get_drvinfo for empty strings.
>
> Suggested-by: Val Packett <val@packett.cool>
> Reported-by: Val Packett <val@packett.cool>
> Closes: https://lore.kernel.org/linux-usb/10890524-cf83-4a71-b879-93e2b2cc1fcc@packett.cool/
> Fixes: ec35c1969650 ("usb: gadget: f_ncm: Fix net_device lifecycle with device_move")
> Cc: stable@vger.kernel.org
> Signed-off-by: Kuen-Han Tsai <khtsai@google.com>
> ---
Works for us in sdm845-next too,
Tested-by: David Heidelberg <david@ixit.cz>
--
David Heidelberg
^ permalink raw reply
* Re: [PATCH] usb: gadget: u_ether: Fix NULL pointer deref in eth_get_drvinfo
From: Aelin Reidel @ 2026-03-26 15:24 UTC (permalink / raw)
To: Kuen-Han Tsai, Greg Kroah-Hartman
Cc: David Heidelberg, Val Packett, linux-usb, linux-kernel, stable
In-Reply-To: <20260316-eth-null-deref-v1-1-07005f33be85@google.com>
On 3/16/26 8:49 AM, Kuen-Han Tsai wrote:
> Commit ec35c1969650 ("usb: gadget: f_ncm: Fix net_device lifecycle with
> device_move") reparents the gadget device to /sys/devices/virtual during
> unbind, clearing the gadget pointer. If the userspace tool queries on
> the surviving interface during this detached window, this leads to a
> NULL pointer dereference.
>
> Unable to handle kernel NULL pointer dereference
> Call trace:
> eth_get_drvinfo+0x50/0x90
> ethtool_get_drvinfo+0x5c/0x1f0
> __dev_ethtool+0xaec/0x1fe0
> dev_ethtool+0x134/0x2e0
> dev_ioctl+0x338/0x560
>
> Add a NULL check for dev->gadget in eth_get_drvinfo(). When detached,
> skip copying the fw_version and bus_info strings, which is natively
> handled by ethtool_get_drvinfo for empty strings.
>
> Suggested-by: Val Packett <val@packett.cool>
> Reported-by: Val Packett <val@packett.cool>
> Closes: https://lore.kernel.org/linux-usb/10890524-cf83-4a71-b879-93e2b2cc1fcc@packett.cool/
> Fixes: ec35c1969650 ("usb: gadget: f_ncm: Fix net_device lifecycle with device_move")
> Cc: stable@vger.kernel.org
> Signed-off-by: Kuen-Han Tsai <khtsai@google.com>
> ---
> drivers/usb/gadget/function/u_ether.c | 6 ++++--
> 1 file changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/usb/gadget/function/u_ether.c b/drivers/usb/gadget/function/u_ether.c
> index 1a9e7c495e2e..a653fae9c0cb 100644
> --- a/drivers/usb/gadget/function/u_ether.c
> +++ b/drivers/usb/gadget/function/u_ether.c
> @@ -113,8 +113,10 @@ static void eth_get_drvinfo(struct net_device *net, struct ethtool_drvinfo *p)
>
> strscpy(p->driver, "g_ether", sizeof(p->driver));
> strscpy(p->version, UETH__VERSION, sizeof(p->version));
> - strscpy(p->fw_version, dev->gadget->name, sizeof(p->fw_version));
> - strscpy(p->bus_info, dev_name(&dev->gadget->dev), sizeof(p->bus_info));
> + if (dev->gadget) {
> + strscpy(p->fw_version, dev->gadget->name, sizeof(p->fw_version));
> + strscpy(p->bus_info, dev_name(&dev->gadget->dev), sizeof(p->bus_info));
> + }
> }
>
> /* REVISIT can also support:
>
> ---
> base-commit: d0d9b1f4f5391e6a00cee81d73ed2e8f98446d5f
> change-id: 20260316-eth-null-deref-0304bb048267
>
> Best regards,
Thank you for the patch! This does fix the null pointer dereference for me.
Tested-by: Aelin Reidel <aelin@mainlining.org>
^ permalink raw reply
* Re: [PATCH v2 1/2] dt-bindings: usb: Add support for Terminus FE1.1s USB2.0 Hub controller
From: Rob Herring (Arm) @ 2026-03-26 15:26 UTC (permalink / raw)
To: Yixun Lan
Cc: linux-kernel, Inochi Amaoto, Greg Kroah-Hartman, spacemit,
Krzysztof Kozlowski, Conor Dooley, linux-usb, Matthias Kaehlcke,
devicetree, Junzhong Pan
In-Reply-To: <20260319-03-usb-hub-fe1-v2-1-e4e26809dd7d@kernel.org>
On Thu, 19 Mar 2026 07:51:03 +0000, Yixun Lan wrote:
> Terminus FE1.1s is USB2.0 protocol compliant 4-port USB HUB, It support
> MTT (Multiple Transaction Translator) mode, the upstream port supports
> high-speed 480MHz and full-speed 12MHz modes, also has integrated 5V to
> 3.3V, 1.8V regulator and Power-On-Reset circuit.
>
> Introduce the DT binding for it.
>
> Link: https://terminus-usa.com/wp-content/uploads/2024/06/FE1.1s-Product-Brief-Rev.-2.0-2023.pdf [1]
> Signed-off-by: Yixun Lan <dlan@kernel.org>
> ---
> .../devicetree/bindings/usb/terminus,fe11.yaml | 62 ++++++++++++++++++++++
> 1 file changed, 62 insertions(+)
>
Reviewed-by: Rob Herring (Arm) <robh@kernel.org>
^ permalink raw reply
* Re [PATCH v3 0/2] usb: offload: Decouple interrupter lifecycle and refactor usage tracking
From: hailong @ 2026-03-26 14:48 UTC (permalink / raw)
To: guanyulin
Cc: amardeep.rai, andriy.shevchenko, arnd, broonie, eadavis, gregkh,
hannelotta, linux-kernel, linux-sound, linux-usb, mathias.nyman,
nkapron, perex, quic_wcheng, sakari.ailus, stern, tiwai,
wesley.cheng, xiaopei01, xu.yang_2, hailong.liu
In-Reply-To: <20260324203851.4091193-1-guanyulin@google.com>
Hi,
We, OPPO kernel team, have thoroughly verified this patch on our devices.
The test results confirm that it effectively resolves a critical headset
hot-plugging issue and the subsequent system deadlock.
Impact:
This issue is currently a blocker for our upcoming product shipping.
We have observed a high reproduction rate on our latest platforms,
and this patch is essential for our production stability.
Test Environment:
Devices: OPPO devices based on SM8850 and SM8845 platforms.
OS/Kernel: Android 16.0 / Linux Kernel 6.12.
Background:
High reproduction rate (typically within 10 cycles) before
applying this patch.
Original Reproduction Path (Verified fixed):
Open music player and enable USB exclusive mode.
Connect a Type-C digital headset and start playback.
Repeatedly plug/unplug the headset.
Observation:
Within 10 cycles, the headset icon would persist after
unplugging, followed by no audio upon reconnection and a system deadlock.
Stress Test Results with This Patch (Phone A & B):
Test Case 1: USB Exclusive Mode Hot-plug
Steps: Enable USB exclusive mode -> Play music -> Plug/unplug 100 cycles.
Result: PASS. Audio functions normally; no deadlock observed.
Test Case 2: Standard Mode Hot-plug
Steps: Disable USB exclusive mode -> Play music -> Plug/unplug 100 cycles.
Result: PASS. Audio and system stability remain normal.
Test Case 3: Mixed Accessory Switching (Headset/Charger)
Steps: Play music -> Unplug headset -> Plug in charger -> Unplug charger
-> Re-plug headset. Repeated for 30 cycles.
Result: PASS. No issues observed.
The patch looks solid and is critical for our project. We hope these
results help expedite the upstreaming process.
Free to add
Tested-by: hailong.liu@oppo.com
^ permalink raw reply
* [PATCH] USB: cdc-acm: Add support for second ACM channel on more Nokia phones
From: Рыжов Фёдор @ 2026-03-26 14:37 UTC (permalink / raw)
To: linux-kernel@vger.kernel.org
Cc: Oliver Neukum, gregkh@linuxfoundation.org,
linux-usb@vger.kernel.org, linux-kernel@vger.kernel.org
On Nokia Series60 phones, second ACM channel is used by phone
applications to communicate with PC. It reports "vendor-specific
protocol" so kernel does not expose it as tty by default.
This patch extends the whitelist with all S60v3.x and S60v5.x phones,
supported by official "Nokia PC Suite" driver for Windows. Device IDs
are taken from its installation configuration file. Older S60v2.x and
S60v1.x devices were not added because I have no hardware to test.
Signed-off-by: Ansel Hayashi <symansel@outlook.com>
---
drivers/usb/class/cdc-acm.c | 77 ++++++++++++++++++++++++++++++++++++-
1 file changed, 76 insertions(+), 1 deletion(-)
diff --git a/drivers/usb/class/cdc-acm.c b/drivers/usb/class/cdc-acm.c
index 7ede29d4c7c1..5f72fe972ec8 100644
--- a/drivers/usb/class/cdc-acm.c
+++ b/drivers/usb/class/cdc-acm.c
@@ -1870,7 +1870,9 @@ static const struct usb_device_id acm_ids[] = {
* information below. The second is 'vendor-specific' but
* is treated as a serial device at the S60 end, so we want
* to expose it on Linux too. */
+ { NOKIA_PCSUITE_ACM_INFO(0x0421), }, /* Nokia 3230 */
{ NOKIA_PCSUITE_ACM_INFO(0x042D), }, /* Nokia 3250 */
+ { NOKIA_PCSUITE_ACM_INFO(0x043F), }, /* Nokia 5500 Sport */
{ NOKIA_PCSUITE_ACM_INFO(0x04D8), }, /* Nokia 5500 Sport */
{ NOKIA_PCSUITE_ACM_INFO(0x04C9), }, /* Nokia E50 */
{ NOKIA_PCSUITE_ACM_INFO(0x0419), }, /* Nokia E60 */
@@ -1891,12 +1893,28 @@ static const struct usb_device_id acm_ids[] = {
{ NOKIA_PCSUITE_ACM_INFO(0x04B2), }, /* Nokia 5700 XpressMusic */
{ NOKIA_PCSUITE_ACM_INFO(0x0134), }, /* Nokia 6110 Navigator (China) */
{ NOKIA_PCSUITE_ACM_INFO(0x046E), }, /* Nokia 6110 Navigator */
- { NOKIA_PCSUITE_ACM_INFO(0x002f), }, /* Nokia 6120 classic & */
+ { NOKIA_PCSUITE_ACM_INFO(0x002f), }, /* Nokia 6120 classic */
{ NOKIA_PCSUITE_ACM_INFO(0x0088), }, /* Nokia 6121 classic */
{ NOKIA_PCSUITE_ACM_INFO(0x00fc), }, /* Nokia 6124 classic */
+ { NOKIA_PCSUITE_ACM_INFO(0x0288), }, /* Nokia 6720 classic */
+ { NOKIA_PCSUITE_ACM_INFO(0x011D), }, /* Nokia 6720 classic */
+ { NOKIA_PCSUITE_ACM_INFO(0x023D), }, /* Nokia 6730 classic */
+ { NOKIA_PCSUITE_ACM_INFO(0x01B6), }, /* Nokia 6790 Surge */
+ { NOKIA_PCSUITE_ACM_INFO(0x0057), }, /* FOMA NM705i */
+ { NOKIA_PCSUITE_ACM_INFO(0x0168), }, /* FOMA NM706i */
+ { NOKIA_PCSUITE_ACM_INFO(0x04A1), }, /* Nokia 6290 */
+ { NOKIA_PCSUITE_ACM_INFO(0x04A5), }, /* Nokia 6290 */
+ { NOKIA_PCSUITE_ACM_INFO(0x03C5), }, /* Nokia 5250 */
+ { NOKIA_PCSUITE_ACM_INFO(0x057B), }, /* Nokia 5230 */
+ { NOKIA_PCSUITE_ACM_INFO(0x0388), }, /* Nokia 5232 */
+ { NOKIA_PCSUITE_ACM_INFO(0x057F), }, /* Nokia 5232 */
+ { NOKIA_PCSUITE_ACM_INFO(0x0348), }, /* Nokia 5233 */
+ { NOKIA_PCSUITE_ACM_INFO(0x03BE), }, /* Nokia 5235 */
+ { NOKIA_PCSUITE_ACM_INFO(0x02A1), }, /* Nokia 6788i */
{ NOKIA_PCSUITE_ACM_INFO(0x0042), }, /* Nokia E51 */
{ NOKIA_PCSUITE_ACM_INFO(0x00b0), }, /* Nokia E66 */
{ NOKIA_PCSUITE_ACM_INFO(0x00ab), }, /* Nokia E71 */
+ { NOKIA_PCSUITE_ACM_INFO(0x01A2), }, /* Nokia E71 */
{ NOKIA_PCSUITE_ACM_INFO(0x0481), }, /* Nokia N76 */
{ NOKIA_PCSUITE_ACM_INFO(0x0007), }, /* Nokia N81 & N81 8GB */
{ NOKIA_PCSUITE_ACM_INFO(0x0071), }, /* Nokia N82 */
@@ -1904,28 +1922,85 @@ static const struct usb_device_id acm_ids[] = {
{ NOKIA_PCSUITE_ACM_INFO(0x0070), }, /* Nokia N95 8GB */
{ NOKIA_PCSUITE_ACM_INFO(0x0099), }, /* Nokia 6210 Navigator, RM-367 */
{ NOKIA_PCSUITE_ACM_INFO(0x0128), }, /* Nokia 6210 Navigator, RM-419 */
+ { NOKIA_PCSUITE_ACM_INFO(0x012C), }, /* Nokia 6210 Navigator */
{ NOKIA_PCSUITE_ACM_INFO(0x008f), }, /* Nokia 6220 Classic */
+ { NOKIA_PCSUITE_ACM_INFO(0x0124), }, /* Nokia 6220 Classic */
{ NOKIA_PCSUITE_ACM_INFO(0x00a0), }, /* Nokia 6650 */
+ { NOKIA_PCSUITE_ACM_INFO(0x0294), }, /* Nokia 6650 Fold */
+ { NOKIA_PCSUITE_ACM_INFO(0x01CC), }, /* Nokia 6710 Navigator */
+ { NOKIA_PCSUITE_ACM_INFO(0x029A), }, /* Nokia 6710 Navigator */
{ NOKIA_PCSUITE_ACM_INFO(0x007b), }, /* Nokia N78 */
{ NOKIA_PCSUITE_ACM_INFO(0x0094), }, /* Nokia N85 */
{ NOKIA_PCSUITE_ACM_INFO(0x003a), }, /* Nokia N96 & N96-3 */
{ NOKIA_PCSUITE_ACM_INFO(0x00e9), }, /* Nokia 5320 XpressMusic */
+ { NOKIA_PCSUITE_ACM_INFO(0x010C), }, /* Nokia 5320 XpressMusic */
{ NOKIA_PCSUITE_ACM_INFO(0x0108), }, /* Nokia 5320 XpressMusic 2G */
{ NOKIA_PCSUITE_ACM_INFO(0x01f5), }, /* Nokia N97, RM-505 */
{ NOKIA_PCSUITE_ACM_INFO(0x02e3), }, /* Nokia 5230, RM-588 */
+ { NOKIA_PCSUITE_ACM_INFO(0x02e7), }, /* Nokia 5230 */
+ { NOKIA_PCSUITE_ACM_INFO(0x034C), }, /* Nokia 5230 */
+ { NOKIA_PCSUITE_ACM_INFO(0x0325), }, /* Nokia 5230 Nuron */
{ NOKIA_PCSUITE_ACM_INFO(0x0178), }, /* Nokia E63 */
{ NOKIA_PCSUITE_ACM_INFO(0x010e), }, /* Nokia E75 */
{ NOKIA_PCSUITE_ACM_INFO(0x02d9), }, /* Nokia 6760 Slide */
{ NOKIA_PCSUITE_ACM_INFO(0x01d0), }, /* Nokia E52 */
{ NOKIA_PCSUITE_ACM_INFO(0x0223), }, /* Nokia E72 */
+ { NOKIA_PCSUITE_ACM_INFO(0x0374), }, /* Nokia E73 */
{ NOKIA_PCSUITE_ACM_INFO(0x0275), }, /* Nokia X6 */
+ { NOKIA_PCSUITE_ACM_INFO(0x0279), }, /* Nokia X6 */
+ { NOKIA_PCSUITE_ACM_INFO(0x027D), }, /* Nokia X6 */
{ NOKIA_PCSUITE_ACM_INFO(0x026c), }, /* Nokia N97 Mini */
{ NOKIA_PCSUITE_ACM_INFO(0x0154), }, /* Nokia 5800 XpressMusic */
+ { NOKIA_PCSUITE_ACM_INFO(0x0138), }, /* Nokia 5800 XpressMusic */
+ { NOKIA_PCSUITE_ACM_INFO(0x0158), }, /* Nokia 5800 XpressMusic */
+ { NOKIA_PCSUITE_ACM_INFO(0x02F6), }, /* Nokia 5800 XpressMusic */
+ { NOKIA_PCSUITE_ACM_INFO(0x02E9), }, /* Nokia 5802 XpressMusic */
+ { NOKIA_PCSUITE_ACM_INFO(0x022A), }, /* Nokia 5530 XpressMusic */
+ { NOKIA_PCSUITE_ACM_INFO(0x011C), }, /* Nokia 5630 XpressMusic */
+ { NOKIA_PCSUITE_ACM_INFO(0x01A9), }, /* Nokia 5730 XpressMusic */
+ { NOKIA_PCSUITE_ACM_INFO(0x014B), }, /* Nokia 5730 XpressMusic */
{ NOKIA_PCSUITE_ACM_INFO(0x04ce), }, /* Nokia E90 */
{ NOKIA_PCSUITE_ACM_INFO(0x01d4), }, /* Nokia E55 */
{ NOKIA_PCSUITE_ACM_INFO(0x0302), }, /* Nokia N8 */
{ NOKIA_PCSUITE_ACM_INFO(0x0335), }, /* Nokia E7 */
{ NOKIA_PCSUITE_ACM_INFO(0x03cd), }, /* Nokia C7 */
+ { NOKIA_PCSUITE_ACM_INFO(0x05AB), }, /* Nokia X7 */
+ { NOKIA_PCSUITE_ACM_INFO(0x03B1), }, /* Nokia T7 */
+ { NOKIA_PCSUITE_ACM_INFO(0x058E), }, /* Nokia Oro */
+ { NOKIA_PCSUITE_ACM_INFO(0x0187), }, /* Nokia N79 */
+ { NOKIA_PCSUITE_ACM_INFO(0x0216), }, /* Nokia N86 */
+ { NOKIA_PCSUITE_ACM_INFO(0x0380), }, /* Nokia E5-00 */
+ { NOKIA_PCSUITE_ACM_INFO(0x038B), }, /* Nokia E5-00 */
+ { NOKIA_PCSUITE_ACM_INFO(0x038F), }, /* Nokia E5-00 */
+ { NOKIA_PCSUITE_ACM_INFO(0x0565), }, /* Nokia E5-00 */
+ { NOKIA_PCSUITE_ACM_INFO(0x0569), }, /* Nokia E5-00 */
+ { NOKIA_PCSUITE_ACM_INFO(0x05DD), }, /* Nokia C5-00 */
+ { NOKIA_PCSUITE_ACM_INFO(0x0592), }, /* Nokia C5-00 */
+ { NOKIA_PCSUITE_ACM_INFO(0x0596), }, /* Nokia C5-00 */
+ { NOKIA_PCSUITE_ACM_INFO(0x03F3), }, /* Nokia C5-00 */
+ { NOKIA_PCSUITE_ACM_INFO(0x03A7), }, /* Nokia C5-00 */
+ { NOKIA_PCSUITE_ACM_INFO(0x03B4), }, /* Nokia C5-01 */
+ { NOKIA_PCSUITE_ACM_INFO(0x03E6), }, /* Nokia C5-03 */
+ { NOKIA_PCSUITE_ACM_INFO(0x051D), }, /* Nokia C5-03 */
+ { NOKIA_PCSUITE_ACM_INFO(0x0520), }, /* Nokia C5-04 */
+ { NOKIA_PCSUITE_ACM_INFO(0x05E1), }, /* Nokia C5-05 */
+ { NOKIA_PCSUITE_ACM_INFO(0x05E5), }, /* Nokia C5-06 */
+ { NOKIA_PCSUITE_ACM_INFO(0x0312), }, /* Nokia C6-01 */
+ { NOKIA_PCSUITE_ACM_INFO(0x03B8), }, /* Nokia X5-00 */
+ { NOKIA_PCSUITE_ACM_INFO(0x0378), }, /* Nokia X5-01 */
+ { NOKIA_PCSUITE_ACM_INFO(0x0432), }, /* Nokia N90 */
+ { NOKIA_PCSUITE_ACM_INFO(0x0472), }, /* Nokia E70 */
+ { NOKIA_PCSUITE_ACM_INFO(0x02FB), }, /* Nokia E63 */
+ { NOKIA_PCSUITE_ACM_INFO(0x032B), }, /* Nokia C6-00 */
+ { NOKIA_PCSUITE_ACM_INFO(0x032F), }, /* Nokia E6-00 */
+ { NOKIA_PCSUITE_ACM_INFO(0x05C0), }, /* Nokia 500 */
+ { NOKIA_PCSUITE_ACM_INFO(0x03F5), }, /* Nokia 600 */
+ { NOKIA_PCSUITE_ACM_INFO(0x05B3), }, /* Nokia 603 */
+ { NOKIA_PCSUITE_ACM_INFO(0x02DF), }, /* Nokia 700 */
+ { NOKIA_PCSUITE_ACM_INFO(0x05A0), }, /* Nokia 701 */
+ { NOKIA_PCSUITE_ACM_INFO(0x0538), }, /* Nokia 702T */
+ { NOKIA_PCSUITE_ACM_INFO(0x0574), }, /* Nokia 801T */
+ { NOKIA_PCSUITE_ACM_INFO(0x05D1), }, /* Nokia 808 */
{ SAMSUNG_PCSUITE_ACM_INFO(0x6651), }, /* Samsung GTi8510 (INNOV8) */
/* Support for Owen devices */
--
2.53.0
^ permalink raw reply related
* Re: [PATCH v2 2/6] usb: xhci: tegra: Remove redundant mutex when setting phy mode
From: Diogo Ivo @ 2026-03-26 14:17 UTC (permalink / raw)
To: Thierry Reding
Cc: Mathias Nyman, Greg Kroah-Hartman, Thierry Reding,
Jonathan Hunter, JC Kuo, Vinod Koul, Kishon Vijay Abraham I,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Neil Armstrong,
linux-usb, linux-tegra, linux-kernel, linux-phy, devicetree
In-Reply-To: <acJ50sQraVmy4zXs@orome>
Hello,
On 3/24/26 11:48, Thierry Reding wrote:
> On Tue, Jan 27, 2026 at 03:11:48PM +0000, Diogo Ivo wrote:
>> As the PHY subsystem already synchronizes concurrent accesses to a PHY
>> instance with a core-internal mutex remove the driver specific mutex
>> synchronization.
>>
>> Signed-off-by: Diogo Ivo <diogo.ivo@tecnico.ulisboa.pt>
>> ---
>> v1->v2:
>> - New patch
>> ---
>> drivers/usb/host/xhci-tegra.c | 4 ----
>> 1 file changed, 4 deletions(-)
>>
>> diff --git a/drivers/usb/host/xhci-tegra.c b/drivers/usb/host/xhci-tegra.c
>> index 8b492871d21d..927861ca14f2 100644
>> --- a/drivers/usb/host/xhci-tegra.c
>> +++ b/drivers/usb/host/xhci-tegra.c
>> @@ -1357,15 +1357,11 @@ static void tegra_xhci_id_work(struct work_struct *work)
>>
>> dev_dbg(tegra->dev, "host mode %s\n", str_on_off(tegra->host_mode));
>>
>> - mutex_lock(&tegra->lock);
>> -
>> if (tegra->host_mode)
>> phy_set_mode_ext(phy, PHY_MODE_USB_OTG, USB_ROLE_HOST);
>> else
>> phy_set_mode_ext(phy, PHY_MODE_USB_OTG, USB_ROLE_NONE);
>>
>> - mutex_unlock(&tegra->lock);
>> -
>
> It looks to me like the mutex here is trying to protect against
> tegra->host_mode changing while we're setting a different mode. That
> doesn't seem to be taken care of by the PHY internal mutex.
After taking another look at it I think I understand your point for the
mutex, but in that case wouldn't it also need to be held in the writer
of host_mode, tegra_xhci_id_notify()?
This patch has been picked up as-is into usb-next so it would be nice to
figure this out before it gets merged in the next merge window.
Diogo
> Thierry
^ permalink raw reply
* RE: [PATCH net-next v4 3/3] r8152: add helper functions for PHY OCP registers
From: Hayes Wang @ 2026-03-26 13:19 UTC (permalink / raw)
To: Chih Kai Hsu, kuba@kernel.org, davem@davemloft.net
Cc: netdev@vger.kernel.org, nic_swsd, linux-kernel@vger.kernel.org,
linux-usb@vger.kernel.org, edumazet@google.com, bjorn@mork.no,
pabeni@redhat.com, Chih Kai Hsu
In-Reply-To: <20260326073925.32976-456-nic_swsd@realtek.com>
Chih Kai Hsu <hsu.chih.kai@realtek.com>
> Sent: Thursday, March 26, 2026 3:39 PM
> To: kuba@kernel.org; davem@davemloft.net
> Cc: netdev@vger.kernel.org; nic_swsd <nic_swsd@realtek.com>;
> linux-kernel@vger.kernel.org; linux-usb@vger.kernel.org;
> edumazet@google.com; bjorn@mork.no; pabeni@redhat.com; Chih Kai Hsu
> <hsu.chih.kai@realtek.com>
> Subject: [PATCH net-next v4 3/3] r8152: add helper functions for PHY OCP
> registers
>
> Add the following bitwise operation functions for PHY OCP registers to simplify
> the code.
>
> - ocp_reg_w0w1()
> - ocp_reg_clr_bits()
> - ocp_reg_set_bits()
> - sram_write_w0w1()
> - sram_clr_bits()
> - sram_set_bits()
> - r8152_mdio_clr_bit()
> - r8152_mdio_set_bit()
> - r8152_mdio_test_and_clr_bit()
>
> In addition, remove variable set but not used from r8153_init(),
> r8153b_init() and r8153c_init().
>
> Signed-off-by: Chih Kai Hsu <hsu.chih.kai@realtek.com>
Reviewed-by: Hayes Wang <hayeswang@realtek.com>
Best Regards,
Hayes
^ permalink raw reply
* RE: [PATCH net-next v4 2/3] r8152: add helper functions for PLA/USB OCP registers
From: Hayes Wang @ 2026-03-26 13:19 UTC (permalink / raw)
To: Chih Kai Hsu, kuba@kernel.org, davem@davemloft.net
Cc: netdev@vger.kernel.org, nic_swsd, linux-kernel@vger.kernel.org,
linux-usb@vger.kernel.org, edumazet@google.com, bjorn@mork.no,
pabeni@redhat.com, Chih Kai Hsu
In-Reply-To: <20260326073925.32976-455-nic_swsd@realtek.com>
Chih Kai Hsu <hsu.chih.kai@realtek.com>
> Sent: Thursday, March 26, 2026 3:39 PM
> To: kuba@kernel.org; davem@davemloft.net
> Cc: netdev@vger.kernel.org; nic_swsd <nic_swsd@realtek.com>;
> linux-kernel@vger.kernel.org; linux-usb@vger.kernel.org;
> edumazet@google.com; bjorn@mork.no; pabeni@redhat.com; Chih Kai Hsu
> <hsu.chih.kai@realtek.com>
> Subject: [PATCH net-next v4 2/3] r8152: add helper functions for PLA/USB OCP
> registers
>
> Add the following bitwise operation functions for PLA/USB OCP registers
> to simplify the code.
>
> - ocp_dword_w0w1()
> - ocp_word_w0w1()
> - ocp_byte_w0w1()
> - ocp_dword_clr_bits()
> - ocp_dword_set_bits()
> - ocp_word_clr_bits()
> - ocp_word_set_bits()
> - ocp_word_test_and_clr_bits()
> - ocp_byte_clr_bits()
> - ocp_byte_set_bits()
>
> Signed-off-by: Chih Kai Hsu <hsu.chih.kai@realtek.com>
Reviewed-by: Hayes Wang <hayeswang@realtek.com>
Best Regards,
Hayes
^ permalink raw reply
* [PATCH net v3 04/11] list: Move on_list_rcu() to list.h and add on_list() also
From: David Howells @ 2026-03-26 13:18 UTC (permalink / raw)
To: netdev
Cc: David Howells, Marc Dionne, Jakub Kicinski, David S. Miller,
Eric Dumazet, Paolo Abeni, linux-afs, linux-kernel,
Mathieu Desnoyers, John Johansen, Minas Harutyunyan, Simon Horman,
apparmor, linux-usb, stable
In-Reply-To: <20260326131838.634095-1-dhowells@redhat.com>
Unfortunately, list_empty() is not usable with an entry that has been
removed from a list with list_del_rcu() as ->next must be left pointing at
the following entry so as not to break traversal under RCU.
Solve this by moving on_list_rcu() from AppArmor to linux/list.h, and
turning it into an inline function.
Also add an on_list() counterpart (functionally, this is just an antonym
for list_empty()), but the name looks less awkward when applied to a
non-head element. We probably don't want to use on_list_rcu() generally
because it requires an extra check as ->prev is set differently in the two
cases.
Further, rename the on_list() function in the Designware usb2 drd ip driver
to dwc2_on_list() to free up the original name.
Signed-off-by: David Howells <dhowells@redhat.com>
cc: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
cc: John Johansen <john.johansen@canonical.com>
cc: Minas Harutyunyan <hminas@synopsys.com>
cc: Marc Dionne <marc.dionne@auristor.com>
cc: Eric Dumazet <edumazet@google.com>
cc: "David S. Miller" <davem@davemloft.net>
cc: Jakub Kicinski <kuba@kernel.org>
cc: Paolo Abeni <pabeni@redhat.com>
cc: Simon Horman <horms@kernel.org>
cc: linux-afs@lists.infradead.org
cc: apparmor@lists.ubuntu.com
cc: linux-usb@vger.kernel.org
cc: netdev@vger.kernel.org
cc: stable@kernel.org
---
drivers/usb/dwc2/gadget.c | 6 +++---
include/linux/list.h | 26 ++++++++++++++++++++++++++
security/apparmor/include/policy.h | 2 --
3 files changed, 29 insertions(+), 5 deletions(-)
diff --git a/drivers/usb/dwc2/gadget.c b/drivers/usb/dwc2/gadget.c
index d216e26c787b..04b6aef8ac13 100644
--- a/drivers/usb/dwc2/gadget.c
+++ b/drivers/usb/dwc2/gadget.c
@@ -4306,11 +4306,11 @@ static int dwc2_hsotg_ep_disable_lock(struct usb_ep *ep)
}
/**
- * on_list - check request is on the given endpoint
+ * dwc2_on_list - check request is on the given endpoint
* @ep: The endpoint to check.
* @test: The request to test if it is on the endpoint.
*/
-static bool on_list(struct dwc2_hsotg_ep *ep, struct dwc2_hsotg_req *test)
+static bool dwc2_on_list(struct dwc2_hsotg_ep *ep, struct dwc2_hsotg_req *test)
{
struct dwc2_hsotg_req *req, *treq;
@@ -4338,7 +4338,7 @@ static int dwc2_hsotg_ep_dequeue(struct usb_ep *ep, struct usb_request *req)
spin_lock_irqsave(&hs->lock, flags);
- if (!on_list(hs_ep, hs_req)) {
+ if (!dwc2_on_list(hs_ep, hs_req)) {
spin_unlock_irqrestore(&hs->lock, flags);
return -EINVAL;
}
diff --git a/include/linux/list.h b/include/linux/list.h
index 00ea8e5fb88b..d224e7210d1b 100644
--- a/include/linux/list.h
+++ b/include/linux/list.h
@@ -381,6 +381,32 @@ static inline int list_empty(const struct list_head *head)
return READ_ONCE(head->next) == head;
}
+/**
+ * on_list - Test whether an entry is on a list.
+ * @entry: The entry to check
+ *
+ * Test whether an entry is on a list. Safe to use on an entry initialised
+ * with INIT_LIST_HEAD() or LIST_HEAD() or removed with things like
+ * list_del_init(). Not safe for use with list_del() or list_del_rcu().
+ */
+static inline bool on_list(const struct list_head *entry)
+{
+ return !list_empty(entry);
+}
+
+/**
+ * on_list_rcu - Test whether an entry is on a list (RCU-del safe).
+ * @entry: The entry to check
+ *
+ * Test whether an entry is on a list. Safe to use on an entry initialised
+ * with INIT_LIST_HEAD() or LIST_HEAD() or removed with things like
+ * list_del_init(). Also safe for use with list_del() or list_del_rcu().
+ */
+static inline bool on_list_rcu(const struct list_head *entry)
+{
+ return !list_empty(entry) && entry->prev != LIST_POISON2;
+}
+
/**
* list_del_init_careful - deletes entry from list and reinitialize it.
* @entry: the element to delete from the list.
diff --git a/security/apparmor/include/policy.h b/security/apparmor/include/policy.h
index 3895f8774a3f..c3697c23bbed 100644
--- a/security/apparmor/include/policy.h
+++ b/security/apparmor/include/policy.h
@@ -57,8 +57,6 @@ extern const char *const aa_profile_mode_names[];
#define profile_is_stale(_profile) (label_is_stale(&(_profile)->label))
-#define on_list_rcu(X) (!list_empty(X) && (X)->prev != LIST_POISON2)
-
/* flags in the dfa accept2 table */
enum dfa_accept_flags {
ACCEPT_FLAG_OWNER = 1,
^ permalink raw reply related
* RE: [PATCH net-next v4 1/3] r8152: fix incorrect register write to USB_UPHY_XTAL
From: Hayes Wang @ 2026-03-26 13:18 UTC (permalink / raw)
To: Chih Kai Hsu, kuba@kernel.org, davem@davemloft.net
Cc: netdev@vger.kernel.org, nic_swsd, linux-kernel@vger.kernel.org,
linux-usb@vger.kernel.org, edumazet@google.com, bjorn@mork.no,
pabeni@redhat.com, Chih Kai Hsu
In-Reply-To: <20260326073925.32976-454-nic_swsd@realtek.com>
Chih Kai Hsu <hsu.chih.kai@realtek.com>
> Sent: Thursday, March 26, 2026 3:39 PM
> To: kuba@kernel.org; davem@davemloft.net
> Cc: netdev@vger.kernel.org; nic_swsd <nic_swsd@realtek.com>;
> linux-kernel@vger.kernel.org; linux-usb@vger.kernel.org;
> edumazet@google.com; bjorn@mork.no; pabeni@redhat.com; Chih Kai Hsu
> <hsu.chih.kai@realtek.com>
> Subject: [PATCH net-next v4 1/3] r8152: fix incorrect register write to
> USB_UPHY_XTAL
>
> The old code used ocp_write_byte() to clear the OOBS_POLLING bit
> (BIT(8)) in the USB_UPHY_XTAL register, but this doesn't correctly clear a bit in
> the upper byte of the 16-bit register.
>
> Fix this by using ocp_write_word() instead.
>
> Fixes: 195aae321c82 ("r8152: support new chips")
> Signed-off-by: Chih Kai Hsu <hsu.chih.kai@realtek.com>
Reviewed-by: Hayes Wang <hayeswang@realtek.com>
Best Regards,
Hayes
^ 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