kernel/linux.git/drivers/thunderbolt/tb.c, branch v6.19.11

thunderbolt: Fix typos in tb.c

2025-11-17T07:24:24+00:00

Fix typos in tb.c. No functional changes. Signed-off-by: Alan Borzeszkowski Signed-off-by: Mika Westerberg

thunderbolt: Replace use of system_wq with system_percpu_wq

2025-11-07T09:41:51+00:00

Currently if a user enqueues a work item using schedule_delayed_work() the used wq is "system_wq" (per-cpu wq) while queue_delayed_work() use WORK_CPU_UNBOUND (used when a cpu is not specified). The same applies to schedule_work() that is using system_wq and queue_work(), that makes use again of WORK_CPU_UNBOUND. This lack of consistency cannot be addressed without refactoring the API. This patch continues the effort to refactor worqueue APIs, which has begun with the change introducing new workqueues and a new alloc_workqueue flag: commit 128ea9f6ccfb ("workqueue: Add system_percpu_wq and system_dfl_wq") commit 930c2ea566af ("workqueue: Add new WQ_PERCPU flag") Replace system_wq with system_percpu_wq, keeping the old behavior. The old wq (system_wq) will be kept for a few release cycles. Suggested-by: Tejun Heo Signed-off-by: Marco Crivellari Signed-off-by: Mika Westerberg

thunderbolt: Update tb.c function documentation

2025-09-17T05:32:59+00:00

Make tb.c function documentation compliant with current kernel-doc standards. No functional changes. Signed-off-by: Alan Borzeszkowski Signed-off-by: Mika Westerberg

thunderbolt: Use is_pciehp instead of is_hotplug_bridge

2025-08-14T04:34:12+00:00

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

thunderbolt: Notify userspace about software CM tunneling events

2025-04-24T05:24:39+00:00

This adds notification whenever software connection manager activates, changes or deactivates a tunnel, and also if there is limitation in bandwidth. The notification looks like below: TUNNEL_EVENT=activated|changed|deactivated|low bandwidth| insufficient bandwidth TUNNEL_DETAILS=0:12 <-> 1:20 (USB3) Userspace can then listen these and inform user if needed. For example if there is not enough bandwidth, it can show warning dialog to the user. Signed-off-by: Alan Borzeszkowski Signed-off-by: Mika Westerberg

thunderbolt: Scan retimers after device router has been enumerated

2025-03-17T10:24:49+00:00

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

thunderbolt: Handle DisplayPort tunnel activation asynchronously

2025-01-03T09:50:09+00:00

Sometimes setting up a DisplayPort tunnel may take quite long time. The reason is that the graphics driver (DPRX) is expected to issue read of certain monitor capabilities over the AUX channel and the "suggested" timeout from VESA is 5 seconds. If there is no graphics driver loaded this does not happen and currently we timeout and tear the tunnel down. The reason for this is that at least Intel discrete USB4 controllers do not send plug/unplug events about whether the DisplayPort cable from the GPU to the controller is connected or not, so in order to "release" the DisplayPort OUT adapter (the one that has monitor connected) we must tear the tunnel down after this timeout has been elapsed. In typical cases there is always graphics driver loaded, and also all the cables are connected but for instance in Intel graphics CI they only load the graphics driver after the system is fully booted up. This makes the driver to tear down the DisplayPort tunnel. To help this case we allow passing bigger or indefinite timeout through a new module parameter (dprx_timeout). To keep the driver bit more responsive during that time we change the way DisplayPort tunnels get activated. We first do the normal tunnel setup and then run the polling of DPRX capabilities read completion in a separate worker. This also makes the driver to accept bandwidth requests to already established DisplayPort tunnels more responsive. If the tunnel still fails to establish we will tear it down and remove the DisplayPort IN adapter from the dp_resource list to avoid using it again (unless we get hotplug to that adapter). Signed-off-by: Mika Westerberg

thunderbolt: Move forward declarations in one place

2025-01-03T09:50:08+00:00

Sometimes we need to have these but move them into one place so that the code is bit more understanable. Signed-off-by: Mika Westerberg

thunderbolt: Pass reason to tb_dp_resource_unavailable()

2025-01-03T09:50:08+00:00

Since we are going to call this also when DisplayPort tunnel establishment fails it is useful to have the reason logged. Signed-off-by: Mika Westerberg

thunderbolt: Drop tb_tunnel_restart()

2025-01-03T09:50:08+00:00

It is pretty much the same as tb_tunnel_activate() excepts does check for already activated paths. This is not needed anymore and makes it more streamlined so drop tb_tunnel_restart() in favour of tb_tunnel_activate(). Signed-off-by: Mika Westerberg