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

thunderbolt: Use is_pciehp instead of is_hotplug_bridge

2025-11-13T20:34:12+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: Scan retimers after device router has been enumerated

2025-05-02T05:59:19+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: Improve redrive mode handling

2024-12-27T13:02:09+00:00

commit 24740385cb0d6d22ab7fa7adf36546d5b3cdcf73 upstream. When USB-C monitor is connected directly to Intel Barlow Ridge host, it goes into "redrive" mode that basically routes the DisplayPort signals directly from the GPU to the USB-C monitor without any tunneling needed. However, the host router must be powered on for this to work. Aaron reported that there are a couple of cases where this will not work with the current code: - Booting with USB-C monitor plugged in. - Plugging in USB-C monitor when the host router is in sleep state (runtime suspended). - Plugging in USB-C device while the system is in system sleep state. In all these cases once the host router is runtime suspended the picture on the connected USB-C display disappears too. This is certainly not what the user expected. For this reason improve the redrive mode handling to keep the host router from runtime suspending when detect that any of the above cases is happening. Fixes: a75e0684efe5 ("thunderbolt: Keep the domain powered when USB4 port is in redrive mode") Reported-by: Aaron Rainbolt Closes: https://lore.kernel.org/linux-usb/20241009220118.70bfedd0@kf-ir16/ Cc: stable@vger.kernel.org Signed-off-by: Mika Westerberg Signed-off-by: Greg Kroah-Hartman

thunderbolt: Honor TMU requirements in the domain when setting TMU mode

2024-10-21T06:42:42+00:00

Currently, when configuring TMU (Time Management Unit) mode of a given router, we take into account only its own TMU requirements ignoring other routers in the domain. This is problematic if the router we are configuring has lower TMU requirements than what is already configured in the domain. In the scenario below, we have a host router with two USB4 ports: A and B. Port A connected to device router #1 (which supports CL states) and existing DisplayPort tunnel, thus, the TMU mode is HiFi uni-directional. 1. Initial topology [Host] A/ / [Device #1] / Monitor 2. Plug in device #2 (that supports CL states) to downstream port B of the host router [Host] A/ B\ / \ [Device #1] [Device #2] / Monitor The TMU mode on port B and port A will be configured to LowRes which is not what we want and will cause monitor to start flickering. To address this we first scan the domain and search for any router configured to HiFi uni-directional mode, and if found, configure TMU mode of the given router to HiFi uni-directional as well. Cc: stable@vger.kernel.org Signed-off-by: Gil Fine Signed-off-by: Mika Westerberg

Merge tag 'thunderbolt-for-v6.10-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/westeri/thunderbolt into usb-next

2024-05-10T09:25:22+00:00

Mika writes: thunderbolt: Changes for v6.10 merge window This includes following USB4/Thunderbolt changes for the v6.10 merge window: - Enable NVM firmare upgrade on Intel Maple Ridge Thunderbolt 4 controller - Improve USB3 tunnel bandwidth calculation - Improve sideband access - Minor cleanups and fixes. All these have been in linux-next with no reported issues. * tag 'thunderbolt-for-v6.10-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/westeri/thunderbolt: thunderbolt: Correct trace output of firmware connection manager packets thunderbolt: Fix kernel-doc for tb_tunnel_alloc_dp() thunderbolt: Fix uninitialized variable in tb_tunnel_alloc_usb3() thunderbolt: There are only 5 basic router registers in pre-USB4 routers thunderbolt: No need to loop over all retimers if access fails thunderbolt: Increase sideband access polling delay thunderbolt: Get rid of TB_CFG_PKG_PREPARE_TO_SLEEP thunderbolt: Use correct error code with ERROR_NOT_SUPPORTED thunderbolt: Allow USB3 bandwidth to be lower than maximum supported thunderbolt: Fix calculation of consumed USB3 bandwidth on a path thunderbolt: Enable NVM upgrade support on Intel Maple Ridge

thunderbolt: Fix calculation of consumed USB3 bandwidth on a path

2024-04-12T06:43:32+00:00

Currently, when setup a new USB3 tunnel that is starting from downstream USB3 adapter of first depth router (or deeper), to upstream USB3 adapter of a second depth router (or deeper), we calculate consumed bandwidth. For this calculation we take into account first USB3 tunnel consumed bandwidth while we shouldn't, because we just recalculating the first USB3 tunnel allocated bandwidth. Fix that, so that more bandwidth is available for the new USB3 tunnel being setup. While there, fix the kernel-doc to decribe more accurately the purpose of the function. Signed-off-by: Gil Fine Signed-off-by: Mika Westerberg

thunderbolt: Avoid notify PM core about runtime PM resume

2024-04-10T07:49:58+00:00

Currently we notify PM core about occurred wakes after any resume. This is not actually needed after resume from runtime suspend. Hence, notify PM core about occurred wakes only after resume from system sleep. Also, if the wake occurred in USB4 router upstream port, we don't notify the PM core about it since it is not actually needed and can cause unexpected autowake (e.g. if /sys/power/wakeup_count is used). While there add the missing kernel-doc for tb_switch_resume(). Signed-off-by: Gil Fine Cc: stable@vger.kernel.org Signed-off-by: Mika Westerberg

thunderbolt: Do not create DisplayPort tunnels on adapters of the same router

2024-04-02T05:51:12+00:00

Probably due to a firmware bug Dell TB16 dock announces that one of its DisplayPort adapters is actually DP IN. Now this is possible and used with some external GPUs but not likely in this case as we are dealing with a dock. Anyways the problem is that the driver tries to create a DisplayPort tunnel between adapters of the same router which then shows to user that there is no picture on the display (because there are no available DP OUT adapters on the dock anymore). Fix this by not creating DisplayPort tunnels between adapters that are on the same router. Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/10265 Fixes: 274baf695b08 ("thunderbolt: Add DP IN added last in the head of the list of DP resources") Cc: Gil Fine Cc: stable@vger.kernel.org Signed-off-by: Mika Westerberg

thunderbolt: Keep the domain powered when USB4 port is in redrive mode

2024-02-26T07:12:12+00:00

If a DiplayPort cable is directly connected to the host routers USB4 port, there is no tunnel involved but the port is in "redrive" mode meaning that it is re-driving the DisplayPort signals from its DisplayPort source. In this case we need to keep the domain powered on otherwise once the domain enters D3cold the connected monitor blanks too. Since this happens only on Intel Barlow Ridge add a quirk that takes runtime PM reference if we detect that the USB4 port entered redrive mode (and release it once it exits the mode). Signed-off-by: Mika Westerberg

thunderbolt: Improve DisplayPort tunnel setup process to be more robust

2024-02-16T10:29:23+00:00

After DisplayPort tunnel setup, we add verification that the DPRX capabilities read process completed. Otherwise, we bail out, teardown the tunnel, and try setup another DisplayPort tunnel using next available DP IN adapter. We do so till all DP IN adapters tried. This way, we avoid allocating DP IN adapter and (bandwidth for it) for unusable tunnel. Signed-off-by: Gil Fine Signed-off-by: Mika Westerberg