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

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

2024-04-13T11:05:17+00:00

[ Upstream commit a75e0684efe567ae5f6a8e91a8360c4c1773cf3a ] 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 Signed-off-by: Sasha Levin

thunderbolt: Fix memory leak in margining_port_remove()

2024-01-01T12:39:08+00:00

commit ac43c9122e4287bbdbe91e980fc2528acb72cc1e upstream. The dentry returned by debugfs_lookup() needs to be released by calling dput() which is missing in margining_port_remove(). Fix this by calling debugfs_lookup_and_remove() that combines both and avoids the memory leak. Fixes: d0f1e0c2a699 ("thunderbolt: Add support for receiver lane margining") Cc: stable@vger.kernel.org Signed-off-by: Yaxiong Tian Signed-off-by: Mika Westerberg Signed-off-by: Greg Kroah-Hartman

thunderbolt: Apply USB 3.x bandwidth quirk only in software connection manager

2023-11-28T17:07:01+00:00

[ Upstream commit 0c35ac18256942e66d8dab6ca049185812e60c69 ] This is not needed when firmware connection manager is run so limit this to software connection manager. Signed-off-by: Mika Westerberg Signed-off-by: Sasha Levin

thunderbolt: Restart XDomain discovery handshake after failure

2023-10-19T21:08:56+00:00

commit 308092d080852f8997126e5b3507536162416f4a upstream. Alex reported that after rebooting the other host the peer-to-peer link does not come up anymore. The reason for this is that the host that was not rebooted tries to send the UUID request only 10 times according to the USB4 Inter-Domain spec and gives up if it does not get reply. Then when the other side is actually ready it cannot get the link established anymore. The USB4 Inter-Domain spec requires that the discovery protocol is restarted in that case so implement this now. Reported-by: Alex Balcanquall Fixes: 8e1de7042596 ("thunderbolt: Add support for XDomain lane bonding") Cc: stable@vger.kernel.org Signed-off-by: Mika Westerberg Signed-off-by: Greg Kroah-Hartman

thunderbolt: Check that lane 1 is in CL0 before enabling lane bonding

2023-10-19T21:08:56+00:00

commit a9fdf5f933a6f2b358fad0194b1287b67f6704b1 upstream. Marek reported that when BlackMagic UltraStudio device is connected the kernel repeatedly tries to enable lane bonding without success making the device non-functional. It looks like the device does not have lane 1 connected at all so even though it is enabled we should not try to bond the lanes. For this reason check that lane 1 is in fact CL0 (connected, active) before attempting to bond the lanes. Reported-by: Marek Šanta Closes: https://bugzilla.kernel.org/show_bug.cgi?id=217737 Cc: stable@vger.kernel.org Signed-off-by: Mika Westerberg Signed-off-by: Greg Kroah-Hartman

thunderbolt: Workaround an IOMMU fault on certain systems with Intel Maple Ridge

2023-10-19T21:08:56+00:00

commit 582620d9f6b352552bc9a3316fe2b1c3acd8742d upstream. On some systems the IOMMU blocks the first couple of driver ready messages to the connection manager firmware as can be seen in below excerpts: thunderbolt 0000:06:00.0: AMD-Vi: Event logged [IO_PAGE_FAULT domain=0x0010 address=0xbb0e3400 flags=0x0020] or DMAR: DRHD: handling fault status reg 2 DMAR: [DMA Write] Request device [04:00.0] PASID ffffffff fault addr 69974000 [fault reason 05] PTE Write access is not set The reason is unknown and hard to debug because we were not able to reproduce this locally. This only happens on certain systems with Intel Maple Ridge Thunderbolt controller. If there is a device connected when the driver is loaded the issue does not happen either. Only when there is nothing connected (so typically when the system is booted up). We can work this around by sending the driver ready several times. After a couple of retries the message goes through and the controller works just fine. For this reason make the number of retries a parameter for icm_request() and then for Maple Ridge (and Titan Ridge as they us the same function but this should not matter) increase number of retries while shortening the timeout accordingly. Reported-by: Werner Sembach Reported-by: Konrad J Hambrick Reported-by: Calvin Walton Closes: https://bugzilla.kernel.org/show_bug.cgi?id=214259 Cc: stable@vger.kernel.org Signed-off-by: Mika Westerberg Signed-off-by: Greg Kroah-Hartman

thunderbolt: Fix a backport error for display flickering issue

2023-09-02T07:16:20+00:00

A mistake was made when backporting commit 583893a66d73 ("thunderbolt: Fix Thunderbolt 3 display flickering issue on 2nd hot plug onwards") in missing the `if` block. Add it back in. Reported-by: Joakim.Tjernlund@infinera.com Closes: https://lore.kernel.org/stable/28b5d0accce90bedf2f75d65290c5a1302225f0f.camel@infinera.com/ Fixes: 06614ca4f18e ("thunderbolt: Fix Thunderbolt 3 display flickering issue on 2nd hot plug onwards") Signed-off-by: Mario Limonciello Signed-off-by: Greg Kroah-Hartman

thunderbolt: Fix Thunderbolt 3 display flickering issue on 2nd hot plug onwards

2023-08-30T14:11:11+00:00

commit 583893a66d731f5da010a3fa38a0460e05f0149b upstream. Previously, on unplug events, the TMU mode was disabled first followed by the Time Synchronization Handshake, irrespective of whether the tb_switch_tmu_rate_write() API was successful or not. However, this caused a problem with Thunderbolt 3 (TBT3) devices, as the TSPacketInterval bits were always enabled by default, leading the host router to assume that the device router's TMU was already enabled and preventing it from initiating the Time Synchronization Handshake. As a result, TBT3 monitors experienced display flickering from the second hot plug onwards. To address this issue, we have modified the code to only disable the Time Synchronization Handshake during TMU disable if the tb_switch_tmu_rate_write() function is successful. This ensures that the TBT3 devices function correctly and eliminates the display flickering issue. Co-developed-by: Sanath S Signed-off-by: Sanath S Signed-off-by: Sanjay R Mehta Cc: stable@vger.kernel.org Signed-off-by: Mika Westerberg [ USB4v2 introduced support for uni-directional TMU mode as part of d49b4f043d63 ("thunderbolt: Add support for enhanced uni-directional TMU mode") This is not a stable candidate commit, so adjust the code for backport. ] Signed-off-by: Mario Limonciello Signed-off-by: Greg Kroah-Hartman

thunderbolt: Limit Intel Barlow Ridge USB3 bandwidth

2023-08-23T15:52:24+00:00

[ Upstream commit f2bfa944080dcbb8eb56259dfd2c07204cbee17e ] Intel Barlow Ridge discrete USB4 host router has the same limitation as the previous generations so make sure the USB3 bandwidth limitation quirk is applied to Barlow Ridge too. Signed-off-by: Gil Fine Signed-off-by: Mika Westerberg Signed-off-by: Sasha Levin

thunderbolt: Add Intel Barlow Ridge PCI ID

2023-08-23T15:52:24+00:00

[ Upstream commit 6f14a210661ce03988ef4ed3c8402037c8e06539 ] Intel Barlow Ridge is the first USB4 v2 controller from Intel. The controller exposes standard USB4 PCI class ID in typical configurations, however there is a way to configure it so that it uses a special class ID to allow using s different driver than the Windows inbox one. For this reason add the Barlow Ridge PCI ID to the Linux driver too so that the driver can attach regardless of the class ID. Tested-by: Pengfei Xu Signed-off-by: Mika Westerberg Signed-off-by: Sasha Levin