* Re: [PATCH] usb: typec: altmode: Fix altmode to handle multiple parners
From: François Scala @ 2026-04-02 18:10 UTC (permalink / raw)
To: Heikki Krogerus; +Cc: linux-usb
In-Reply-To: <ac5uh_3N3q61efIb@kuha>
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
> Then provide the trace output from the ucsi driver, dmesg output
> (full), and also acpidump of your system. The ucsi trace you can
> get like this (assuming you have the debugfs mounted at
> /sys/kernel/debug):
>
> cd /sys/kernel/debug/tracing
That /sys/kernel/tracing (without /debug).
The traces with port3 (tb4) and port0 (tb5):
# entries-in-buffer/entries-written: 19/19 #P:16
#
# _-----=> irqs-off/BH-disabled
# / _----=> need-resched
# | / _---=> hardirq/softirq
# || / _--=> preempt-depth
# ||| / _-=> migrate-disable
# |||| / delay
# TASK-PID CPU# ||||| TIMESTAMP FUNCTION
# | | | ||||| | |
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
kworker/u64:2-356 [005] ..... 467.005141:
ucsi_register_altmode: partner alt mode: svid 8087, mode 2 vdo 1
kworker/2:1-177 [002] ..... 471.027602:
ucsi_connector_change: port3 status: change=0200, opmode=3, connected=1,
sourcing=0, partner_flags=1, partner_type=2, request_data_obj=82c7d1f4,
BC status=1
kworker/2:1-177 [002] ..... 1140.998711:
ucsi_connector_change: port3 status: change=4000, opmode=1, connected=0,
sourcing=0, partner_flags=0, partner_type=0, request_data_obj=82c7d1f4,
BC status=0
kworker/0:2-15093 [000] ..... 1164.065528:
ucsi_connector_change: port0 status: change=4000, opmode=4, connected=1,
sourcing=1, partner_flags=1, partner_type=2, request_data_obj=00000000,
BC status=1
kworker/0:2-15093 [000] ..... 1164.173696:
ucsi_connector_change: port0 status: change=0060, opmode=3, connected=1,
sourcing=1, partner_flags=1, partner_type=2, request_data_obj=13800000,
BC status=1
kworker/7:0-13116 [007] ..... 1164.508267:
ucsi_connector_change: port0 status: change=1000, opmode=5, connected=1,
sourcing=0, partner_flags=1, partner_type=2, request_data_obj=13800000,
BC status=1
kworker/7:0-13116 [007] ..... 1164.609765:
ucsi_connector_change: port0 status: change=0060, opmode=3, connected=1,
sourcing=0, partner_flags=1, partner_type=2, request_data_obj=42c4b12c,
BC status=1
kworker/6:3-360 [006] ..... 1165.119848:
ucsi_connector_change: port0 status: change=0060, opmode=3, connected=1,
sourcing=0, partner_flags=1, partner_type=2, request_data_obj=82c7d1f4,
BC status=1
kworker/6:3-360 [006] ..... 1165.208511:
ucsi_connector_change: port0 status: change=0060, opmode=3, connected=1,
sourcing=0, partner_flags=1, partner_type=2, request_data_obj=82c7d1f4,
BC status=1
kworker/u64:3-1005 [010] ..... 1166.339613:
ucsi_register_altmode: partner alt mode: svid 8087, mode 1 vdo 8087a843
kworker/u64:3-1005 [011] ..... 1166.454835:
ucsi_register_altmode: partner alt mode: svid 8087, mode 2 vdo 1
kworker/1:3-191 [001] ..... 1170.026494:
ucsi_connector_change: port0 status: change=0200, opmode=3, connected=1,
sourcing=0, partner_flags=1, partner_type=2, request_data_obj=82c7d1f4,
BC status=1
> 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
Thanks
François
^ permalink raw reply
* [PATCH v1] usb: typec: ucsi: Set usb mode on partner change
From: Jameson Thies @ 2026-04-02 18:24 UTC (permalink / raw)
To: heikki.krogerus, linux-usb, linux-kernel
Cc: dmitry.baryshkov, bleung, gregkh, akuchynski, abhishekpandit,
Jameson Thies
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>
---
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)) &&
base-commit: 81ebd43cc0d6d106ce7b6ccbf7b5e40ca7f5503d
--
2.53.0.1213.gd9a14994de-goog
^ permalink raw reply related
* [PATCH] USB: cdc-acm: Add quirks for Yoga Book 9 14IAH10 INGENIC touchscreen
From: Dave Carey @ 2026-04-02 18:29 UTC (permalink / raw)
To: oneukum; +Cc: gregkh, linux-usb, linux-kernel, Dave Carey
The Lenovo Yoga Book 9 14IAH10 (83KJ) has a composite USB device
(17EF:6161) that controls both touchscreens via a CDC ACM interface.
Interface 0 is a standard CDC ACM control interface, but interface 1
(the data interface) incorrectly declares vendor-specific class (0xFF)
instead of USB_CLASS_CDC_DATA. cdc-acm rejects the device at probe with
-EINVAL, leaving interface 0 unbound and EP 0x82 never polled.
With no consumer polling EP 0x82, the firmware's watchdog fires every
~20 seconds and resets the USB bus, producing a continuous disconnect/
reconnect loop that prevents the touchscreens from ever initialising.
Add two new quirk flags:
VENDOR_CLASS_DATA_IFACE: Bypasses the bInterfaceClass check in
acm_probe() that would otherwise reject the vendor-class data
interface with -EINVAL.
ALWAYS_POLL_CTRL: Submits the notification URB at probe() rather than
waiting for a TTY open. This keeps EP 0x82 polled at all times,
permanently suppressing the firmware watchdog. The URB is resubmitted
after port_shutdown() and on system resume. SET_CONTROL_LINE_STATE
(DTR|RTS) is sent at probe and after port_shutdown() to complete
firmware handshake.
Note: the firmware performs exactly 4 USB connect/disconnect cycles
(~19 s each) on every cold boot before stabilising. This is a fixed
firmware property; touch is available ~75-80 s after power-on.
Signed-off-by: Dave Carey <carvsdriver@gmail.com>
Tested-by: Dave Carey <carvsdriver@gmail.com>
---
drivers/usb/class/cdc-acm.c | 53 ++++++++++++++++++++++++++++++++-----
1 file changed, 46 insertions(+), 7 deletions(-)
diff --git a/drivers/usb/class/cdc-acm.c b/drivers/usb/class/cdc-acm.c
index 7ede29d4c..568f0c479 100644
--- a/drivers/usb/class/cdc-acm.c
+++ b/drivers/usb/class/cdc-acm.c
@@ -114,6 +114,8 @@ static int acm_ctrl_msg(struct acm *acm, int request, int value,
int retval;
retval = usb_autopm_get_interface(acm->control);
+#define VENDOR_CLASS_DATA_IFACE BIT(9) /* data interface uses vendor-specific class */
+#define ALWAYS_POLL_CTRL BIT(10) /* keep ctrl URB active even without an open TTY */
if (retval)
return retval;
@@ -710,12 +712,14 @@ static int acm_port_activate(struct tty_port *port, struct tty_struct *tty)
set_bit(TTY_NO_WRITE_SPLIT, &tty->flags);
acm->control->needs_remote_wakeup = 1;
- acm->ctrlurb->dev = acm->dev;
- retval = usb_submit_urb(acm->ctrlurb, GFP_KERNEL);
- if (retval) {
- dev_err(&acm->control->dev,
- "%s - usb_submit_urb(ctrl irq) failed\n", __func__);
- goto error_submit_urb;
+ if (!(acm->quirks & ALWAYS_POLL_CTRL)) {
+ acm->ctrlurb->dev = acm->dev;
+ retval = usb_submit_urb(acm->ctrlurb, GFP_KERNEL);
+ if (retval) {
+ dev_err(&acm->control->dev,
+ "%s - usb_submit_urb(ctrl irq) failed\n", __func__);
+ goto error_submit_urb;
+ }
}
acm_tty_set_termios(tty, NULL);
@@ -788,6 +792,14 @@ static void acm_port_shutdown(struct tty_port *port)
acm_unpoison_urbs(acm);
+ if (acm->quirks & ALWAYS_POLL_CTRL) {
+ acm->ctrlurb->dev = acm->dev;
+ if (usb_submit_urb(acm->ctrlurb, GFP_KERNEL))
+ dev_dbg(&acm->control->dev,
+ "ctrl polling restart failed after port close\n");
+ /* port_shutdown() cleared DTR/RTS; restore them */
+ acm_set_control(acm, USB_CDC_CTRL_DTR | USB_CDC_CTRL_RTS);
+ }
}
static void acm_tty_cleanup(struct tty_struct *tty)
@@ -1322,6 +1334,9 @@ static int acm_probe(struct usb_interface *intf,
dev_dbg(&intf->dev,
"Your device has switched interfaces.\n");
swap(control_interface, data_interface);
+ } else if (quirks & VENDOR_CLASS_DATA_IFACE) {
+ dev_dbg(&intf->dev,
+ "Vendor-specific data interface class, continuing.\n");
} else {
return -EINVAL;
}
@@ -1516,6 +1531,9 @@ static int acm_probe(struct usb_interface *intf,
acm->line.bDataBits = 8;
acm_set_line(acm, &acm->line);
+ if (quirks & ALWAYS_POLL_CTRL)
+ acm_set_control(acm, USB_CDC_CTRL_DTR | USB_CDC_CTRL_RTS);
+
if (!acm->combined_interfaces) {
rv = usb_driver_claim_interface(&acm_driver, data_interface, acm);
if (rv)
@@ -1537,6 +1555,13 @@ static int acm_probe(struct usb_interface *intf,
dev_info(&intf->dev, "ttyACM%d: USB ACM device\n", minor);
+ if (acm->quirks & ALWAYS_POLL_CTRL) {
+ acm->ctrlurb->dev = acm->dev;
+ if (usb_submit_urb(acm->ctrlurb, GFP_KERNEL))
+ dev_warn(&intf->dev,
+ "failed to start persistent ctrl polling\n");
+ }
+
return 0;
err_release_data_interface:
@@ -1663,7 +1688,7 @@ static int acm_resume(struct usb_interface *intf)
acm_unpoison_urbs(acm);
- if (tty_port_initialized(&acm->port)) {
+ if (tty_port_initialized(&acm->port) || (acm->quirks & ALWAYS_POLL_CTRL)) {
rv = usb_submit_urb(acm->ctrlurb, GFP_ATOMIC);
for (;;) {
@@ -2007,6 +2032,20 @@ static const struct usb_device_id acm_ids[] = {
/* CH343 supports CAP_BRK, but doesn't advertise it */
{ USB_DEVICE(0x1a86, 0x55d3), .driver_info = MISSING_CAP_BRK, },
+ /*
+ * Lenovo Yoga Book 9 14IAH10 (83KJ) — INGENIC 17EF:6161 touchscreen
+ * composite device. The CDC ACM control interface (0) uses a standard
+ * Union descriptor, but the data interface (1) is declared as vendor-
+ * specific class (0xff) with no CDC data descriptors, so cdc-acm would
+ * normally reject it. The firmware also requires continuous polling of
+ * the notification endpoint (EP 0x82) to suppress a 20-second watchdog
+ * reset; ALWAYS_POLL_CTRL keeps the ctrlurb active even when no TTY is
+ * open. Match only the control interface by class to avoid probing the
+ * vendor-specific data interface.
+ */
+ { USB_DEVICE_INTERFACE_CLASS(0x17ef, 0x6161, USB_CLASS_COMM),
+ .driver_info = VENDOR_CLASS_DATA_IFACE | ALWAYS_POLL_CTRL },
+
/* control interfaces without any protocol set */
{ USB_INTERFACE_INFO(USB_CLASS_COMM, USB_CDC_SUBCLASS_ACM,
USB_CDC_PROTO_NONE) },
--
2.53.0
^ permalink raw reply related
* Re: [PATCH] usb: gadget: f_hid: Add missing error code
From: Peter Korsgaard @ 2026-04-02 18:40 UTC (permalink / raw)
To: Ethan Tidmore
Cc: gregkh, sigmaepsilon92, mhklinux, linuxhid, danisjiang, kees,
hoff.benjamin.k, linux-usb, linux-kernel
In-Reply-To: <20260402180008.64233-1-ethantidmore06@gmail.com>
>>>>> "Ethan" == Ethan Tidmore <ethantidmore06@gmail.com> writes:
> 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>
Acked-by: Peter Korsgaard <peter@korsgaard.com>
--
Bye, Peter Korsgaard
^ permalink raw reply
* Re: [PATCH v10 6/6] usb: typec: tcpm/tcpci_maxim: deprecate WAR for setting charger mode
From: Amit Sunil Dhamne @ 2026-04-02 18:47 UTC (permalink / raw)
To: Heikki Krogerus
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: <ac5-OzwQkczTWtMg@kuha>
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.
Thanks,
Amit
>
> thanks,
>
>> + if (IS_ERR_OR_NULL(chip->vbus_reg)) {
>> + dev_err(chip->dev,
>> + "Failed to get vbus regulator handle\n");
>> + return -ENODEV;
>> + }
>> + }
>> +
>> + return 0;
>> +}
^ permalink raw reply
* Re: [PATCH] USB: cdc-acm: Add quirks for Yoga Book 9 14IAH10 INGENIC touchscreen
From: Oliver Neukum @ 2026-04-02 18:56 UTC (permalink / raw)
To: Dave Carey, oneukum; +Cc: gregkh, linux-usb, linux-kernel
In-Reply-To: <20260402182950.389016-1-carvsdriver@gmail.com>
On 02.04.26 20:29, Dave Carey wrote:
> The Lenovo Yoga Book 9 14IAH10 (83KJ) has a composite USB device
> (17EF:6161) that controls both touchscreens via a CDC ACM interface.
> Interface 0 is a standard CDC ACM control interface, but interface 1
> (the data interface) incorrectly declares vendor-specific class (0xFF)
> instead of USB_CLASS_CDC_DATA. cdc-acm rejects the device at probe with
> -EINVAL, leaving interface 0 unbound and EP 0x82 never polled.
>
> With no consumer polling EP 0x82, the firmware's watchdog fires every
> ~20 seconds and resets the USB bus, producing a continuous disconnect/
> reconnect loop that prevents the touchscreens from ever initialising.
>
> Add two new quirk flags:
>
> VENDOR_CLASS_DATA_IFACE: Bypasses the bInterfaceClass check in
> acm_probe() that would otherwise reject the vendor-class data
> interface with -EINVAL.
>
> ALWAYS_POLL_CTRL: Submits the notification URB at probe() rather than
> waiting for a TTY open. This keeps EP 0x82 polled at all times,
> permanently suppressing the firmware watchdog. The URB is resubmitted
> after port_shutdown() and on system resume. SET_CONTROL_LINE_STATE
> (DTR|RTS) is sent at probe and after port_shutdown() to complete
> firmware handshake.
>
> Note: the firmware performs exactly 4 USB connect/disconnect cycles
> (~19 s each) on every cold boot before stabilising. This is a fixed
> firmware property; touch is available ~75-80 s after power-on.
>
> Signed-off-by: Dave Carey <carvsdriver@gmail.com>
> Tested-by: Dave Carey <carvsdriver@gmail.com>
Acked-by: Oliver Neukum <oneukum@suse.com>
^ permalink raw reply
* Re: [PATCH v1] usb: typec: ucsi: Set usb mode on partner change
From: Benson Leung @ 2026-04-02 19:50 UTC (permalink / raw)
To: Jameson Thies
Cc: heikki.krogerus, linux-usb, linux-kernel, dmitry.baryshkov,
bleung, gregkh, akuchynski, abhishekpandit
In-Reply-To: <20260402182438.867396-1-jthies@google.com>
[-- Attachment #1: Type: text/plain, Size: 1525 bytes --]
Hi Jameson,
On Thu, Apr 02, 2026 at 06:24:38PM +0000, Jameson Thies wrote:
> 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: Benson Leung <bleung@chromium.org>
> ---
> 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)) &&
>
> base-commit: 81ebd43cc0d6d106ce7b6ccbf7b5e40ca7f5503d
> --
> 2.53.0.1213.gd9a14994de-goog
>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH] usb: core: Fix bandwidth for devices with invalid wBytesPerInterval
From: Michal Pecio @ 2026-04-02 20:17 UTC (permalink / raw)
To: Alan Stern
Cc: Xuetao (kirin), Greg KH, linux-usb, linux-kernel, caiyadong,
stable
In-Reply-To: <74f1bb0d-24c3-44be-9583-0585863cdae3@rowland.harvard.edu>
On Thu, 2 Apr 2026 09:56:51 -0400, Alan Stern wrote:
> On Thu, Apr 02, 2026 at 02:59:35PM +0800, Xuetao (kirin) wrote:
> > 2、Following Alan's suggestion in another email, should I check
> > whether wBytesPerInterval is a valid value and handle it in the
> > usb_parse_ss_endpoint_companion() ?
>
> Yes, IMO.
Not sure, this could backfire if it turns out that these workarounds
will need to become more elaborate and account for wBytesPerInterval.
These descriptors aren't blatantly invalid. USB3 9.6.7 doesn't require
that wBytesPerInterval == wMaxPacketSize * bMaxBurst * Mult.
Being greater would be blatantly invalid, but this is already being
sanitized by the descriptor parser.
> > However, when parsing the device descriptor, we do not know whether
> > the actual data length transmitted by the peripheral is greater than
> > wBytesPerInterval.
Indeed. Device is allowed (actually: required) not to send more data
than its wBytesPerInterval on IN endpoints.
UVC driver uses this field to pick isochronous altsetting capable of
transmitting a particular payload each interval. If we overestimate,
there is risk that the device will deliver on its promise and truncate
instead of violating USB3 spec. We should rather pick a larger alt.
OTOH, when a device lies and sends more than specified, this happens.
Some HCs ignore the problem (and may overcommit bandwidth if we enable
million such endpoints), others get pedantic and return Babble Error
(my mistake, Bandwidth Overrun is specific to isochronous).
I think this patch is relatively safe for interrupt, because drivers
generally don't look at endpoint descriptors and submit URBs of class
specific size. Case in point, everything works when you override xHCI
allocation. It also works on HCs ignoring it.
Beind the pedant I am, I would restrict this to bMaxBurst==0 because
that's the known problem case and IDK off-hand what devices might use
bursting interrupt endpoints and what gotchas await there.
Maybe add a comment that it's a questionable, spec-violating hack.
Regards,
Michal
^ permalink raw reply
* Re: AW: [BUG] Thunderbolt runtime resume during PCIe removal causes IRQ warning and shutdown failure.
From: Bjorn Helgaas @ 2026-04-02 22:20 UTC (permalink / raw)
To: Georg Klima
Cc: linux-pci, linux-kernel, Georg Klima, Lukas Wunner,
Andreas Noever, Mika Westerberg, Yehezkel Bernat, linux-usb
In-Reply-To: <AM9PR10MB4231D6536D271E1F5A81F3D1B757A@AM9PR10MB4231.EURPRD10.PROD.OUTLOOK.COM>
[+cc Thunderbolt & pciehp folks, initial report of system poweroff
failure at
https://lore.kernel.org/all/AM9PR10MB42316BF3E59B29E1EA3E5600B756A@AM9PR10MB4231.EURPRD10.PROD.OUTLOOK.COM]
On Fri, Mar 27, 2026 at 05:28:28PM +0000, Georg Klima wrote:
> Hi Bjorn,
>
> Upstream without nvidia, more debug, same issue with aspm default:
Thanks for this test with an upstream kernel (6.19.10). Complete
dmesg log was attached to
https://lore.kernel.org/all/AM9PR10MB4231D6536D271E1F5A81F3D1B757A@AM9PR10MB4231.EURPRD10.PROD.OUTLOOK.COM/
Linux only requests control of PME, AER, hotplug, etc if Linux
supports ASPM and MSI. "pcie_aspm=off" means Linux doesn't support
ASPM, so it doesn't request control:
--- dmesg_aspm_off.txt
+++ dmesg_actual.txt
- acpi PNP0A08:01: _OSC: OS supports [ExtendedConfig Segments MSI EDR HPX-Type3]
+ acpi PNP0A08:01: _OSC: OS supports [ExtendedConfig ASPM ClockPM Segments MSI EDR HPX-Type3]
- acpi PNP0A08:01: _OSC: not requesting OS control; OS requires [ExtendedConfig ASPM ClockPM MSI]
+ acpi PNP0A08:01: _OSC: OS now controls [PCIeHotplug SHPCHotplug PME AER PCIeCapability LTR DPC]
I suspect the issue is related to those services, not to ASPM itself.
Booting with "pcie_port_pm=off" might be a more targeted workaround.
You have this topology:
0000:80:1b.4: [8086:7f44] PCIe Root Port to [bus 88-d8]
0000:88:00.0: [8086:5780] PCIe Switch Upstream Port (JHL9580 Thunderbolt 5)
and the first thing I see in the 6.19.10 log is this, which makes me
think we put the Thunderbolt controller at 88:00.0 into D3 and are
trying to bring it back to D0 but it took too long, so we can't access
downstream devices like b1:00.0:
Mar 27 18:08:40 fedora kernel: pcieport 0000:80:1b.4: Data Link Layer Link Active not set in 100 msec
Mar 27 18:08:40 fedora kernel: pcieport 0000:80:1b.4: pciehp: Slot(25): Card not present
Mar 27 18:08:40 fedora kernel: xhci_hcd 0000:b1:00.0: Controller not ready at resume -19
Mar 27 18:08:40 fedora kernel: ------------[ cut here ]------------
Mar 27 18:08:40 fedora kernel: xhci_hcd 0000:b1:00.0: PCI post-resume error -19!
Mar 27 18:08:40 fedora kernel: thunderbolt 0000:8a:00.0: interrupt for TX ring 0 is already enabled
Mar 27 18:08:40 fedora kernel: tb_ring_start+0x149/0x330 [thunderbolt]
Mar 27 18:08:40 fedora kernel: tb_ctl_start+0x1b/0xc0 [thunderbolt]
Mar 27 18:08:40 fedora kernel: tb_domain_runtime_resume+0x19/0x40 [thunderbolt]
Mar 27 18:08:40 fedora kernel: __rpm_callback+0x48/0x1f0
Mar 27 18:08:40 fedora kernel: rpm_callback+0x6d/0x80
Mar 27 18:08:40 fedora kernel: rpm_resume+0x4ab/0x6d0
^ permalink raw reply
* Re: [PATCH] power: supply: max77759_charger: fix voltage scale (mV -> uV)
From: Sebastian Reichel @ 2026-04-02 22:28 UTC (permalink / raw)
To: amitsd
Cc: Greg Kroah-Hartman, André Draszik, linux-kernel, linux-pm,
linux-usb, Badhri Jagan Sridharan
In-Reply-To: <20260402-fix-psy-max77759-usb-next-v1-1-427f5af566c3@google.com>
[-- Attachment #1: Type: text/plain, Size: 8432 bytes --]
Hi,
On Thu, Apr 02, 2026 at 07:15:29AM +0000, Amit Sunil Dhamne via B4 Relay wrote:
> From: Amit Sunil Dhamne <amitsd@google.com>
>
> CONSTANT_CHARGE_VOLTAGE_MAX property incorrectly uses mV instead of uV.
> Add fix to use uV as per the power-supply subsystem convention.
>
> Also, add a note indicating all the properties use non negative values.
> A negative value indicates failure with the appropriate error value. In
> that case, it should not be taken as a measurement value or status.
>
> Signed-off-by: Amit Sunil Dhamne <amitsd@google.com>
> ---
> This patch is a follow-up to the series [1]. [1] has been accepted in
> the USB subsystem tree (usb-next). However, since Sebastian has additional
> feedback [2], I am sending this patch to address it. Please note that this
> patch is based out of usb-next branch on usb tree. This patch should be
> applied on top of 70d7dd27f6dc ("power: supply: max77759: add charger driver").
>
> [1] https://lore.kernel.org/all/20260325-max77759-charger-v9-0-4486dd297adc@google.com/
> [2] https://lore.kernel.org/all/ac2jYUA2F5oQsA2g@venus/#t
> ---
Fixes: 70d7dd27f6dc ("power: supply: max77759: add charger driver")
Reviewed-by: Sebastian Reichel <sebastian.reichel@collabora.com>
Greetings,
-- Sebastian
> Output of power supply selftest:
> root@google-gs:/data/power_supply# ./test_power_supply_properties.sh
> TAP version 13
> 1..66
> # Testing device max77759-charger
> ok 1 max77759-charger.exists
> ok 2 max77759-charger.uevent.NAME
> ok 3 max77759-charger.sysfs.type
> ok 4 max77759-charger.uevent.TYPE
> ok 5 max77759-charger.sysfs.usb_type # SKIP
> # Reported: '1' ()
> ok 6 max77759-charger.sysfs.online
> # Reported: '1' ()
> ok 7 max77759-charger.sysfs.present
> # Reported: 'Charging'
> ok 8 max77759-charger.sysfs.status
> ok 9 max77759-charger.sysfs.capacity # SKIP
> ok 10 max77759-charger.sysfs.capacity_level # SKIP
> ok 11 max77759-charger.sysfs.model_name # SKIP
> ok 12 max77759-charger.sysfs.manufacturer # SKIP
> ok 13 max77759-charger.sysfs.serial_number # SKIP
> ok 14 max77759-charger.sysfs.technology # SKIP
> ok 15 max77759-charger.sysfs.cycle_count # SKIP
> ok 16 max77759-charger.sysfs.scope # SKIP
> # Reported: '3000000' uA (3000 mA)
> ok 17 max77759-charger.sysfs.input_current_limit
> ok 18 max77759-charger.sysfs.input_voltage_limit # SKIP
> ok 19 max77759-charger.sysfs.voltage_now # SKIP
> ok 20 max77759-charger.sysfs.voltage_min # SKIP
> ok 21 max77759-charger.sysfs.voltage_max # SKIP
> ok 22 max77759-charger.sysfs.voltage_min_design # SKIP
> ok 23 max77759-charger.sysfs.voltage_max_design # SKIP
> ok 24 max77759-charger.sysfs.current_now # SKIP
> ok 25 max77759-charger.sysfs.current_max # SKIP
> ok 26 max77759-charger.sysfs.charge_now # SKIP
> ok 27 max77759-charger.sysfs.charge_full # SKIP
> ok 28 max77759-charger.sysfs.charge_full_design # SKIP
> ok 29 max77759-charger.sysfs.power_now # SKIP
> ok 30 max77759-charger.sysfs.energy_now # SKIP
> ok 31 max77759-charger.sysfs.energy_full # SKIP
> ok 32 max77759-charger.sysfs.energy_full_design # SKIP
> ok 33 max77759-charger.sysfs.energy_full_design # SKIP
> # Testing device tcpm-source-psy-1-0025
> ok 34 tcpm-source-psy-1-0025.exists
> ok 35 tcpm-source-psy-1-0025.uevent.NAME
> ok 36 tcpm-source-psy-1-0025.sysfs.type
> ok 37 tcpm-source-psy-1-0025.uevent.TYPE
> # Reported: 'C [PD] PD_PPS PD_SPR_AVS PD_PPS_SPR_AVS' ()
> ok 38 tcpm-source-psy-1-0025.sysfs.usb_type
> # Reported: '1' ()
> ok 39 tcpm-source-psy-1-0025.sysfs.online
> ok 40 tcpm-source-psy-1-0025.sysfs.present # SKIP
> ok 41 tcpm-source-psy-1-0025.sysfs.status # SKIP
> ok 42 tcpm-source-psy-1-0025.sysfs.capacity # SKIP
> ok 43 tcpm-source-psy-1-0025.sysfs.capacity_level # SKIP
> ok 44 tcpm-source-psy-1-0025.sysfs.model_name # SKIP
> ok 45 tcpm-source-psy-1-0025.sysfs.manufacturer # SKIP
> ok 46 tcpm-source-psy-1-0025.sysfs.serial_number # SKIP
> ok 47 tcpm-source-psy-1-0025.sysfs.technology # SKIP
> ok 48 tcpm-source-psy-1-0025.sysfs.cycle_count # SKIP
> ok 49 tcpm-source-psy-1-0025.sysfs.scope # SKIP
> ok 50 tcpm-source-psy-1-0025.sysfs.input_current_limit # SKIP
> ok 51 tcpm-source-psy-1-0025.sysfs.input_voltage_limit # SKIP
> # Reported: '5000000' uV (5 V)
> ok 52 tcpm-source-psy-1-0025.sysfs.voltage_now
> # Reported: '5000000' uV (5 V)
> ok 53 tcpm-source-psy-1-0025.sysfs.voltage_min
> # Reported: '5000000' uV (5 V)
> ok 54 tcpm-source-psy-1-0025.sysfs.voltage_max
> ok 55 tcpm-source-psy-1-0025.sysfs.voltage_min_design # SKIP
> ok 56 tcpm-source-psy-1-0025.sysfs.voltage_max_design # SKIP
> # Reported: '3000000' uA (3000 mA)
> ok 57 tcpm-source-psy-1-0025.sysfs.current_now
> # Reported: '3000000' uA (3000 mA)
> ok 58 tcpm-source-psy-1-0025.sysfs.current_max
> ok 59 tcpm-source-psy-1-0025.sysfs.charge_now # SKIP
> ok 60 tcpm-source-psy-1-0025.sysfs.charge_full # SKIP
> ok 61 tcpm-source-psy-1-0025.sysfs.charge_full_design # SKIP
> ok 62 tcpm-source-psy-1-0025.sysfs.power_now # SKIP
> ok 63 tcpm-source-psy-1-0025.sysfs.energy_now # SKIP
> ok 64 tcpm-source-psy-1-0025.sysfs.energy_full # SKIP
> ok 65 tcpm-source-psy-1-0025.sysfs.energy_full_design # SKIP
> ok 66 tcpm-source-psy-1-0025.sysfs.energy_full_design # SKIP
> # 47 skipped test(s) detected. Consider enabling relevant config options to improve coverage.
> # Totals: pass:19 fail:0 xfail:0 xpass:0 skip:47 error:0
> ---
> drivers/power/supply/max77759_charger.c | 21 +++++++++++++--------
> 1 file changed, 13 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/power/supply/max77759_charger.c b/drivers/power/supply/max77759_charger.c
> index 9bb414599f16..58594bb78426 100644
> --- a/drivers/power/supply/max77759_charger.c
> +++ b/drivers/power/supply/max77759_charger.c
> @@ -26,7 +26,7 @@
>
> /* Default values for Fast Charge Current & Float Voltage */
> #define CHG_CC_DEFAULT_UA 2266770
> -#define CHG_FV_DEFAULT_MV 4300
> +#define CHG_FV_DEFAULT_UV 4300000
>
> #define MAX_NUM_RETRIES 3
> #define PSY_WORK_RETRY_DELAY_MS 10
> @@ -61,10 +61,10 @@ static const struct linear_range chgcc_limit_ranges[] = {
> LINEAR_RANGE(200000, 0x3, 0x3C, 66670),
> };
>
> -/* Charge Termination Voltage Limits (in mV) */
> +/* Charge Termination Voltage Limits (in uV) */
> static const struct linear_range chg_cv_prm_ranges[] = {
> - LINEAR_RANGE(3800, 0x38, 0x39, 100),
> - LINEAR_RANGE(4000, 0x0, 0x32, 10),
> + LINEAR_RANGE(3800000, 0x38, 0x39, 100000),
> + LINEAR_RANGE(4000000, 0x0, 0x32, 10000),
> };
>
> /* USB input current limits (in uA) */
> @@ -310,14 +310,14 @@ static int get_float_voltage(struct max77759_charger *chg)
> return ret ? ret : val;
> }
>
> -static int set_float_voltage_limit(struct max77759_charger *chg, u32 fv_mv)
> +static int set_float_voltage_limit(struct max77759_charger *chg, u32 fv_uv)
> {
> u32 regval;
> bool found;
>
> linear_range_get_selector_high_array(chg_cv_prm_ranges,
> ARRAY_SIZE(chg_cv_prm_ranges),
> - fv_mv, ®val, &found);
> + fv_uv, ®val, &found);
> if (!found)
> return -EINVAL;
>
> @@ -370,6 +370,11 @@ static const enum power_supply_property max77759_charger_props[] = {
> POWER_SUPPLY_PROP_INPUT_CURRENT_LIMIT,
> };
>
> +/*
> + * Note: None of the properties in this driver support usage of negative values.
> + * If you do see one, it's because the function is reporting an error value and
> + * should not be taken as a measurement value or status.
> + */
> static int max77759_charger_get_property(struct power_supply *psy,
> enum power_supply_property psp,
> union power_supply_propval *pval)
> @@ -557,10 +562,10 @@ static int max77759_charger_init(struct max77759_charger *chg)
> return ret;
>
> if (power_supply_get_battery_info(chg->psy, &info)) {
> - fv = CHG_FV_DEFAULT_MV;
> + fv = CHG_FV_DEFAULT_UV;
> fast_chg_curr = CHG_CC_DEFAULT_UA;
> } else {
> - fv = info->constant_charge_voltage_max_uv / 1000;
> + fv = info->constant_charge_voltage_max_uv;
> fast_chg_curr = info->constant_charge_current_max_ua;
> }
>
>
> ---
> base-commit: 81ebd43cc0d6d106ce7b6ccbf7b5e40ca7f5503d
> change-id: 20260402-fix-psy-max77759-usb-next-15a4f86a08ce
>
> Best regards,
> --
> Amit Sunil Dhamne <amitsd@google.com>
>
>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [PATCH v2 2/3] power: supply: Add PD SPR AVS support to USB type enum
From: Sebastian Reichel @ 2026-04-02 22:39 UTC (permalink / raw)
To: Badhri Jagan Sridharan
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Heikki Krogerus,
Greg Kroah-Hartman, Amit Sunil Dhamne, devicetree, linux-kernel,
linux-pm, linux-usb
In-Reply-To: <20260316150301.3892223-3-badhri@google.com>
[-- Attachment #1: Type: text/plain, Size: 2989 bytes --]
Hi,
On Mon, Mar 16, 2026 at 03:03:00PM +0000, Badhri Jagan Sridharan wrote:
> Add two new members to the power_supply_usb_type to represent the
> USB Power Delivery (PD) Standard Power Range (SPR) Adjustable Voltage
> Supply (AVS) charging types:
>
> POWER_SUPPLY_USB_TYPE_PD_SPR_AVS: For devices supporting only the
> PD SPR AVS type.
>
> POWER_SUPPLY_USB_TYPE_PD_PPS_SPR_AVS: For devices that support both
> PD Programmable Power Supply (PPS) and PD SPR AVS.
>
> Signed-off-by: Badhri Jagan Sridharan <badhri@google.com>
> ---
I'm not too fond of these types, but I guess we already fell into
the rabbit hole when PD_PPS was added. So:
Acked-by: Sebastian Reichel <sebastian.reichel@collabora.com>
I guess the patches will be handled via the USB tree.
Greetings,
-- Sebastian
> Documentation/ABI/testing/sysfs-class-power | 3 ++-
> drivers/power/supply/power_supply_sysfs.c | 2 ++
> include/linux/power_supply.h | 3 +++
> 3 files changed, 7 insertions(+), 1 deletion(-)
>
> diff --git a/Documentation/ABI/testing/sysfs-class-power b/Documentation/ABI/testing/sysfs-class-power
> index 4b21d5d23251..32697b926cc8 100644
> --- a/Documentation/ABI/testing/sysfs-class-power
> +++ b/Documentation/ABI/testing/sysfs-class-power
> @@ -675,7 +675,8 @@ Description:
>
> Valid values:
> "Unknown", "SDP", "DCP", "CDP", "ACA", "C", "PD",
> - "PD_DRP", "PD_PPS", "BrickID"
> + "PD_DRP", "PD_PPS", "BrickID", "PD_SPR_AVS",
> + "PD_PPS_SPR_AVS"
>
> **Device Specific Properties**
>
> diff --git a/drivers/power/supply/power_supply_sysfs.c b/drivers/power/supply/power_supply_sysfs.c
> index dd3a48d72d2b..f30a7b9ccd5e 100644
> --- a/drivers/power/supply/power_supply_sysfs.c
> +++ b/drivers/power/supply/power_supply_sysfs.c
> @@ -70,6 +70,8 @@ static const char * const POWER_SUPPLY_USB_TYPE_TEXT[] = {
> [POWER_SUPPLY_USB_TYPE_PD] = "PD",
> [POWER_SUPPLY_USB_TYPE_PD_DRP] = "PD_DRP",
> [POWER_SUPPLY_USB_TYPE_PD_PPS] = "PD_PPS",
> + [POWER_SUPPLY_USB_TYPE_PD_SPR_AVS] = "PD_SPR_AVS",
> + [POWER_SUPPLY_USB_TYPE_PD_PPS_SPR_AVS] = "PD_PPS_SPR_AVS",
> [POWER_SUPPLY_USB_TYPE_APPLE_BRICK_ID] = "BrickID",
> };
>
> diff --git a/include/linux/power_supply.h b/include/linux/power_supply.h
> index 360ffdf272da..7a5e4c3242a0 100644
> --- a/include/linux/power_supply.h
> +++ b/include/linux/power_supply.h
> @@ -210,6 +210,9 @@ enum power_supply_usb_type {
> POWER_SUPPLY_USB_TYPE_PD, /* Power Delivery Port */
> POWER_SUPPLY_USB_TYPE_PD_DRP, /* PD Dual Role Port */
> POWER_SUPPLY_USB_TYPE_PD_PPS, /* PD Programmable Power Supply */
> + /* PD Standard Power Range Adjustable Voltage Supply */
> + POWER_SUPPLY_USB_TYPE_PD_SPR_AVS,
> + POWER_SUPPLY_USB_TYPE_PD_PPS_SPR_AVS, /* Supports both PD PPS + SPR AVS */
> POWER_SUPPLY_USB_TYPE_APPLE_BRICK_ID, /* Apple Charging Method */
> };
>
> --
> 2.53.0.851.ga537e3e6e9-goog
>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* [usb:usb-linus] BUILD SUCCESS bf3781a35c27978341c31f59f1460dcaabf2e726
From: kernel test robot @ 2026-04-02 23:44 UTC (permalink / raw)
To: Greg Kroah-Hartman; +Cc: linux-usb
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git usb-linus
branch HEAD: bf3781a35c27978341c31f59f1460dcaabf2e726 Merge tag 'usb-serial-7.0-rc7' of ssh://gitolite.kernel.org/pub/scm/linux/kernel/git/johan/usb-serial into usb-linus
elapsed time: 732m
configs tested: 220
configs skipped: 2
The following configs have been built successfully.
More configs may be tested in the coming days.
tested configs:
alpha allnoconfig gcc-15.2.0
alpha allyesconfig gcc-15.2.0
alpha defconfig gcc-15.2.0
arc allmodconfig clang-16
arc allnoconfig gcc-15.2.0
arc allyesconfig clang-23
arc defconfig gcc-15.2.0
arc randconfig-001-20260402 gcc-11.5.0
arc randconfig-001-20260403 gcc-10.5.0
arc randconfig-002-20260402 gcc-11.5.0
arc randconfig-002-20260403 gcc-10.5.0
arm allnoconfig gcc-15.2.0
arm allyesconfig clang-16
arm defconfig gcc-15.2.0
arm orion5x_defconfig clang-23
arm randconfig-001-20260402 gcc-11.5.0
arm randconfig-001-20260403 gcc-10.5.0
arm randconfig-002-20260402 gcc-11.5.0
arm randconfig-002-20260403 gcc-10.5.0
arm randconfig-003-20260402 gcc-11.5.0
arm randconfig-003-20260403 gcc-10.5.0
arm randconfig-004-20260402 gcc-11.5.0
arm randconfig-004-20260403 gcc-10.5.0
arm64 allmodconfig clang-23
arm64 allnoconfig gcc-15.2.0
arm64 defconfig gcc-15.2.0
arm64 randconfig-001-20260402 gcc-15.2.0
arm64 randconfig-001-20260403 gcc-13.4.0
arm64 randconfig-002-20260402 gcc-15.2.0
arm64 randconfig-002-20260403 gcc-13.4.0
arm64 randconfig-003-20260402 gcc-15.2.0
arm64 randconfig-003-20260403 gcc-13.4.0
arm64 randconfig-004-20260402 gcc-15.2.0
arm64 randconfig-004-20260403 gcc-13.4.0
csky allmodconfig gcc-15.2.0
csky allnoconfig gcc-15.2.0
csky defconfig gcc-15.2.0
csky randconfig-001-20260402 gcc-15.2.0
csky randconfig-001-20260403 gcc-13.4.0
csky randconfig-002-20260402 gcc-15.2.0
csky randconfig-002-20260403 gcc-13.4.0
hexagon allmodconfig gcc-15.2.0
hexagon allnoconfig gcc-15.2.0
hexagon defconfig gcc-15.2.0
hexagon randconfig-001-20260402 clang-18
hexagon randconfig-001-20260403 clang-23
hexagon randconfig-002-20260402 clang-18
hexagon randconfig-002-20260403 clang-23
i386 allmodconfig clang-20
i386 allnoconfig gcc-15.2.0
i386 allyesconfig clang-20
i386 buildonly-randconfig-001-20260402 clang-20
i386 buildonly-randconfig-001-20260403 gcc-14
i386 buildonly-randconfig-002-20260402 clang-20
i386 buildonly-randconfig-002-20260403 gcc-14
i386 buildonly-randconfig-003-20260402 clang-20
i386 buildonly-randconfig-003-20260403 gcc-14
i386 buildonly-randconfig-004-20260402 clang-20
i386 buildonly-randconfig-004-20260403 gcc-14
i386 buildonly-randconfig-005-20260402 clang-20
i386 buildonly-randconfig-005-20260403 gcc-14
i386 buildonly-randconfig-006-20260402 clang-20
i386 buildonly-randconfig-006-20260403 gcc-14
i386 defconfig gcc-15.2.0
i386 randconfig-001-20260402 clang-20
i386 randconfig-001-20260403 gcc-14
i386 randconfig-002-20260402 clang-20
i386 randconfig-002-20260403 gcc-14
i386 randconfig-003-20260402 clang-20
i386 randconfig-003-20260403 gcc-14
i386 randconfig-004-20260402 clang-20
i386 randconfig-004-20260403 gcc-14
i386 randconfig-005-20260402 clang-20
i386 randconfig-005-20260403 gcc-14
i386 randconfig-006-20260402 clang-20
i386 randconfig-006-20260403 gcc-14
i386 randconfig-007-20260402 clang-20
i386 randconfig-007-20260403 gcc-14
i386 randconfig-011-20260402 clang-20
i386 randconfig-011-20260403 clang-20
i386 randconfig-012-20260402 clang-20
i386 randconfig-012-20260403 clang-20
i386 randconfig-013-20260402 clang-20
i386 randconfig-013-20260403 clang-20
i386 randconfig-014-20260402 clang-20
i386 randconfig-014-20260403 clang-20
i386 randconfig-015-20260402 clang-20
i386 randconfig-015-20260403 clang-20
i386 randconfig-016-20260402 clang-20
i386 randconfig-016-20260403 clang-20
i386 randconfig-017-20260402 clang-20
i386 randconfig-017-20260403 clang-20
loongarch allmodconfig clang-23
loongarch allnoconfig gcc-15.2.0
loongarch defconfig clang-19
loongarch randconfig-001-20260402 clang-18
loongarch randconfig-001-20260403 clang-23
loongarch randconfig-002-20260402 clang-18
loongarch randconfig-002-20260403 clang-23
m68k allmodconfig gcc-15.2.0
m68k allnoconfig gcc-15.2.0
m68k allyesconfig clang-16
m68k defconfig clang-19
microblaze allnoconfig gcc-15.2.0
microblaze allyesconfig gcc-15.2.0
microblaze defconfig clang-19
mips allmodconfig gcc-15.2.0
mips allnoconfig gcc-15.2.0
mips allyesconfig gcc-15.2.0
nios2 allmodconfig clang-23
nios2 allnoconfig clang-23
nios2 defconfig clang-19
nios2 randconfig-001-20260402 clang-18
nios2 randconfig-001-20260403 clang-23
nios2 randconfig-002-20260402 clang-18
nios2 randconfig-002-20260403 clang-23
openrisc allmodconfig clang-23
openrisc allnoconfig clang-23
openrisc defconfig gcc-15.2.0
parisc allmodconfig gcc-15.2.0
parisc allnoconfig clang-23
parisc allyesconfig clang-19
parisc defconfig gcc-15.2.0
parisc randconfig-001-20260402 clang-20
parisc randconfig-001-20260403 gcc-10.5.0
parisc randconfig-002-20260402 clang-20
parisc randconfig-002-20260403 gcc-10.5.0
parisc64 defconfig clang-19
powerpc allmodconfig gcc-15.2.0
powerpc allnoconfig clang-23
powerpc randconfig-001-20260402 clang-20
powerpc randconfig-001-20260403 gcc-10.5.0
powerpc randconfig-002-20260402 clang-20
powerpc randconfig-002-20260403 gcc-10.5.0
powerpc64 randconfig-001-20260402 clang-20
powerpc64 randconfig-001-20260403 gcc-10.5.0
powerpc64 randconfig-002-20260402 clang-20
powerpc64 randconfig-002-20260403 gcc-10.5.0
riscv allmodconfig clang-23
riscv allnoconfig clang-23
riscv allyesconfig clang-16
riscv defconfig gcc-15.2.0
riscv randconfig-001-20260402 clang-23
riscv randconfig-001-20260403 clang-23
riscv randconfig-002-20260402 clang-23
riscv randconfig-002-20260403 clang-23
s390 allmodconfig clang-19
s390 allnoconfig clang-23
s390 allyesconfig gcc-15.2.0
s390 defconfig gcc-15.2.0
s390 randconfig-001-20260402 clang-23
s390 randconfig-001-20260403 clang-23
s390 randconfig-002-20260402 clang-23
s390 randconfig-002-20260403 clang-23
sh allmodconfig gcc-15.2.0
sh allnoconfig clang-23
sh allyesconfig clang-19
sh defconfig gcc-14
sh randconfig-001-20260402 clang-23
sh randconfig-001-20260403 clang-23
sh randconfig-002-20260402 clang-23
sh randconfig-002-20260403 clang-23
sparc allnoconfig clang-23
sparc defconfig gcc-15.2.0
sparc randconfig-001-20260402 gcc-14
sparc randconfig-001-20260403 clang-20
sparc randconfig-002-20260402 gcc-14
sparc randconfig-002-20260403 clang-20
sparc64 allmodconfig clang-23
sparc64 defconfig gcc-14
sparc64 randconfig-001-20260402 gcc-14
sparc64 randconfig-001-20260403 clang-20
sparc64 randconfig-002-20260402 gcc-14
sparc64 randconfig-002-20260403 clang-20
um allmodconfig clang-19
um allnoconfig clang-23
um allyesconfig gcc-15.2.0
um defconfig gcc-14
um i386_defconfig gcc-14
um randconfig-001-20260402 gcc-14
um randconfig-001-20260403 clang-20
um randconfig-002-20260402 gcc-14
um randconfig-002-20260403 clang-20
um x86_64_defconfig gcc-14
x86_64 allmodconfig clang-20
x86_64 allnoconfig clang-23
x86_64 allyesconfig clang-20
x86_64 buildonly-randconfig-001-20260402 clang-20
x86_64 buildonly-randconfig-001-20260403 clang-20
x86_64 buildonly-randconfig-002-20260402 clang-20
x86_64 buildonly-randconfig-002-20260403 clang-20
x86_64 buildonly-randconfig-003-20260402 clang-20
x86_64 buildonly-randconfig-003-20260403 clang-20
x86_64 buildonly-randconfig-004-20260402 clang-20
x86_64 buildonly-randconfig-004-20260403 clang-20
x86_64 buildonly-randconfig-005-20260402 clang-20
x86_64 buildonly-randconfig-005-20260403 clang-20
x86_64 buildonly-randconfig-006-20260402 clang-20
x86_64 buildonly-randconfig-006-20260403 clang-20
x86_64 defconfig gcc-14
x86_64 kexec clang-20
x86_64 randconfig-071-20260402 clang-20
x86_64 randconfig-072-20260402 clang-20
x86_64 randconfig-073-20260402 clang-20
x86_64 randconfig-074-20260402 clang-20
x86_64 randconfig-075-20260402 clang-20
x86_64 randconfig-076-20260402 clang-20
x86_64 rhel-9.4 clang-20
x86_64 rhel-9.4-bpf gcc-14
x86_64 rhel-9.4-func clang-20
x86_64 rhel-9.4-kselftests clang-20
x86_64 rhel-9.4-kunit gcc-14
x86_64 rhel-9.4-ltp gcc-14
x86_64 rhel-9.4-rust clang-20
xtensa allnoconfig clang-23
xtensa allyesconfig clang-23
xtensa randconfig-001-20260402 gcc-14
xtensa randconfig-001-20260403 clang-20
xtensa randconfig-002-20260402 gcc-14
xtensa randconfig-002-20260403 clang-20
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
^ permalink raw reply
* [PATCH v3 0/9] driver core: Fix some race conditions
From: Douglas Anderson @ 2026-04-03 0:49 UTC (permalink / raw)
To: Greg Kroah-Hartman, Rafael J . Wysocki, Danilo Krummrich,
Alan Stern
Cc: Robin Murphy, Leon Romanovsky, Paul Burton, Saravana Kannan,
Alexander Lobakin, Eric Dumazet, Toshi Kani, Christoph Hellwig,
Alexey Kardashevskiy, Johan Hovold, Douglas Anderson,
Andrew Morton, Frank.Li, Jason Gunthorpe, alex, alexander.stein,
andre.przywara, andrew, andrew, andriy.shevchenko, aou, ardb,
astewart, bhelgaas, brgl, broonie, catalin.marinas, chleroy,
davem, david, devicetree, dmaengine, driver-core, gbatra,
gregory.clement, hkallweit1, iommu, jirislaby, joel, joro, kees,
kevin.brodsky, kuba, lenb, lgirdwood, linux-acpi,
linux-arm-kernel, linux-aspeed, linux-cxl, linux-kernel,
linux-mips, linux-mm, linux-pci, linux-riscv, linux-serial,
linux-snps-arc, linux-usb, linux, linuxppc-dev, m.szyprowski,
maddy, mani, maz, miko.lenczewski, mpe, netdev, npiggin,
osalvador, oupton, pabeni, palmer, peter.ujfalusi, peterz, pjw,
robh, sebastian.hesselbarth, tglx, tsbogend, vgupta, vkoul, will,
willy, yangyicong, yeoreum.yun
The main goal of this series is to fix the observed bug talked about
in the first patch ("driver core: Don't let a device probe until it's
ready"). That patch fixes a problem that has been observed in the real
world and could land even if the rest of the patches are found
unacceptable or need to be spun.
That said, during patch review Danilo correctly pointed out that many
of the bitfield accesses in "struct device" are unsafe. I added a
bunch of patches in the series to address each one.
Danilo said he's most worried about "can_match", so I put that one
first. After that, I tried to transition bitfields to flags in reverse
order to when the bitfield was added.
Even if transitioning from bitfields to flags isn't truly needed for
correctness, it seems silly (and wasteful of space in struct device)
to have some in bitfields and some as flags. Thus I didn't spend time
for each bitfield showing that it's truly needed for correctness.
Transition was done semi manually. Presumably someone skilled at
coccinelle could do a better job, but I just used sed in a heavy-
handed manner and then reviewed/fixed the results, undoing anything my
script got wrong. My terrible/ugly script was:
var=can_match
caps="${var^^}"
for f in $(git grep -l "[>\.]${var}[^1-9_a-zA-Z\[]"); do
echo $f
sed -i~ -e "s/\([a-zA-Z_0-9\.>()-][a-zA-Z_0-9\.>()-]*\)->${var} = true/set_bit(DEV_FLAG_${caps}, \&\\1->flags)/" "$f"
sed -i~ -e "s/\([a-zA-Z_0-9\.>()-][a-zA-Z_0-9\.>()-]*\)\.${var} = true/set_bit(DEV_FLAG_${caps}, \&\\1.flags)/" "$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/clear_bit(DEV_FLAG_${caps}, \&\\1.flags)/" "$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} = \([^;]*\)/assign_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\[]\)/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\[]\)/test_bit(DEV_FLAG_${caps}, \&\\1.flags)\\2/" "$f"
done
NOTE: one potentially "controversial" choice I made in some patches
was to always reserve a flag ID even if a flag is only used under
certain CONFIG_ settings. This is a change from how things were
before. Keeping the numbering consistent and allowing easy
compile-testing of both CONFIG settings seemed worth it, especially
since it won't take up any extra space until we've added a lot more
flags.
I only marked the first patch as a "Fix" since it is the only one
fixing observed problems. Other patches could be considered fixes too
if folks want.
I tested the first patch in the series backported to kernel 6.6 on the
Pixel phone that was experiencing the race. I added extra printouts to
make sure that the problem was hitting / addressed. The rest of the
patches are tested with allmodconfig with arm32, arm64, ppc, and
x86. I boot tested on an arm64 Chromebook running mainline.
Changes in 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_FLAG_CAN_MATCH
driver core: Replace dev->dma_iommu with DEV_FLAG_DMA_IOMMU
driver core: Replace dev->dma_skip_sync with DEV_FLAG_DMA_SKIP_SYNC
driver core: Replace dev->dma_ops_bypass with DEV_FLAG_DMA_OPS_BYPASS
driver core: Replace dev->state_synced with DEV_FLAG_STATE_SYNCED
driver core: Replace dev->dma_coherent with DEV_FLAG_DMA_COHERENT
driver core: Replace dev->of_node_reused with DEV_FLAG_OF_NODE_REUSED
driver core: Replace dev->offline + ->offline_disabled with DEV_FLAGs
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 | 30 +++----
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 | 3 +-
drivers/base/core.c | 55 +++++++-----
drivers/base/cpu.c | 4 +-
drivers/base/dd.c | 28 +++++--
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 | 83 ++++++++++---------
include/linux/dma-map-ops.h | 6 +-
include/linux/dma-mapping.h | 2 +-
include/linux/iommu-dma.h | 4 +-
kernel/cpu.c | 4 +-
kernel/dma/mapping.c | 16 ++--
mm/hmm.c | 2 +-
37 files changed, 178 insertions(+), 143 deletions(-)
--
2.53.0.1213.gd9a14994de-goog
^ permalink raw reply
* [PATCH v3 8/9] driver core: Replace dev->of_node_reused with DEV_FLAG_OF_NODE_REUSED
From: Douglas Anderson @ 2026-04-03 0:49 UTC (permalink / raw)
To: Greg Kroah-Hartman, Rafael J . Wysocki, Danilo Krummrich,
Alan Stern
Cc: Robin Murphy, Leon Romanovsky, Paul Burton, Saravana Kannan,
Alexander Lobakin, Eric Dumazet, Toshi Kani, Christoph Hellwig,
Alexey Kardashevskiy, Johan Hovold, Douglas Anderson,
alexander.stein, andrew, andrew, andriy.shevchenko, astewart,
bhelgaas, brgl, broonie, 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: <20260403005005.30424-1-dianders@chromium.org>
In C, bitfields are not necessarily safe to modify from multiple
threads without locking. Switch "of_node_reused" over to the "flags"
field so modifications are safe.
Cc: Johan Hovold <johan@kernel.org>
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).
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 | 6 +++---
12 files changed, 16 insertions(+), 16 deletions(-)
diff --git a/drivers/base/core.c b/drivers/base/core.c
index 00005777c21f..a87bd40499b6 100644
--- a/drivers/base/core.c
+++ b/drivers/base/core.c
@@ -5282,7 +5282,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;
+ set_bit(DEV_FLAG_OF_NODE_REUSED, &dev->flags);
}
EXPORT_SYMBOL_GPL(device_set_of_node_from_dev);
diff --git a/drivers/base/pinctrl.c b/drivers/base/pinctrl.c
index 6e250272c843..62c228c75d50 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 (test_bit(DEV_FLAG_OF_NODE_REUSED, &dev->flags))
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..5128ff7e5e78 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;
+ assign_bit(DEV_FLAG_OF_NODE_REUSED, &pdev->dev.flags, 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..c2722d8bd98a 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;
+ set_bit(DEV_FLAG_OF_NODE_REUSED, &mdiodev->dev.flags);
/* 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..fd77295a8c0f 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 || test_bit(DEV_FLAG_OF_NODE_REUSED, &dev->flags))
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 || test_bit(DEV_FLAG_OF_NODE_REUSED, &dev->flags))
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) || test_bit(DEV_FLAG_OF_NODE_REUSED, &dev->flags))
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..197b60c5a660 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;
+ set_bit(DEV_FLAG_OF_NODE_REUSED, &dev->bus->dev.flags);
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..cfbe9b615b88 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;
+ set_bit(DEV_FLAG_OF_NODE_REUSED, &dev->flags);
break;
}
diff --git a/drivers/regulator/bq257xx-regulator.c b/drivers/regulator/bq257xx-regulator.c
index dab8f1ab4450..01d3139e1d87 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;
+ set_bit(DEV_FLAG_OF_NODE_REUSED, &pdev->dev.flags);
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..375ea7861134 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;
+ set_bit(DEV_FLAG_OF_NODE_REUSED, &pdev->dev.flags);
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..86c6003bbebb 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;
+ set_bit(DEV_FLAG_OF_NODE_REUSED, &dev->flags);
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..57048e3aa6bb 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;
+ set_bit(DEV_FLAG_OF_NODE_REUSED, &d->gadget.dev.flags);
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 c2a6dba7a036..f6ca067bacca 100644
--- a/include/linux/device.h
+++ b/include/linux/device.h
@@ -482,6 +482,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,
@@ -491,6 +493,7 @@ enum struct_device_flags {
DEV_FLAG_DMA_OPS_BYPASS,
DEV_FLAG_STATE_SYNCED,
DEV_FLAG_DMA_COHERENT,
+ DEV_FLAG_OF_NODE_REUSED,
};
/**
@@ -570,8 +573,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
@@ -678,7 +679,6 @@ struct device {
bool offline_disabled:1;
bool offline:1;
- bool of_node_reused:1;
unsigned long flags;
};
--
2.53.0.1213.gd9a14994de-goog
^ permalink raw reply related
* Re: [PATCH net-next] r8152: Add helper functions for SRAM2
From: patchwork-bot+netdevbpf @ 2026-04-03 1:10 UTC (permalink / raw)
To: Chih Kai Hsu
Cc: kuba, davem, netdev, nic_swsd, linux-kernel, linux-usb, edumazet,
bjorn, pabeni
In-Reply-To: <20260401115542.34601-1-nic_swsd@realtek.com>
Hello:
This patch was applied to netdev/net-next.git (main)
by Jakub Kicinski <kuba@kernel.org>:
On Wed, 1 Apr 2026 19:55:41 +0800 you wrote:
> Add the following helper functions for SRAM2 access to simplify the code
> and improve readability:
>
> - sram2_write() - write data to SRAM2 address
> - sram2_read() - read data from SRAM2 address
> - sram2_write_w0w1() - read-modify-write operation
>
> [...]
Here is the summary with links:
- [net-next] r8152: Add helper functions for SRAM2
https://git.kernel.org/netdev/net-next/c/86f5dd4e0ff2
You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html
^ permalink raw reply
* Re: [PATCH] usb: core: Fix bandwidth for devices with invalid wBytesPerInterval
From: Xuetao (kirin) @ 2026-04-03 1:20 UTC (permalink / raw)
To: Greg KH, Alan Stern; +Cc: linux-usb, linux-kernel, caiyadong, stable
In-Reply-To: <2026040221-reclusive-garland-6281@gregkh>
在 2026/4/2 22:09, Greg KH 写道:
> On Thu, Apr 02, 2026 at 09:56:51AM -0400, Alan Stern wrote:
>> On Thu, Apr 02, 2026 at 02:59:35PM +0800, Xuetao (kirin) wrote:
>>> 2、Following Alan's suggestion in another email, should I check whether
>>> wBytesPerInterval is a valid value and handle it in the
>>> usb_parse_ss_endpoint_companion() ?
>>
>> Yes, IMO.
>>
>>> However, when parsing the device descriptor, we do not know whether the
>>> actual data length transmitted by the peripheral is greater than
>>> wBytesPerInterval.
>>
>> Note: wBytesPerInterval is in the endpoint descriptor, not the device
>> descriptor.
>>
Thank you for your review. I will correct the description in the
subsequent patch.
>>> Therefore, would it be sufficient to only add a check for whether
>>> wBytesPerInterval is 0 in the existing flow, and if it is 0, set
>>> wBytesPerInterval to cpu_to_le16(max_tx) by default?
>>>
>>> For example, modify it in the following way：
>>>
>>> if (le16_to_cpu(desc->wBytesPerInterval) > max_tx ||
>>> le16_to_cpu(desc->wBytesPerInterval) == 0) {
>>> dev_notice(ddev, "%s endpoint with wBytesPerInterval of %d in "
>>> "config %d interface %d altsetting %d ep %d: "
>>> "setting to %d\n",
>>> usb_endpoint_xfer_isoc(&ep->desc) ? "Isoc" : "Int",
>>> le16_to_cpu(desc->wBytesPerInterval),
>>> cfgno, inum, asnum, ep->desc.bEndpointAddress,
>>> max_tx);
>>> ep->ss_ep_comp.wBytesPerInterval = cpu_to_le16(max_tx);
>>> }
>>>
>>> Could you please give me some advice? Thanks.
>>
>> Try it and see if it fixes the problems you see with the network
>> adapters.
>>
Okay, I will verify the effectiveness of this modification and provide
feedback on the results.
I guess that for the scenario where wBytesPerInterval is 0, it should be
solvable. However, for the scenario where wBytesPerInterval is 8 but the
peripheral sends a data length greater than 8 (e.g., 16), there might be
an issue. I will test both of the above scenarios.
>> I saw the Greg said not to change the descriptors and just fail the
>> device, but we already make this sort of change to correct other errors
>> so there doesn't seem to be any reason not to do it here as well.
>> Especially if it allows people to use devices that otherwise would not
>> work.
>
> I didn't realize this was on "real" devices, sorry. I thought this was
> only a fuzzing thing. So yes, fix up the broken descriptor after
> warning about it is the correct thing to do.
>
> thanks,
>
> greg k-h
^ permalink raw reply
* Re: [RFC PATCH 1/2] xhci: prevent automatic endpoint restart after stall or error
From: Thinh Nguyen @ 2026-04-03 1:59 UTC (permalink / raw)
To: stern@rowland.harvard.edu
Cc: Mathias Nyman, Thinh Nguyen, linux-usb@vger.kernel.org,
michal.pecio@gmail.com, oneukum@suse.com,
niklas.neronin@linux.intel.com
In-Reply-To: <07351d72-5cdb-45e8-90af-311a0dc49718@rowland.harvard.edu>
On Wed, Apr 01, 2026, stern@rowland.harvard.edu wrote:
> On Thu, Apr 02, 2026 at 01:08:31AM +0300, Mathias Nyman wrote:
> > On 3/31/26 18:31, stern@rowland.harvard.edu wrote:
> > >
> > > How about this instead? We add a "halted" flag to the usb_host_endpoint
> > > structure, and the core will set this flag whenever a bulk or interrupt
> > > URB gets a status other than 0 (before putting the URB on the bh list).
> > > If an URB has one of these statuses, when its completion handler returns
> > > the core will unlink all the URBs queued to the same endpoint. Finally,
> > > the "halted" flag should be cleared after a completion handler returns
> > > if there are no more unlinked URBs still in the queue or URBs waiting on
> > > the bh list to be given back.
> > >
> > > The result of this is that any URB remaining in the queue when the flag
> > > is cleared must have been submitted by the class driver _after_ the
> > > failing URB's completion handler has run. We can assume the class
> > > driver knows what it's doing in this case.
> > >
> > > The endpoint queue shouldn't be restarted until the "halted" flag is
> > > cleared. Either right away, if there are any URBs in the queue, or not
> > > until the next URB is submitted. Doing this might require a new HCD
> > > callback. (It would also mean the kerneldoc for usb_unlink_urb() would
> > > need to be updated, because the endpoint might restart before all the
> > > completion handlers for the unlinked URBs have run.)
> > >
> > > What I'm trying to do here is come up with a single, consistent proposal
> > > for exactly when halted endpoint queues should restart. Maybe someone
> > > else has a better suggestion.
> >
> > Sounds like a possible solution to me.
> >
> > Just to clarify, core should unlink the remaining URBs queued to that endpoint
> > after setting the "halted" flag, but before URB completion is called.
>
> Above I wrote that the remaining URBs should be unlinked _after_ the
> completion handler is called. If we did the unlinks before then the
> class driver might submit a new URB after the unlinks were finished and
> before the completion handler learned about the transaction error, and
> this new URB then wouldn't get unlinked.
>
> It's a race between completion of one URB and submission of another.
>
> > "Halted" flag should be cleared after URB completion returns, and endpoint
> > should be restarted if there are any pending URBs.
>
> To be clear, the flag should be cleared after the completion handlers
> for _all_ the unlinked URBs (as well as the URB getting the original
> error) have returned.
>
> > This allows the class driver URB completion handler to re-queue the halted URB
> > without core unlinking it.
>
> The completion handler shouldn't do this, because it would mean
> resubmitting without doing a clear-halt first. (Completion handlers
> can't do clear-halts because they run in atomic context.) If it does
> try to do this anyway, I see nothing wrong with the core unlinking the
> resubmitted URB.
>
> (Are you going to ask about verification tests that set the endpoint's
> Halt feature, submit an URB, wait for it to fail with -EPIPE, and then
> submit another URB from within the completion handler? :-) )
>
How about this:
Introduce a halted flag the following conditions:
* Introduce the halted flag in usb_host_endpoint
* The halted flag must be implemented as a bit in a unsigned long so
we can use atomic bit operation
* Only the HCD may set the halted flag, and only upon checking the
first URB completing with a halted status
* Only the USB core may clear the halted flag, and only after
usb_reset_endpoint returns (this makes sure the HCD drained and reset
the endpoint before the flag is cleared and new URBs are accepted)
* The usb_reset_endpoint must be called after clear-halt, SetInterface,
and SetConfiguration.
* The USB core will not attempt to unlink pending URBs due to halted
condition
* The HCD is responsible for completing or canceling queued URBs
when the halted flag is set. Cancelled and newly submitted URBs will
be returned with -EPIPE as long as the halted flag is set
* The class driver is responsible to check the halted flag to
determine whether to initiate error recovery via usb_clear_halt
I'm trying to keep a clear separation of responsibilities between HCD
and the USB core. Also, I try to keep the halted flag more closely match
the state of the endpoint.
Let me know what you think?
BR,
Thinh
^ permalink raw reply
* Re: [RFC PATCH 1/2] xhci: prevent automatic endpoint restart after stall or error
From: stern @ 2026-04-03 2:42 UTC (permalink / raw)
To: Thinh Nguyen
Cc: Mathias Nyman, linux-usb@vger.kernel.org, michal.pecio@gmail.com,
oneukum@suse.com, niklas.neronin@linux.intel.com
In-Reply-To: <20260403015950.lx4n4zdqki37dy27@synopsys.com>
On Fri, Apr 03, 2026 at 01:59:58AM +0000, Thinh Nguyen wrote:
> On Wed, Apr 01, 2026, stern@rowland.harvard.edu wrote:
> > On Thu, Apr 02, 2026 at 01:08:31AM +0300, Mathias Nyman wrote:
> > > On 3/31/26 18:31, stern@rowland.harvard.edu wrote:
> > > >
> > > > How about this instead? We add a "halted" flag to the usb_host_endpoint
> > > > structure, and the core will set this flag whenever a bulk or interrupt
> > > > URB gets a status other than 0 (before putting the URB on the bh list).
> > > > If an URB has one of these statuses, when its completion handler returns
> > > > the core will unlink all the URBs queued to the same endpoint. Finally,
> > > > the "halted" flag should be cleared after a completion handler returns
> > > > if there are no more unlinked URBs still in the queue or URBs waiting on
> > > > the bh list to be given back.
> > > >
> > > > The result of this is that any URB remaining in the queue when the flag
> > > > is cleared must have been submitted by the class driver _after_ the
> > > > failing URB's completion handler has run. We can assume the class
> > > > driver knows what it's doing in this case.
> > > >
> > > > The endpoint queue shouldn't be restarted until the "halted" flag is
> > > > cleared. Either right away, if there are any URBs in the queue, or not
> > > > until the next URB is submitted. Doing this might require a new HCD
> > > > callback. (It would also mean the kerneldoc for usb_unlink_urb() would
> > > > need to be updated, because the endpoint might restart before all the
> > > > completion handlers for the unlinked URBs have run.)
> > > >
> > > > What I'm trying to do here is come up with a single, consistent proposal
> > > > for exactly when halted endpoint queues should restart. Maybe someone
> > > > else has a better suggestion.
> How about this:
>
> Introduce a halted flag the following conditions:
>
> * Introduce the halted flag in usb_host_endpoint
> * The halted flag must be implemented as a bit in a unsigned long so
> we can use atomic bit operation
I don't see why it needs to use atomic operations. Unless you're
thinking that we might want to add other bitflags into the same unsigned
long?
> * Only the HCD may set the halted flag, and only upon checking the
> first URB completing with a halted status
Every status other than 0 should mean that the endpoint's queue is
halted. But not all statuses require a clear-halt or reset-endpoint to
recover. For instance, a short transfer when the URB_SHORT_NOT_OK flag
is set.
Why do you want the HCD to set the flag instead of
usb_hcd_giveback_urb()? Just one central place is simpler than in every
HCD.
> * Only the USB core may clear the halted flag, and only after
> usb_reset_endpoint returns (this makes sure the HCD drained and reset
> the endpoint before the flag is cleared and new URBs are accepted)
> * The usb_reset_endpoint must be called after clear-halt, SetInterface,
> and SetConfiguration.
That's easy to do just by adding it into the appropriate core routines.
> * The USB core will not attempt to unlink pending URBs due to halted
> condition
> * The HCD is responsible for completing or canceling queued URBs
> when the halted flag is set. Cancelled and newly submitted URBs will
> be returned with -EPIPE as long as the halted flag is set
Why make the HCD responsible for draining the queue? It's like setting
the halted flag; one central place is simpler and less error-prone than
lots of separate places.
For newly submitted URBs, should the submission fail with -EPIPE, or
should the submission succeed and then the URB complete with -EPIPE?
The first is simpler, but drivers probably aren't prepared for it -- it
would mean adding error handling to the submission code as well as to
the completion handler code.
(Actually, that wouldn't matter unless the driver was queuing up
multiple URBs, in which case it should be prepared to handle submission
errors in the middle.)
> * The class driver is responsible to check the halted flag to
> determine whether to initiate error recovery via usb_clear_halt
>
> I'm trying to keep a clear separation of responsibilities between HCD
> and the USB core. Also, I try to keep the halted flag more closely match
> the state of the endpoint.
>
> Let me know what you think?
Making the flag match the endpoint state is a good idea. But there is
some ambiguity: Do you mean the state in the device, or the state in the
HC hardware, or the state in the HCD? After all, these aren't always
the same. For instance, unlinking an URB won't affect the device's
state but it will affect the state on the host side.
Alan Stern
^ permalink raw reply
* Re: [PATCH v1 2/2] mfd: Add Host Interface (HIF) support for Nuvoton NCT6694
From: Ming Yu @ 2026-04-03 4:46 UTC (permalink / raw)
To: Marc Kleine-Budde
Cc: tmyu0, linusw, brgl, linux, andi.shyti, lee, mailhol,
alexandre.belloni, wim, linux-kernel, linux-gpio, linux-i2c,
linux-can, netdev, linux-watchdog, linux-hwmon, linux-rtc,
linux-usb
In-Reply-To: <20260402-warping-chameleon-of-prowess-9df780-mkl@pengutronix.de>
Dear Marc,
Thanks for the review.
Marc Kleine-Budde <mkl@pengutronix.de> 於 2026年4月2日週四 下午7:05寫道：
>
> > +struct nct6694_sio_data {
> > + enum nct6694_chips chip;
> > + int sioreg; /* Super-I/O index port */
> > +
> > + /* Super-I/O access functions */
> > + int (*sio_enter)(struct nct6694_sio_data *sio_data);
> > + void (*sio_exit)(struct nct6694_sio_data *sio_data);
> > + void (*sio_select)(struct nct6694_sio_data *sio_data, int ld);
> > + int (*sio_inb)(struct nct6694_sio_data *sio_data, int reg);
> > + int (*sio_inw)(struct nct6694_sio_data *sio_data, int reg);
> > + void (*sio_outb)(struct nct6694_sio_data *sio_data, int reg, int val);
>
> The signatures of the function look a bit strange. I expect functions
> reading/writing bytes use u8 not int, register offsets should probably
> be an unsigned int.
>
> Why do you have pointers to the access functions? Why not use them
> directly?
>
These helpers were originally meant to be used by sub-drivers for SIO
access, but the implementation later converged so that all SIO access
is done in the MFD driver itself. In the next version, I will remove
the function pointers and simplify the interface accordingly.
I will also adjust the types as suggested.
Regards,
Ming
^ permalink raw reply
* [usb:usb-testing] BUILD SUCCESS WITH UNVERIFIED WARNING 25e531b422dc2ac90cdae3b6e74b5cdeb081440d
From: kernel test robot @ 2026-04-03 5:18 UTC (permalink / raw)
To: Greg Kroah-Hartman; +Cc: linux-usb
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git usb-testing
branch HEAD: 25e531b422dc2ac90cdae3b6e74b5cdeb081440d usb: xhci: Make usb_host_endpoint.hcpriv survive endpoint_disable()
Unverified Warning (likely false positive, kindly check if interested):
drivers/usb/typec/tcpm/fusb302.c:1790 fusb302_probe() warn: 'chip->gpio_int_n_irq' from request_threaded_irq() not released on lines: 1779.
Warning ids grouped by kconfigs:
recent_errors
`-- x86_64-randconfig-161-20260402
`-- drivers-usb-typec-tcpm-fusb302.c-fusb302_probe()-warn:chip-gpio_int_n_irq-from-request_threaded_irq()-not-released-on-lines:.
elapsed time: 915m
configs tested: 185
configs skipped: 3
tested configs:
alpha allnoconfig gcc-15.2.0
alpha allyesconfig gcc-15.2.0
alpha defconfig gcc-15.2.0
arc allmodconfig clang-16
arc allnoconfig gcc-15.2.0
arc allyesconfig clang-23
arc defconfig gcc-15.2.0
arc randconfig-001-20260403 gcc-10.5.0
arc randconfig-002-20260403 gcc-10.5.0
arm allnoconfig gcc-15.2.0
arm allyesconfig clang-16
arm defconfig gcc-15.2.0
arm orion5x_defconfig clang-23
arm randconfig-001-20260403 gcc-10.5.0
arm randconfig-002-20260403 gcc-10.5.0
arm randconfig-003-20260403 gcc-10.5.0
arm randconfig-004-20260403 gcc-10.5.0
arm64 allmodconfig clang-23
arm64 allnoconfig gcc-15.2.0
arm64 defconfig gcc-15.2.0
arm64 randconfig-001-20260403 gcc-13.4.0
arm64 randconfig-002-20260403 gcc-13.4.0
arm64 randconfig-003-20260403 gcc-13.4.0
arm64 randconfig-004-20260403 gcc-13.4.0
csky allmodconfig gcc-15.2.0
csky allnoconfig gcc-15.2.0
csky defconfig gcc-15.2.0
csky randconfig-001-20260403 gcc-13.4.0
csky randconfig-002-20260403 gcc-13.4.0
hexagon allmodconfig gcc-15.2.0
hexagon allnoconfig gcc-15.2.0
hexagon defconfig gcc-15.2.0
hexagon randconfig-001-20260403 clang-23
hexagon randconfig-002-20260403 clang-23
i386 allmodconfig clang-20
i386 allmodconfig gcc-14
i386 allnoconfig gcc-15.2.0
i386 allyesconfig clang-20
i386 allyesconfig gcc-14
i386 buildonly-randconfig-001-20260403 gcc-14
i386 buildonly-randconfig-002-20260403 gcc-14
i386 buildonly-randconfig-003-20260403 gcc-14
i386 buildonly-randconfig-004-20260403 gcc-14
i386 buildonly-randconfig-005-20260403 gcc-14
i386 buildonly-randconfig-006-20260403 gcc-14
i386 defconfig gcc-15.2.0
i386 randconfig-001-20260403 gcc-14
i386 randconfig-002-20260403 gcc-14
i386 randconfig-003-20260403 gcc-14
i386 randconfig-004-20260403 gcc-14
i386 randconfig-005-20260403 gcc-14
i386 randconfig-006-20260403 gcc-14
i386 randconfig-007-20260403 gcc-14
i386 randconfig-011-20260403 clang-20
i386 randconfig-012-20260403 clang-20
i386 randconfig-013-20260403 clang-20
i386 randconfig-014-20260403 clang-20
i386 randconfig-015-20260403 clang-20
i386 randconfig-016-20260403 clang-20
i386 randconfig-017-20260403 clang-20
loongarch allmodconfig clang-23
loongarch allnoconfig gcc-15.2.0
loongarch defconfig clang-19
loongarch randconfig-001-20260403 clang-23
loongarch randconfig-002-20260403 clang-23
m68k allmodconfig gcc-15.2.0
m68k allnoconfig gcc-15.2.0
m68k allyesconfig clang-16
m68k defconfig clang-19
microblaze allnoconfig gcc-15.2.0
microblaze allyesconfig gcc-15.2.0
microblaze defconfig clang-19
mips allmodconfig gcc-15.2.0
mips allnoconfig gcc-15.2.0
mips allyesconfig gcc-15.2.0
nios2 allmodconfig clang-23
nios2 allmodconfig gcc-11.5.0
nios2 allnoconfig clang-23
nios2 allnoconfig gcc-11.5.0
nios2 defconfig clang-19
nios2 randconfig-001-20260403 clang-23
nios2 randconfig-002-20260403 clang-23
openrisc allmodconfig clang-23
openrisc allmodconfig gcc-15.2.0
openrisc allnoconfig clang-23
openrisc allnoconfig gcc-15.2.0
openrisc defconfig gcc-15.2.0
parisc allmodconfig gcc-15.2.0
parisc allnoconfig clang-23
parisc allnoconfig gcc-15.2.0
parisc allyesconfig clang-19
parisc allyesconfig gcc-15.2.0
parisc defconfig gcc-15.2.0
parisc randconfig-001-20260403 gcc-10.5.0
parisc randconfig-002-20260403 gcc-10.5.0
parisc64 defconfig clang-19
powerpc allmodconfig gcc-15.2.0
powerpc allnoconfig clang-23
powerpc allnoconfig gcc-15.2.0
powerpc randconfig-001-20260403 gcc-10.5.0
powerpc randconfig-002-20260403 gcc-10.5.0
powerpc tqm5200_defconfig gcc-15.2.0
powerpc64 randconfig-001-20260403 gcc-10.5.0
powerpc64 randconfig-002-20260403 gcc-10.5.0
riscv allmodconfig clang-23
riscv allnoconfig clang-23
riscv allnoconfig gcc-15.2.0
riscv allyesconfig clang-16
riscv defconfig gcc-15.2.0
riscv randconfig-001-20260403 clang-23
riscv randconfig-002-20260403 clang-23
s390 allmodconfig clang-18
s390 allmodconfig clang-19
s390 allnoconfig clang-23
s390 allyesconfig gcc-15.2.0
s390 defconfig gcc-15.2.0
s390 randconfig-001-20260403 clang-23
s390 randconfig-002-20260403 clang-23
sh allmodconfig gcc-15.2.0
sh allnoconfig clang-23
sh allnoconfig gcc-15.2.0
sh allyesconfig clang-19
sh allyesconfig gcc-15.2.0
sh defconfig gcc-14
sh randconfig-001-20260403 clang-23
sh randconfig-002-20260403 clang-23
sparc allnoconfig clang-23
sparc allnoconfig gcc-15.2.0
sparc defconfig gcc-15.2.0
sparc randconfig-001-20260403 clang-20
sparc randconfig-002-20260403 clang-20
sparc64 allmodconfig clang-23
sparc64 defconfig gcc-14
sparc64 randconfig-001-20260403 clang-20
sparc64 randconfig-002-20260403 clang-20
um allmodconfig clang-19
um allnoconfig clang-23
um allyesconfig gcc-15.2.0
um defconfig gcc-14
um i386_defconfig gcc-14
um randconfig-001-20260403 clang-20
um randconfig-002-20260403 clang-20
um x86_64_defconfig gcc-14
x86_64 allmodconfig clang-20
x86_64 allnoconfig clang-20
x86_64 allnoconfig clang-23
x86_64 allyesconfig clang-20
x86_64 buildonly-randconfig-001-20260403 clang-20
x86_64 buildonly-randconfig-002-20260403 clang-20
x86_64 buildonly-randconfig-003-20260403 clang-20
x86_64 buildonly-randconfig-004-20260403 clang-20
x86_64 buildonly-randconfig-005-20260403 clang-20
x86_64 buildonly-randconfig-006-20260403 clang-20
x86_64 defconfig gcc-14
x86_64 kexec clang-20
x86_64 randconfig-001-20260403 clang-20
x86_64 randconfig-002-20260403 clang-20
x86_64 randconfig-003-20260403 clang-20
x86_64 randconfig-004-20260403 clang-20
x86_64 randconfig-005-20260403 clang-20
x86_64 randconfig-006-20260403 clang-20
x86_64 randconfig-011-20260403 gcc-14
x86_64 randconfig-012-20260403 gcc-14
x86_64 randconfig-013-20260403 gcc-14
x86_64 randconfig-014-20260403 gcc-14
x86_64 randconfig-015-20260403 gcc-14
x86_64 randconfig-016-20260403 gcc-14
x86_64 randconfig-071-20260403 gcc-14
x86_64 randconfig-072-20260403 gcc-14
x86_64 randconfig-073-20260403 gcc-14
x86_64 randconfig-074-20260403 gcc-14
x86_64 randconfig-075-20260403 gcc-14
x86_64 randconfig-076-20260403 gcc-14
x86_64 rhel-9.4 clang-20
x86_64 rhel-9.4-bpf gcc-14
x86_64 rhel-9.4-func clang-20
x86_64 rhel-9.4-kselftests clang-20
x86_64 rhel-9.4-kunit gcc-14
x86_64 rhel-9.4-ltp gcc-14
x86_64 rhel-9.4-rust clang-20
xtensa allnoconfig clang-23
xtensa allnoconfig gcc-15.2.0
xtensa allyesconfig clang-23
xtensa randconfig-001-20260403 clang-20
xtensa randconfig-002-20260403 clang-20
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
^ permalink raw reply
* Re: [PATCH] usb: cdnsp: Add support for device-only configuration
From: Peter Chen (CIX) @ 2026-04-03 5:56 UTC (permalink / raw)
To: pawell
Cc: Roger Quadros, Greg Kroah-Hartman, Bjorn Helgaas, linux-usb,
linux-kernel, linux-pci
In-Reply-To: <20260331-device_only-v1-1-00378b80365c@cadence.com>
On 26-03-31 10:19:11, Pawel Laszczak via B4 Relay wrote:
> From: Pawel Laszczak <pawell@cadence.com>
>
> This patch introduces support for operating the Cadence USBSSP (cdnsp)
> controller in a peripheral-only mode, bypassing the Dual-Role Device (DRD)
> logic.
Is it possible the SoC customer (not Cadence internal) has this configuration
too?
>
> The change in BAR indexing (from BAR 2 to BAR 1) is a direct
> consequence of switching from 64-bit to 32-bit addressing in the
> Peripheral-only configuration.
>
> Tested on PCI platform with Device-only configuration. Platform-side
> changes are included to support the PCI glue layer's property injection.
>
> Signed-off-by: Pawel Laszczak <pawell@cadence.com>
> ---
> NOTE: This patch depends on Peter Chen's series "usb: cdns3: Add
> USBSSP platform driver support", which was recently accepted by
> Greg into the usb-testing branch (commit 6076388ca1ed).
> ---
> drivers/usb/cdns3/cdns3-plat.c | 24 ++++++++++++---------
> drivers/usb/cdns3/cdnsp-pci.c | 47 ++++++++++++++++++++++++++++++++++--------
> drivers/usb/cdns3/core.c | 3 ++-
> drivers/usb/cdns3/core.h | 5 ++++-
> drivers/usb/cdns3/drd.c | 16 ++++++++++++--
> include/linux/pci_ids.h | 1 +
> 6 files changed, 73 insertions(+), 23 deletions(-)
>
> diff --git a/drivers/usb/cdns3/cdns3-plat.c b/drivers/usb/cdns3/cdns3-plat.c
> index 71c612e27b73..33746e672cda 100644
> --- a/drivers/usb/cdns3/cdns3-plat.c
> +++ b/drivers/usb/cdns3/cdns3-plat.c
> @@ -75,6 +75,7 @@ static int cdns3_plat_probe(struct platform_device *pdev)
> if (cdns->pdata && cdns->pdata->override_apb_timeout)
> cdns->override_apb_timeout = cdns->pdata->override_apb_timeout;
>
> + cdns->no_drd = device_property_read_bool(dev, "no_drd");
> platform_set_drvdata(pdev, cdns);
>
> ret = platform_get_irq_byname(pdev, "host");
> @@ -107,21 +108,23 @@ static int cdns3_plat_probe(struct platform_device *pdev)
>
> cdns->dev_regs = regs;
>
> - cdns->otg_irq = platform_get_irq_byname(pdev, "otg");
> - if (cdns->otg_irq < 0)
> - return dev_err_probe(dev, cdns->otg_irq,
> - "Failed to get otg IRQ\n");
> + if (!cdns->no_drd) {
> + cdns->otg_irq = platform_get_irq_byname(pdev, "otg");
> + if (cdns->otg_irq < 0)
> + return dev_err_probe(dev, cdns->otg_irq,
> + "Failed to get otg IRQ\n");
I suggest making "otg" register/irq as optional, if it is not existed,
we set "no_drd" flag for cdns structure. In that case, we do not need to
add new property.
>
> - res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "otg");
> - if (!res) {
> - dev_err(dev, "couldn't get otg resource\n");
> - return -ENXIO;
> + res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "otg");
> + if (!res) {
> + dev_err(dev, "couldn't get otg resource\n");
> + return -ENXIO;
> + }
> +
> + cdns->otg_res = *res;
> }
>
> cdns->phyrst_a_enable = device_property_read_bool(dev, "cdns,phyrst-a-enable");
>
> - cdns->otg_res = *res;
> -
> cdns->wakeup_irq = platform_get_irq_byname_optional(pdev, "wakeup");
> if (cdns->wakeup_irq == -EPROBE_DEFER)
> return cdns->wakeup_irq;
> @@ -158,6 +161,7 @@ static int cdns3_plat_probe(struct platform_device *pdev)
> goto err_cdns_init;
>
> cdns->gadget_init = cdns3_plat_gadget_init;
> +
Not related to this change.
> ret = cdns_core_init_role(cdns);
> if (ret)
> goto err_cdns_init;
> diff --git a/drivers/usb/cdns3/cdnsp-pci.c b/drivers/usb/cdns3/cdnsp-pci.c
> index 432007cfe695..e20c59ceb8a4 100644
> --- a/drivers/usb/cdns3/cdnsp-pci.c
> +++ b/drivers/usb/cdns3/cdnsp-pci.c
> @@ -19,6 +19,7 @@
>
> struct cdnsp_wrap {
> struct platform_device *plat_dev;
> + struct property_entry prop[3];
> struct resource dev_res[6];
> int devfn;
> };
> @@ -29,10 +30,15 @@ struct cdnsp_wrap {
> #define RES_HOST_ID 3
> #define RES_DEV_ID 4
> #define RES_DRD_ID 5
> -
> +/* DRD PCI configuration - 64-bit addressing */
> +/* First PCI function */
> #define PCI_BAR_HOST 0
> -#define PCI_BAR_OTG 0
> #define PCI_BAR_DEV 2
> +/* Second PCI function */
> +#define PCI_BAR_OTG 0
> +/* Device only PCI configuration - 32-bit addressing */
> +/* First PCI function */
> +#define PCI_BAR_ONLY_DEV 1
>
> #define PCI_DEV_FN_HOST_DEVICE 0
> #define PCI_DEV_FN_OTG 1
> @@ -65,6 +71,7 @@ static int cdnsp_pci_probe(struct pci_dev *pdev,
> struct cdnsp_wrap *wrap;
> struct resource *res;
> struct pci_dev *func;
> + bool no_drd = false;
> int ret = 0;
>
> /*
> @@ -75,11 +82,14 @@ static int cdnsp_pci_probe(struct pci_dev *pdev,
> pdev->devfn != PCI_DEV_FN_OTG))
> return -EINVAL;
>
> + if (pdev->device == PCI_DEVICE_ID_CDNS_UDC_USBSSP)
> + no_drd = true;
> +
> func = cdnsp_get_second_fun(pdev);
> - if (!func)
> + if (!func && !no_drd)
> return -EINVAL;
>
> - if (func->class == PCI_CLASS_SERIAL_USB_XHCI ||
> + if ((func && func->class == PCI_CLASS_SERIAL_USB_XHCI) ||
> pdev->class == PCI_CLASS_SERIAL_USB_XHCI) {
> ret = -EINVAL;
> goto put_pci;
> @@ -93,7 +103,7 @@ static int cdnsp_pci_probe(struct pci_dev *pdev,
>
> pci_set_master(pdev);
>
> - if (pci_is_enabled(func)) {
> + if (func && pci_is_enabled(func)) {
> wrap = pci_get_drvdata(func);
> } else {
> wrap = kzalloc_obj(*wrap);
> @@ -106,10 +116,13 @@ static int cdnsp_pci_probe(struct pci_dev *pdev,
> res = wrap->dev_res;
>
> if (pdev->devfn == PCI_DEV_FN_HOST_DEVICE) {
> + int bar_dev = no_drd ? PCI_BAR_ONLY_DEV : PCI_BAR_DEV;
> +
> /* Function 0: host(BAR_0) + device(BAR_2). */
> dev_dbg(&pdev->dev, "Initialize Device resources\n");
> - res[RES_DEV_ID].start = pci_resource_start(pdev, PCI_BAR_DEV);
> - res[RES_DEV_ID].end = pci_resource_end(pdev, PCI_BAR_DEV);
> +
> + res[RES_DEV_ID].start = pci_resource_start(pdev, bar_dev);
> + res[RES_DEV_ID].end = pci_resource_end(pdev, bar_dev);
> res[RES_DEV_ID].name = "dev";
> res[RES_DEV_ID].flags = IORESOURCE_MEM;
> dev_dbg(&pdev->dev, "USBSSP-DEV physical base addr: %pa\n",
> @@ -145,9 +158,20 @@ static int cdnsp_pci_probe(struct pci_dev *pdev,
> wrap->dev_res[RES_IRQ_OTG_ID].flags = IORESOURCE_IRQ;
> }
>
> - if (pci_is_enabled(func)) {
> + if (no_drd || pci_is_enabled(func)) {
> + u8 idx = 0;
> +
> /* set up platform device info */
> pdata.override_apb_timeout = CHICKEN_APB_TIMEOUT_VALUE;
> + if (no_drd) {
> + wrap->prop[idx++] = PROPERTY_ENTRY_STRING("dr_mode", "peripheral");
> + wrap->prop[idx++] = PROPERTY_ENTRY_BOOL("no_drd");
> + } else {
> + wrap->prop[idx++] = PROPERTY_ENTRY_STRING("dr_mode", "otg");
> + wrap->prop[idx++] = PROPERTY_ENTRY_BOOL("usb-role-switch");
> + }
> +
> + wrap->prop[idx] = (struct property_entry){ };
> memset(&plat_info, 0, sizeof(plat_info));
> plat_info.parent = &pdev->dev;
> plat_info.fwnode = pdev->dev.fwnode;
> @@ -158,6 +182,7 @@ static int cdnsp_pci_probe(struct pci_dev *pdev,
> plat_info.dma_mask = pdev->dma_mask;
> plat_info.data = &pdata;
> plat_info.size_data = sizeof(pdata);
> + plat_info.properties = wrap->prop;
> wrap->devfn = pdev->devfn;
> /* register platform device */
> wrap->plat_dev = platform_device_register_full(&plat_info);
> @@ -185,13 +210,17 @@ static void cdnsp_pci_remove(struct pci_dev *pdev)
> if (wrap->devfn == pdev->devfn)
> platform_device_unregister(wrap->plat_dev);
>
> - if (!pci_is_enabled(func))
> + if (!func || !pci_is_enabled(func))
> kfree(wrap);
>
> pci_dev_put(func);
> }
>
> static const struct pci_device_id cdnsp_pci_ids[] = {
> + { PCI_DEVICE(PCI_VENDOR_ID_CDNS, PCI_DEVICE_ID_CDNS_UDC_USBSSP),
> + .class = PCI_CLASS_SERIAL_USB_DEVICE },
> + { PCI_DEVICE(PCI_VENDOR_ID_CDNS, PCI_DEVICE_ID_CDNS_UDC_USBSSP),
> + .class = PCI_CLASS_SERIAL_USB_CDNS },
> { PCI_DEVICE(PCI_VENDOR_ID_CDNS, PCI_DEVICE_ID_CDNS_USBSSP),
> .class = PCI_CLASS_SERIAL_USB_DEVICE },
> { PCI_DEVICE(PCI_VENDOR_ID_CDNS, PCI_DEVICE_ID_CDNS_USBSSP),
> diff --git a/drivers/usb/cdns3/core.c b/drivers/usb/cdns3/core.c
> index 10f00b6c3c83..72f7acba6258 100644
> --- a/drivers/usb/cdns3/core.c
> +++ b/drivers/usb/cdns3/core.c
> @@ -71,7 +71,8 @@ static void cdns_role_stop(struct cdns *cdns)
> static void cdns_exit_roles(struct cdns *cdns)
> {
> cdns_role_stop(cdns);
> - cdns_drd_exit(cdns);
> + if (!cdns->no_drd)
> + cdns_drd_exit(cdns);
> }
>
> /**
> diff --git a/drivers/usb/cdns3/core.h b/drivers/usb/cdns3/core.h
> index dc8c4137de15..6abe231f4559 100644
> --- a/drivers/usb/cdns3/core.h
> +++ b/drivers/usb/cdns3/core.h
> @@ -80,9 +80,11 @@ struct cdns3_platform_data {
> * @pdata: platform data from glue layer
> * @lock: spinlock structure
> * @xhci_plat_data: xhci private data structure pointer
> + * @gadget_init: pointer to gadget initialization function
> * @override_apb_timeout: hold value of APB timeout. For value 0 the default
> * value in CHICKEN_BITS_3 will be preserved.
> - * @gadget_init: pointer to gadget initialization function
> + * @no_drd: DRD register block is inaccessible - driver handles only
> + * device mode.
> */
> struct cdns {
> struct device *dev;
> @@ -122,6 +124,7 @@ struct cdns {
> struct xhci_plat_priv *xhci_plat_data;
> int (*gadget_init)(struct cdns *cdns);
> u32 override_apb_timeout;
> + bool no_drd;
> };
>
> int cdns_hw_role_switch(struct cdns *cdns);
> diff --git a/drivers/usb/cdns3/drd.c b/drivers/usb/cdns3/drd.c
> index 84fb38a5723a..38f3051c2188 100644
> --- a/drivers/usb/cdns3/drd.c
> +++ b/drivers/usb/cdns3/drd.c
> @@ -107,7 +107,7 @@ void cdns_clear_vbus(struct cdns *cdns)
> {
> u32 reg;
>
> - if (cdns->version != CDNSP_CONTROLLER_V2)
> + if (cdns->version != CDNSP_CONTROLLER_V2 || cdns->no_drd)
> return;
>
> reg = readl(&cdns->otg_cdnsp_regs->override);
> @@ -120,7 +120,7 @@ void cdns_set_vbus(struct cdns *cdns)
> {
> u32 reg;
>
> - if (cdns->version != CDNSP_CONTROLLER_V2)
> + if (cdns->version != CDNSP_CONTROLLER_V2 || cdns->no_drd)
> return;
>
> reg = readl(&cdns->otg_cdnsp_regs->override);
> @@ -234,6 +234,9 @@ int cdns_drd_gadget_on(struct cdns *cdns)
> u32 ready_bit;
> int ret, val;
>
> + if (cdns->no_drd)
> + return 0;
> +
You may add similar logic for cdns_power_is_lost and cdns_get_id.
> /* switch OTG core */
> writel(OTGCMD_DEV_BUS_REQ | reg, &cdns->otg_regs->cmd);
>
> @@ -265,6 +268,9 @@ void cdns_drd_gadget_off(struct cdns *cdns)
> {
> u32 val;
>
> + if (cdns->no_drd)
> + return;
> +
> /*
> * Driver should wait at least 10us after disabling Device
> * before turning-off Device (DEV_BUS_DROP).
> @@ -392,6 +398,12 @@ int cdns_drd_init(struct cdns *cdns)
> u32 state, reg;
> int ret;
>
> + 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?
> + 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
^ permalink raw reply
* Re: [PATCH v2] usb: typec: fusb302: Switch to threaded IRQ handler
From: Greg Kroah-Hartman @ 2026-04-03 6:36 UTC (permalink / raw)
To: Alexey Charkov
Cc: Heikki Krogerus, Sebastian Reichel, Hans de Goede,
Sebastian Andrzej Siewior, linux-usb, linux-kernel, stable
In-Reply-To: <20260317-fusb302-irq-v2-1-dbabd5c5c961@flipper.net>
On Tue, Mar 17, 2026 at 08:30:15PM +0400, Alexey Charkov wrote:
> FUSB302 fails to probe with -EINVAL if its interrupt line is connected via
> an I2C GPIO expander, such as TI TCA6416.
>
> Switch the interrupt handler to a threaded one, which also works behind
> such GPIO expanders.
>
> Cc: stable@vger.kernel.org
> Fixes: 309b6341d557 ("usb: typec: fusb302: Revert incorrect threaded irq fix")
> Signed-off-by: Alexey Charkov <alchark@flipper.net>
> ---
> Changes in v2:
> - Re-added the IRQF_ONESHOT flag to the request_threaded_irq() call
> (thanks Hans de Goede and Sebastian Andrzej Siewior)
> - Link to v1: https://lore.kernel.org/r/20260311-fusb302-irq-v1-1-7e7105706629@flipper.net
> ---
> drivers/usb/typec/tcpm/fusb302.c | 5 +++--
> 1 file changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/usb/typec/tcpm/fusb302.c b/drivers/usb/typec/tcpm/fusb302.c
> index ce7069fb4be6..889c4c29c1b8 100644
> --- a/drivers/usb/typec/tcpm/fusb302.c
> +++ b/drivers/usb/typec/tcpm/fusb302.c
> @@ -1764,8 +1764,9 @@ static int fusb302_probe(struct i2c_client *client)
> goto destroy_workqueue;
> }
>
> - ret = request_irq(chip->gpio_int_n_irq, fusb302_irq_intn,
> - IRQF_TRIGGER_LOW, "fsc_interrupt_int_n", chip);
> + ret = request_threaded_irq(chip->gpio_int_n_irq, NULL, fusb302_irq_intn,
> + IRQF_ONESHOT | IRQF_TRIGGER_LOW,
> + "fsc_interrupt_int_n", chip);
> if (ret < 0) {
> dev_err(dev, "cannot request IRQ for GPIO Int_N, ret=%d", ret);
> goto tcpm_unregister_port;
>
I'll take this, but the testing systems rightly point out that
chip->gpio_int_n_irq may NOT be initialized before this call is made in
some situations, so this whole irq handler might never be set up.
I know your change didn't cause that logic bug to show up, but can you
send a patch to fix that, as you have the ability to test these types of
changes?
thanks,
greg k-h
^ permalink raw reply
* Re: [usb:usb-testing] BUILD SUCCESS WITH UNVERIFIED WARNING 25e531b422dc2ac90cdae3b6e74b5cdeb081440d
From: Greg Kroah-Hartman @ 2026-04-03 6:37 UTC (permalink / raw)
To: kernel test robot; +Cc: linux-usb
In-Reply-To: <202604031342.WrjEctjz-lkp@intel.com>
On Fri, Apr 03, 2026 at 01:18:52PM +0800, kernel test robot wrote:
> tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git usb-testing
> branch HEAD: 25e531b422dc2ac90cdae3b6e74b5cdeb081440d usb: xhci: Make usb_host_endpoint.hcpriv survive endpoint_disable()
>
> Unverified Warning (likely false positive, kindly check if interested):
>
> drivers/usb/typec/tcpm/fusb302.c:1790 fusb302_probe() warn: 'chip->gpio_int_n_irq' from request_threaded_irq() not released on lines: 1779.
Nice, this is an older issue, good catch! But not directly related to
the change that is currently in this tree at the moment.
thanks,
greg k-h
^ permalink raw reply
* Re: [PATCH] usb: core: Fix bandwidth for devices with invalid wBytesPerInterval
From: Michal Pecio @ 2026-04-03 7:16 UTC (permalink / raw)
To: Xuetao (kirin); +Cc: gregkh, linux-usb, linux-kernel, caiyadong, stable
In-Reply-To: <85ad518a-f87f-4ca6-a11c-1ccc37d60bd1@huawei.com>
On Thu, 2 Apr 2026 19:55:16 +0800, Xuetao (kirin) wrote:
> > Any other examples besides AX88179?
>
> We tested 18 different USB 3.0 docks, but they only contained two
> different types of USB 3.0 Ethernet devices based on VID/PID.
> The dwc3 controller works fine with all of the devices mentioned
> above. The other USB host controller works fine with all 12 Realtek
> devices, but fails with all 6 ASIX devices.
>
> 1. Realtek USB 10/100/1000 LAN (12 devices)
> All 12 devices share the same VID/PID and descriptor values.
>
> VID = 0x0BDA, PID = 0x8153
> wMaxPacketSize = 0x10
> bMaxBurst = 0
> wBytesPerInterval = 0x8
My RTL8153 has this endpoint for its default proprietary configuration:
bEndpointAddress 0x83 EP 3 IN
bmAttributes 3
Transfer Type Interrupt
Synch Type None
Usage Type Data
wMaxPacketSize 0x0002 1x 2 bytes
bInterval 8
bMaxBurst 0
wBytesPerInterval 2
which should be problem-free, and this for its CDC configuration:
bEndpointAddress 0x83 EP 3 IN
bmAttributes 3
Transfer Type Interrupt
Synch Type None
Usage Type Data
wMaxPacketSize 0x0010 1x 16 bytes
bInterval 8
bMaxBurst 0
wBytesPerInterval 8
The CDC configuration needs to be enabled with a patch, I'm not sure
if there is any other way. It will then use the r8153_ecm driver.
--- a/drivers/net/usb/r8152.c
+++ b/drivers/net/usb/r8152.c
@@ -9641,6 +9641,7 @@ static int rtl_fw_init(struct r8152 *tp)
static u8 __rtl_get_hw_ver(struct usb_device *udev)
{
+ return 0;
u32 ocp_data = 0;
__le32 *tmp;
u8 version;
> 2. ASIX AX88179 USB 3.0 to Gigabit Ethernet Adapter (6 devices)
> All 6 devices share the same VID/PID.
>
> VID = 0x0B95, PID = 0x1790
> (a) 4 devices:
> wMaxPacketSize = 0x10
> bMaxBurst = 0
> wBytesPerInterval = 0x0
This looks like my AX88179 and it's obviously broken.
> (b) 2 devices:
> wMaxPacketSize = 0x10
> bMaxBurst = 0
> wBytesPerInterval = 0x8
But this is odd. When I use mine, I see that the driver submits 8 byte
URBs and they complete successfully with 8 bytes received, no babble.
ffff888100981b40 3364969734 S Ii:2:010:1 -115:1024 8 <
ffff888100981b40 3365097706 C Ii:2:010:1 0:1024 8 = a1000800 79490000
So I think this should work even with bandwidth reservation set to 8.
Can you check what happens here, before and after your patch?
Regards,
Michal
^ permalink raw reply
* Re: [PATCH] usb: cdns3: attempt to fix Kconfig dependencies
From: Peter Chen (CIX) @ 2026-04-03 7:50 UTC (permalink / raw)
To: Arnd Bergmann, Greg Kroah-Hartman
Cc: Pawel Laszczak, Arnd Bergmann, Roger Quadros, linux-usb,
linux-kernel
In-Reply-To: <20260402141008.2691819-1-arnd@kernel.org>
On 26-04-02 16:09:55, Arnd Bergmann wrote:
> From: Arnd Bergmann <arnd@arndb.de>
>
> The way that dependencies between host and gadget mode, as well as cdns3
> and cdnsp were handled was rather fragile before commit 6076388ca1ed
> ("usb: cdns3: Add USBSSP platform driver support").
>
> After those changes, I get randconfig build failures:
>
> arm-linux-gnueabi-ld: drivers/usb/cdns3/cdnsp-gadget.o: in function `__cdnsp_gadget_init':
> cdnsp-gadget.c:(.text+0x12da): undefined reference to `cdns_drd_gadget_on'
> arm-linux-gnueabi-ld: drivers/usb/cdns3/cdnsp-gadget.o: in function `cdnsp_gadget_pullup':
> cdnsp-gadget.c:(.text+0x3030): undefined reference to `cdns_clear_vbus'
> arm-linux-gnueabi-ld: cdnsp-gadget.c:(.text+0x3138): undefined reference to `cdns_set_vbus'
> arm-linux-gnueabi-ld: drivers/usb/cdns3/cdnsp-gadget.o: in function `cdnsp_gadget_exit':
> cdnsp-gadget.c:(.text+0xe0): undefined reference to `cdns_drd_gadget_off'
>
> and I see additional configurations that are broken. The main problem
> here is that the 'common' module links against both host and gadget
> support if they are enabled, but there are insufficient protections
> agains it being built-in if only one of them is built-in and the other
> is in a loadable module, causing link failures.
>
> The use of IS_REACHABLE() in gadget-export.h works around a similar
> problem if one of cdns3 and cdnsp is built-in but the other one is
> =m. This one is worse because instead of a clear link failure, the
> logic just makes it not work at all despite support being enabled.
>
> To improve this mess, throw out both the Makefile hacks and the
> IS_REACHABLE() hack and replace these with regular Kconfig dependencies
> that ensure each driver is only enabled when its dependencies are there,
> as we do in most other drivers. The main downside here is that there is no
> good way to have built-in gadget support on cdn3 along with USB=m. Fixing
> this part proper would require cleaning up the code to turn the 'common'
> parts into a library module that only gets called by the other drivers
> but does not interact with either host or gadget support itself.
>
> Another problem that is not solved by this patch is the way that
> platform specific glue logic in this driver relies on having
> a soc specific device as the parent of a generic child, instead of
> the specific driver just calling into a common helper module.
> This may be impossible to fix without breaking the DT bindings.
>
> Fixes: 6076388ca1ed ("usb: cdns3: Add USBSSP platform driver support")
Hi Arnd,
Thanks for fixing it, I am sorry for taking your effort debug it.
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> ---
> TBH, I would be more comfortable with reverting 6076388ca1ed altogether
> and asking for a new version with the proper fixups included along
> with more testing for the next merge window.
It depends on Greg, I am okay for both ways. If Greg reverts the patch,
I will do below improvements and adapts for most of your changes for v3
patch.
cdns-usb-common.ko is a libary, and no USB/GADGET dependency, could builds in.
├── core.o
└── drd.o
cdns3-host.ko -> depends on USB/XHCI（it is m when USB = m
cdns3.ko (gadget) -> depends on USB_GADGET
cdnsp.ko (gadget) -> depends on USB_GADGET
cdns3-plat.ko -> assign host_init/gadget_init function pointer
In that way, below combination could work:
cdns-usb-common=y
cdns3-host=m
cdns3(p)-gadget=y
> @@ -10,12 +11,24 @@ config USB_CDNS_SUPPORT
>
> config USB_CDNS_HOST
> bool
> + depends on USB=y || USB=USB_CDNS_SUPPORT
> +
> +config CONFIG_USB_CDNS_PLATFORM
%s/CONFIG_USB_CDNS_PLATFORM/USB_CDNS_PLATFORM
Peter
> + tristate "Cadence USB3 generic platform support"
> + depends on USB_CDNSP || USB_CDNS3
> + depends on USB_CDNSP || !USB_CDNSP
> + depends on USB_CDNS3 || !USB_CDNS3
> + help
> + The platform driver support is needed on any SoC integrating
> + a variant of the Cadence USB3 or USBSSP dual-role controllers,
> + e.g. the TI K3 or NXP i.MX series of SoCs.
>
> if USB_CDNS_SUPPORT
>
> config USB_CDNS3
> tristate "Cadence USB3 Dual-Role Controller"
> depends on USB_CDNS_SUPPORT
> + select USB_CDNS_HOST if USB_CDNS3_HOST
> help
> Say Y here if your system has a Cadence USB3 dual-role controller.
> It supports: dual-role switch, Host-only, and Peripheral-only.
> @@ -23,8 +36,9 @@ config USB_CDNS3
> if USB_CDNS3
>
> config USB_CDNS3_GADGET
> - bool "Cadence USB3 device controller"
> + tristate "Cadence USB3 device controller"
> depends on USB_GADGET=y || USB_GADGET=USB_CDNS3
> + depends on USB_CDNS_SUPPORT
> help
> Say Y here to enable device controller functionality of the
> Cadence USBSS-DEV driver.
> @@ -34,8 +48,7 @@ config USB_CDNS3_GADGET
>
> config USB_CDNS3_HOST
> bool "Cadence USB3 host controller"
> - depends on USB=y || USB=USB_CDNS3
> - select USB_CDNS_HOST
> + depends on USB=y || USB=USB_CDNS_SUPPORT
> help
> Say Y here to enable host controller functionality of the
> Cadence driver.
> @@ -57,6 +70,7 @@ config USB_CDNS3_PCI_WRAP
> config USB_CDNS3_TI
> tristate "Cadence USB3 support on TI platforms"
> depends on ARCH_K3 || COMPILE_TEST
> + depends on USB_CDNS_PLATFORM
> default USB_CDNS3
> help
> Say 'Y' or 'M' here if you are building for Texas Instruments
> @@ -67,6 +81,7 @@ config USB_CDNS3_TI
> config USB_CDNS3_IMX
> tristate "Cadence USB3 support on NXP i.MX platforms"
> depends on ARCH_MXC || COMPILE_TEST
> + depends on USB_CDNS_PLATFORM
> default USB_CDNS3
> help
> Say 'Y' or 'M' here if you are building for NXP i.MX
> @@ -77,6 +92,7 @@ config USB_CDNS3_IMX
> config USB_CDNS3_STARFIVE
> tristate "Cadence USB3 support on StarFive SoC platforms"
> depends on ARCH_STARFIVE || COMPILE_TEST
> + depends on USB_CDNS_PLATFORM
> help
> Say 'Y' or 'M' here if you are building for StarFive SoCs
> platforms that contain Cadence USB3 controller core.
> @@ -91,6 +107,7 @@ endif # USB_CDNS3
> config USB_CDNSP
> tristate "Cadence USBSSP Dual-Role Controller"
> depends on USB_CDNS_SUPPORT
> + select USB_CDNS_HOST if USB_CDNSP_HOST
> help
> Say Y here if your system has a Cadence USBSSP dual-role controller.
> It supports: dual-role switch, Host-only, and Peripheral-only.
> @@ -115,8 +132,7 @@ config USB_CDNSP_GADGET
>
> config USB_CDNSP_HOST
> bool "Cadence USBSSP host controller"
> - depends on USB=y || USB=USB_CDNSP
> - select USB_CDNS_HOST
> + depends on USB=y || USB=USB_CDNS_SUPPORT
> help
> Say Y here to enable host controller functionality of the
> Cadence driver.
> diff --git a/drivers/usb/cdns3/Makefile b/drivers/usb/cdns3/Makefile
> index 63484f145bb9..f1e00ab3d729 100644
> --- a/drivers/usb/cdns3/Makefile
> +++ b/drivers/usb/cdns3/Makefile
> @@ -5,32 +5,25 @@ CFLAGS_cdnsp-trace.o := -I$(src)
>
> cdns-usb-common-y := core.o drd.o
>
> -ifeq ($(CONFIG_USB),m)
> -obj-m += cdns-usb-common.o
> -obj-m += cdns3-plat.o
> -else
> obj-$(CONFIG_USB_CDNS_SUPPORT) += cdns-usb-common.o
> -obj-$(CONFIG_USB_CDNS_SUPPORT) += cdns3-plat.o
> -endif
> +
> +obj-$(CONFIG_USB_CDNS_PLATFORM) += cdns3-plat.o
>
> cdns-usb-common-$(CONFIG_USB_CDNS_HOST) += host.o
>
> # For CDNS3 gadget
> -ifneq ($(CONFIG_USB_CDNS3_GADGET),)
> cdns3-y := cdns3-gadget.o cdns3-ep0.o
> cdns3-$(CONFIG_TRACING) += cdns3-trace.o
> -obj-$(CONFIG_USB_CDNS3) += cdns3.o
> -endif
> +obj-$(CONFIG_USB_CDNS3_GADGET) += cdns3.o
> +
> obj-$(CONFIG_USB_CDNS3_PCI_WRAP) += cdns3-pci-wrap.o
> obj-$(CONFIG_USB_CDNS3_TI) += cdns3-ti.o
> obj-$(CONFIG_USB_CDNS3_IMX) += cdns3-imx.o
> obj-$(CONFIG_USB_CDNS3_STARFIVE) += cdns3-starfive.o
>
> # For CDNSP gadget
> -ifneq ($(CONFIG_USB_CDNSP_GADGET),)
> cdnsp-y := cdnsp-ring.o cdnsp-gadget.o \
> cdnsp-mem.o cdnsp-ep0.o
> cdnsp-$(CONFIG_TRACING) += cdnsp-trace.o
> -obj-$(CONFIG_USB_CDNSP) += cdnsp.o
> -endif
> +obj-$(CONFIG_USB_CDNSP_GADGET) += cdnsp.o
> obj-$(CONFIG_USB_CDNSP_PCI) += cdnsp-pci.o
> diff --git a/drivers/usb/cdns3/gadget-export.h b/drivers/usb/cdns3/gadget-export.h
> index 0cb600e2b5d2..c37b6269b001 100644
> --- a/drivers/usb/cdns3/gadget-export.h
> +++ b/drivers/usb/cdns3/gadget-export.h
> @@ -10,7 +10,7 @@
> #ifndef __LINUX_CDNS3_GADGET_EXPORT
> #define __LINUX_CDNS3_GADGET_EXPORT
>
> -#if defined(CONFIG_USB_CDNSP_GADGET) && IS_REACHABLE(CONFIG_USB_CDNSP)
> +#if IS_ENABLED(CONFIG_USB_CDNSP_GADGET)
>
> int cdnsp_gadget_init(struct cdns *cdns);
> #else
> @@ -22,7 +22,7 @@ static inline int cdnsp_gadget_init(struct cdns *cdns)
>
> #endif /* CONFIG_USB_CDNSP_GADGET */
>
> -#if defined(CONFIG_USB_CDNS3_GADGET) && IS_REACHABLE(CONFIG_USB_CDNS3)
> +#if IS_ENABLED(CONFIG_USB_CDNS3_GADGET)
>
> int cdns3_gadget_init(struct cdns *cdns);
> #else
> --
> 2.39.5
>
--
Best regards,
Peter
^ 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