wireguard-linux/drivers/usb/typec/ucsi, branch stable

usb: typec: ucsi: use UCSI_TIMEOUT_MS for sync command completion

2026-08-14T01:48:55Z

The synchronous command completion path in ucsi_sync_control_common() hardcodes a 5 second (5 * HZ) timeout when waiting for the PPM to signal command completion via ACPI notification. This value matched UCSI_TIMEOUT_MS when it was still 5000 ms, but it was not updated when that macro was later raised to 10000 ms to fix PPM reset timeouts. As a result, the two PPM communication paths are now inconsistent: the polling path in ucsi_reset_ppm() respects the 10 second timeout, while the event-driven completion path still uses 5 seconds. On machines where the firmware is slow to respond during boot (e.g. some Lenovo ThinkPad models such as the E14 Gen 7), commands sent after the PPM reset, such as SET_NOTIFICATION_ENABLE and GET_CAPABILITY, can exceed 5 seconds and cause UCSI initialization to fail with: ucsi_acpi USBC000:00: error -ETIMEDOUT: PPM init failed Once UCSI init aborts, USB-C PD negotiation never completes, which in turn blocks USB-C dock enumeration since the dock depends on a successful PD contract. Replace the hardcoded 5 * HZ with msecs_to_jiffies(UCSI_TIMEOUT_MS) so that both communication paths share a single, consistent timeout value, and future adjustments to UCSI_TIMEOUT_MS are picked up automatically. Link: https://bugzilla.kernel.org/show_bug.cgi?id=221740 Link: https://bugzilla.kernel.org/show_bug.cgi?id=2183790 Fixes: bf4f9ae1cb08c ("usb: typec: ucsi: increase timeout for PPM reset operations") Cc: stable@vger.kernel.org Signed-off-by: Huang Wei Reviewed-by: Heikki Krogerus Reviewed-by: Fedor Pchelkin Link: https://patch.msgid.link/20260805085725.389761-1-huangwei@kylinos.cn Signed-off-by: Greg Kroah-Hartman

Merge 7.2-rc5 into usb-next

2026-07-27T06:40:53Z

We need the USB fixes in here as well. Signed-off-by: Greg Kroah-Hartman

usb: typec: ucsi: Correct teardown ordering in ucsi_init() error path

2026-07-23T08:38:19Z

The commit 7aa7d4bf9d3f ("usb: typec: ucsi: Fix race condition and ordering in port unregistration") consolidated port teardown into the ucsi_unregister_port() helper. However, it introduced an ordering problem in the ucsi_init() error path. Fix this by ensuring ucsi_unregister_port() is called before we unregister their corresponding lockdep keys. Cc: stable@vger.kernel.org Fixes: 7aa7d4bf9d3f ("usb: typec: ucsi: Fix race condition and ordering in port unregistration") Reported-by: "Borah, Chaitanya Kumar" Closes: https://lore.kernel.org/all/22064276-6c56-411a-9f20-6917ceeb865f@intel.com/ Signed-off-by: Andrei Kuchynski Tested-by: Chaitanya Kumar Borah Reviewed-by: Heikki Krogerus Link: https://patch.msgid.link/20260717104614.325250-1-akuchynski@chromium.org Signed-off-by: Greg Kroah-Hartman

usb: typec: ucsi: yoga_c630: Remove redundant duplicate altmode handling

2026-07-16T15:14:34Z

This reverts commit e0c48e42d818 ("usb: typec: ucsi: yoga-c630: remove duplicate AltModes"). The yoga_c630 driver previously implemented its own duplicate altmode detection in yoga_c630_ucsi_update_altmodes() to work around buggy EC firmware that returns duplicate AltModes instead of empty ones. With the introduction of the common ucsi_altmode_is_duplicate() helper in both the standard and nvidia registration paths, duplicate detection is now handled automatically in the core UCSI code. This makes the yoga_c630-specific implementation added in commit e0c48e42d818 ("usb: typec: ucsi: yoga-c630: remove duplicate AltModes") redundant. Remove yoga_c630_ucsi_update_altmodes() and its callback to eliminate code duplication and simplify the driver. Note that this causes the driver to switch back from the nvidia registration path to the standard path, which is the original behavior before commit e0c48e42d818 ("usb: typec: ucsi: yoga-c630: remove duplicate AltModes"). Both paths now include duplicate detection, ensuring the firmware bug is still properly handled. Signed-off-by: Chia-Lin Kao (AceLan) Link: https://patch.msgid.link/20260713084323.287516-3-acelan.kao@canonical.com Signed-off-by: Greg Kroah-Hartman

