kernel/linux.git/drivers/thunderbolt, branch v6.6.132

thunderbolt: Add support for Intel Wildcat Lake

2025-12-06T21:18:51+00:00

commit 3575254546a27210a4b661ea37fbbfb836c0815d upstream. Intel Wildcat Lake derives its Thunderbolt/USB4 controller from Lunar Lake platform. Add Wildcat Lake PCI ID to the driver list of supported devices. Signed-off-by: Alan Borzeszkowski Cc: stable@vger.kernel.org Signed-off-by: Mika Westerberg Signed-off-by: Greg Kroah-Hartman

thunderbolt: Use is_pciehp instead of is_hotplug_bridge

2025-11-24T09:29:27+00:00

[ Upstream commit 5d03847175e81e86d4865456c15638faaf7c0634 ] The thunderbolt driver sets up device link dependencies from hotplug ports to the Host Router (aka Native Host Interface, NHI). When resuming from system sleep, this allows the Host Router to re-establish tunnels to attached Thunderbolt devices before the hotplug ports resume. To identify the hotplug ports, the driver utilizes the is_hotplug_bridge flag which also encompasses ACPI slots handled by the ACPI hotplug driver. Thunderbolt hotplug ports are always Hot-Plug Capable PCIe ports, so it is more apt to identify them with the is_pciehp flag. Similarly, hotplug ports on older Thunderbolt controllers have broken MSI support and are quirked to use legacy INTx interrupts instead. The quirk identifies them with is_hotplug_bridge, even though all affected ports are also matched by is_pciehp. So use is_pciehp here as well. Signed-off-by: Lukas Wunner Acked-by: Bjorn Helgaas Signed-off-by: Mika Westerberg Signed-off-by: Sasha Levin

thunderbolt: Fix copy+paste error in match_service_id()

2025-08-28T14:28:31+00:00

commit 5cc1f66cb23cccc704e3def27ad31ed479e934a5 upstream. The second instance of TBSVC_MATCH_PROTOCOL_VERSION seems to have been intended to be TBSVC_MATCH_PROTOCOL_REVISION. Fixes: d1ff70241a27 ("thunderbolt: Add support for XDomain discovery protocol") Cc: stable Signed-off-by: Eric Biggers Link: https://lore.kernel.org/r/20250721050136.30004-1-ebiggers@kernel.org Signed-off-by: Greg Kroah-Hartman

thunderbolt: Fix bit masking in tb_dp_port_set_hops()

2025-07-24T06:53:11+00:00

commit 2cdde91c14ec358087f43287513946d493aef940 upstream. The tb_dp_port_set_hops() function was incorrectly clearing ADP_DP_CS_1_AUX_RX_HOPID_MASK twice. According to the function's purpose, it should clear both TX and RX AUX HopID fields. Replace the first instance with ADP_DP_CS_1_AUX_TX_HOPID_MASK to ensure proper configuration of both AUX directions. Fixes: 98176380cbe5 ("thunderbolt: Convert DP adapter register names to follow the USB4 spec") Cc: stable@vger.kernel.org Signed-off-by: Alok Tiwari Signed-off-by: Mika Westerberg Signed-off-by: Greg Kroah-Hartman

thunderbolt: Fix wake on connect at runtime

2025-07-24T06:53:11+00:00

commit 58d71d4242ce057955c783a14c82270c71f9e1e8 upstream. commit 1a760d10ded37 ("thunderbolt: Fix a logic error in wake on connect") fixated on the USB4 port sysfs wakeup file not working properly to control policy, but it had an unintended side effect that the sysfs file controls policy both at runtime and at suspend time. The sysfs file is supposed to only control behavior while system is suspended. Pass whether programming a port for runtime into usb4_switch_set_wake() and if runtime then ignore the value in the sysfs file. Cc: stable@vger.kernel.org Reported-by: Alexander Kovacs Tested-by: Alexander Kovacs Fixes: 1a760d10ded37 ("thunderbolt: Fix a logic error in wake on connect") Signed-off-by: Mario Limonciello Signed-off-by: Mika Westerberg Signed-off-by: Greg Kroah-Hartman

thunderbolt: Fix a logic error in wake on connect

2025-06-19T13:28:30+00:00