usb: typec: ucsi: Add duplicate detection to nvidia registration path

2026-07-16T15:14:27Z

Extend the duplicate altmode detection to ucsi_register_altmodes_nvidia() which is used when a driver provides the update_altmodes() callback. This ensures all drivers benefit from duplicate detection, whether they use the standard registration path or the nvidia path with update_altmodes callback. Without this fix, drivers using the nvidia path (like yoga_c630) would still encounter duplicate altmode registration errors from buggy firmware. Fixes: a79f16efcd00 ("usb: typec: ucsi: Add support for the partner USB Modes") Cc: stable Signed-off-by: Chia-Lin Kao (AceLan) Link: https://patch.msgid.link/20260713084323.287516-2-acelan.kao@canonical.com Signed-off-by: Greg Kroah-Hartman

usb: typec: ucsi: Detect and skip duplicate altmodes from buggy firmware

2026-07-16T15:14:18Z

Some firmware implementations incorrectly return the same altmode multiple times at different offsets when queried via UCSI_GET_ALTERNATE_MODES. This causes sysfs duplicate filename errors and kernel call traces when the driver attempts to register the same altmode twice: sysfs: cannot create duplicate filename '/devices/.../typec/port0/port0.0/partner' typec-thunderbolt port0-partner.1: failed to create symlinks typec-thunderbolt port0-partner.1: probe with driver typec-thunderbolt failed with error -17 The matching rules differ by recipient: - UCSI_RECIPIENT_CON (port) and UCSI_RECIPIENT_SOP_P (plug): Two altmodes with identical SVID and VDO are byte-for-byte duplicates and the second has no observable function, so drop it. - UCSI_RECIPIENT_SOP (partner): The typec class binds each partner altmode to a port altmode of the same SVID via altmode_match()/device_find_child(), which returns the first port altmode with a matching SVID. If the partner advertises more altmodes for SVID X than the port advertises, the surplus partner altmode(s) collapse onto an already-paired port altmode and trigger the "duplicate filename .../partner" sysfs error during typec_altmode_create_links(). Use the port-side altmode count for SVID X as the authoritative cap and reject any partner altmode that would exceed it. This preserves legitimate multi-Mode partner altmodes (vendor SVIDs that the port really does advertise more than once) while filtering the firmware-generated duplicates that have no port counterpart, and is therefore stricter than a plain SVID+VDO comparison (which still admits the Thunderbolt case where firmware reports the same SVID twice with different VDOs) without being over-broad like a plain SVID match (which would falsely drop legitimate vendor multi-Mode entries). If a duplicate is detected, skip it and emit a clean warning instead of generating a kernel call trace: ucsi_acpi USBC000:00: con2: Firmware bug: duplicate partner altmode SVID 0x8087 at offset 1, ignoring. ucsi_acpi USBC000:00: con2: VDO mismatch: 0x8087a043 vs 0x00000001 The duplicate detection logic lives in a reusable helper ucsi_altmode_is_duplicate() and is invoked from ucsi_register_altmodes(). It applies to all three recipient types: partner (SOP), port (CON), and plug (SOP_P) altmodes. Fixes: a79f16efcd00 ("usb: typec: ucsi: Add support for the partner USB Modes") Cc: stable Signed-off-by: Chia-Lin Kao (AceLan) unchanged: still SVID+VDO exact-dup match. Reviewed-by: Heikki Krogerus Link: https://patch.msgid.link/20260713084323.287516-1-acelan.kao@canonical.com Signed-off-by: Greg Kroah-Hartman

usb: typec: ucsi: Fix race condition and ordering in port unregistration

2026-07-13T05:10:11Z