[ Upstream commit 1a760d10ded372d113a0410c42be246315bbc2ff ] commit a5cfc9d65879c ("thunderbolt: Add wake on connect/disconnect on USB4 ports") introduced a sysfs file to control wake up policy for a given USB4 port that defaulted to disabled. However when testing commit 4bfeea6ec1c02 ("thunderbolt: Use wake on connect and disconnect over suspend") I found that it was working even without making changes to the power/wakeup file (which defaults to disabled). This is because of a logic error doing a bitwise or of the wake-on-connect flag with device_may_wakeup() which should have been a logical AND. Adjust the logic so that policy is only applied when wakeup is actually enabled. Fixes: a5cfc9d65879c ("thunderbolt: Add wake on connect/disconnect on USB4 ports") Signed-off-by: Mario Limonciello Signed-off-by: Mika Westerberg Signed-off-by: Sasha Levin

thunderbolt: Do not double dequeue a configuration request

2025-06-19T13:28:00+00:00

commit 0f73628e9da1ee39daf5f188190cdbaee5e0c98c upstream. Some of our devices crash in tb_cfg_request_dequeue(): general protection fault, probably for non-canonical address 0xdead000000000122 CPU: 6 PID: 91007 Comm: kworker/6:2 Tainted: G U W 6.6.65 RIP: 0010:tb_cfg_request_dequeue+0x2d/0xa0 Call Trace: ? tb_cfg_request_dequeue+0x2d/0xa0 tb_cfg_request_work+0x33/0x80 worker_thread+0x386/0x8f0 kthread+0xed/0x110 ret_from_fork+0x38/0x50 ret_from_fork_asm+0x1b/0x30 The circumstances are unclear, however, the theory is that tb_cfg_request_work() can be scheduled twice for a request: first time via frame.callback from ring_work() and second time from tb_cfg_request(). Both times kworkers will execute tb_cfg_request_dequeue(), which results in double list_del() from the ctl->request_queue (the list poison deference hints at it: 0xdead000000000122). Do not dequeue requests that don't have TB_CFG_REQUEST_ACTIVE bit set. Signed-off-by: Sergey Senozhatsky Cc: stable@vger.kernel.org Signed-off-by: Mika Westerberg Signed-off-by: Greg Kroah-Hartman

thunderbolt: Do not add non-active NVM if NVM upgrade is disabled for retimer

2025-06-04T12:41:58+00:00

[ Upstream commit ad79c278e478ca8c1a3bf8e7a0afba8f862a48a1 ] This is only used to write a new NVM in order to upgrade the retimer firmware. It does not make sense to expose it if upgrade is disabled. This also makes it consistent with the router NVM upgrade. Signed-off-by: Mika Westerberg Signed-off-by: Sasha Levin

thunderbolt: Scan retimers after device router has been enumerated

2025-05-02T05:50:55+00:00

[ Upstream commit 75749d2c1d8cef439f8b69fa1f4f36d0fc3193e6 ] Thomas reported connection issues on AMD system with Pluggable UD-4VPD dock. After some experiments it looks like the device has some sort of internal timeout that triggers reconnect. This is completely against the USB4 spec, as there is no requirement for the host to enumerate the device right away or even at all. In Linux case the delay is caused by scanning of retimers on the link so we can work this around by doing the scanning after the device router has been enumerated. Reported-by: Thomas Lynema Closes: https://bugzilla.kernel.org/show_bug.cgi?id=219748 Reviewed-by: Mario Limonciello Signed-off-by: Mika Westerberg Signed-off-by: Sasha Levin

thunderbolt: Don't display nvm_version unless upgrade supported

2025-01-09T12:31:49+00:00

[ Upstream commit e34f1717ef0632fcec5cb827e5e0e9f223d70c9b ] The read will never succeed if NVM wasn't initialized due to an unknown format. Add a new callback for visibility to only show when supported. Cc: stable@vger.kernel.org Fixes: aef9c693e7e5 ("thunderbolt: Move vendor specific NVM handling into nvm.c") Reported-by: Richard Hughes Closes: https://github.com/fwupd/fwupd/issues/8200 Signed-off-by: Mario Limonciello Signed-off-by: Mika Westerberg Signed-off-by: Sasha Levin