A synchronization issue exists during port unregistration where pending partner work items can race against workqueue destruction, leading to use-after-free conditions: cros_ec_ucsi cros_ec_ucsi.3.auto: error -ETIMEDOUT: PPM init failed BUG: kernel NULL pointer dereference, address: 0000000000000000 RIP: 0010:__queue_work+0x83/0x4a0 Call Trace: __cfi_delayed_work_timer_fn+0x10/0x10 run_timer_softirq+0x3b6/0xbd0 sched_clock_cpu+0xc/0x110 irq_exit_rcu+0x18d/0x330 fred_sysvec_apic_timer_interrupt+0x5e/0x80 Fix this by ensuring strict ordering and proper serialization during teardown: 1. Move ucsi_unregister_partner() to the beginning of the teardown sequence and protect it under the connector mutex lock. 2. Ensure all pending partner tasks are explicitly flushed and finished before the workqueue is destroyed. 3. Switch from mod_delayed_work() to a cancel_delayed_work() and queue_delayed_work() sequence. This guarantees that items currently marked as pending won't be scheduled an additional time, preventing a double release of resources which leads to the following crash: Oops: general protection fault, probably for non-canonical address 0xdead000000000122: 0000 [#1] SMP NOPTI Workqueue: cros_ec_ucsi.3.auto-con2 ucsi_poll_worker RIP: 0010:ucsi_poll_worker+0x65/0x1e0 Call Trace: process_scheduled_works+0x218/0x6d0 worker_thread+0x188/0x3f0 __cfi_worker_thread+0x10/0x10 kthread+0x226/0x2a0 To ensure these rules are applied identically across both the normal teardown and the ucsi_init() error paths, consolidate the cleanup logic into a new helper, ucsi_unregister_port(). Cc: stable Fixes: b9aa02ca39a4 ("usb: typec: ucsi: Add polling mechanism for partner tasks like alt mode checking") Fixes: b13abcb7ddd8 ("usb: typec: ucsi: Fix NULL pointer access") Fixes: fac4b8633fd6 ("usb: ucsi: Ensure connector delayed work items are flushed") Signed-off-by: Andrei Kuchynski Reviewed-by: Benson Leung Link: https://patch.msgid.link/20260707141736.1635698-1-akuchynski@chromium.org Signed-off-by: Greg Kroah-Hartman

Merge 7.2-rc3 into usb-next

2026-07-13T05:09:28Z

We need the USB fixes in here as well to build on top of. Signed-off-by: Greg Kroah-Hartman

Merge tag 'usb-7.2-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb

2026-07-12T19:12:41Z

Pull USB fixes from Greg KH: "Here are a number of small USB driver fixes for many reported issues. Included in here are: - usb serial driver corruption and use-after-free fixes - usb gadget rndis bugfixes for malicious/buggy host connections - typec driver fixes for a load of different tiny reported issues - typec mux driver revert for a broken patch in -rc1 - usb gadget driver fixes for many different reported problems - new usb device quirks added - usbip tool fixes and some core usbip fixes as well - dwc3 driver fixes for minor issues - xhci driver fixes for reported problems - lots of other tiny usb driver fixes for many tiny issues All of these have been in linux-next with no reported issues" * tag 'usb-7.2-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb: (56 commits) USB: core: ratelimit cabling message usb: misc: usbio: fix disconnect UAF in client teardown Revert "usb: typec: mux: avoid duplicated mux switches" USB: chaoskey: Fix slab-use-after-free in chaoskey_release() usb: ucsi: huawei_gaokun: move typec_altmode off stack usb: typec: tcpci_rt1711h: unregister TCPCI port with devres usb: typec: tcpm: Fix VDM type for Enter Mode commands usb: typec: ucsi: cancel pending work on system suspend usb: typec: class: drop PD lookup reference usb: typec: ps883x: Fix DP+USB3 configuration usb: xhci: Fix sleep in atomic context in xhci_free_streams() xhci: sideband: fix ring sg table pages leak usb: gadget: udc: Fix use-after-free in gadget_match_driver usb: dwc3: run gadget disconnect from sleepable suspend context usb: sl811-hcd: disable controller wakeup on remove usb: typec: anx7411: use devm_pm_runtime_enable() usb: dwc3: fix dwc3_readl() and dwc3_writel() calls in dwc3_ulpi_setup() USB: misc: uss720: unregister parport on probe failure usb: gadget: function: rndis: add length check for header usb: gadget: function: rndis: add length check to response query ...

usb: typec: ucsi: gaokun: unwind notifier on UCSI register failure

2026-07-10T13:56:54Z

gaokun_ucsi_register_worker() registers the EC notifier before calling ucsi_register(). If ucsi_register() fails, the worker currently only logs the error and leaves the notifier registered. Later EC events can then call into an unpublished UCSI instance. The remove path also unconditionally unregisters both the EC notifier and the UCSI device even if the delayed worker failed before both publication steps completed. Unregister the notifier immediately when ucsi_register() fails, and track only the fully published state. The remove path then tears down the pair only if both publication steps completed. Fixes: 00327d7f2c8c ("usb: typec: ucsi: add Huawei Matebook E Go ucsi driver") Reviewed-by: Heikki Krogerus Reviewed-by: Pengyu Luo Signed-off-by: Pengpeng Hou Link: https://patch.msgid.link/20260709123239.62930-1-pengpeng@iscas.ac.cn Signed-off-by: Greg Kroah-Hartman