blaster4385/linux-IllusionX/drivers/thunderbolt, branch v6.12.10

thunderbolt: Don't display nvm_version unless upgrade supported

2024-12-27T13:02:09Z

commit e34f1717ef0632fcec5cb827e5e0e9f223d70c9b upstream. 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: Greg Kroah-Hartman

thunderbolt: Improve redrive mode handling

2024-12-27T13:02:09Z

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: Add support for Intel Panther Lake-M/P

2024-12-27T13:02:09Z

commit 8644b48714dca8bf2f42a4ff8311de8efc9bd8c3 upstream. Intel Panther Lake-M/P has the same integrated Thunderbolt/USB4 controller as Lunar Lake. Add these PCI IDs to the driver list of supported devices. Cc: stable@vger.kernel.org Signed-off-by: Mika Westerberg Signed-off-by: Greg Kroah-Hartman

Merge tag 'thunderbolt-for-v6.12-rc7' of ssh://gitolite.kernel.org/pub/scm/linux/kernel/git/westeri/thunderbolt into usb-linus

2024-11-07T15:11:57Z

thunderbolt: Fixes for v6.12-rc7 This includes following USB4/Thunderbolt fixes for v6.12-rc7: - Fix for retimer enumeration. - Fix connection issue with Pluggable UD-4VPD USB4 dock. Both have been in linux-next with no reported issues. * tag 'thunderbolt-for-v6.12-rc7' of ssh://gitolite.kernel.org/pub/scm/linux/kernel/git/westeri/thunderbolt: thunderbolt: Fix connection issue with Pluggable UD-4VPD dock thunderbolt: Add only on-board retimers when !CONFIG_USB4_DEBUGFS_MARGINING

thunderbolt: Fix connection issue with Pluggable UD-4VPD dock

2024-11-05T14:29:47Z

Rick reported that his Pluggable USB4 dock does not work anymore after upgrading to v6.10 kernel. It looks like commit c6ca1ac9f472 ("thunderbolt: Increase sideband access polling delay") makes the device router enumeration happen later than what might be expected by the dock (although there is no such limit in the USB4 spec) which probably makes it assume there is something wrong with the high-speed link and reset it. After the link is reset the same issue happens again and again. For this reason lower the sideband access delay from 5ms to 1ms. This seems to work fine according to Rick's testing. Reported-by: Rick Lahaye Closes: https://lore.kernel.org/linux-usb/000f01db247b$d10e1520$732a3f60$@581238.xyz/ Tested-by: Rick Lahaye Fixes: c6ca1ac9f472 ("thunderbolt: Increase sideband access polling delay") Cc: stable@vger.kernel.org Acked-by: Greg Kroah-Hartman Reviewed-by: Mario Limonciello Signed-off-by: Mika Westerberg

thunderbolt: Add only on-board retimers when !CONFIG_USB4_DEBUGFS_MARGINING

2024-10-29T05:48:42Z

Normally there is no need to enumerate retimers on the other side of the cable. This is only needed in special cases where user wants to run receiver lane margining against the downstream facing port of a retimer. Furthermore this might confuse the userspace tools such as fwupd because it cannot read the information it expects from these retimers. Fix this by changing the retimer enumeration code to add only on-board retimers when CONFIG_USB4_DEBUGFS_MARGINING is not enabled. Reported-by: AceLan Kao Tested-by: AceLan Kao Closes: https://bugzilla.kernel.org/show_bug.cgi?id=219420 Cc: stable@vger.kernel.org Fixes: ff6ab055e070 ("thunderbolt: Add receiver lane margining support for retimers") Signed-off-by: Mika Westerberg

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

2024-10-21T06:42:42Z

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

thunderbolt: Fix KASAN reported stack out-of-bounds read in tb_retimer_scan()

2024-10-11T11:23:15Z

KASAN reported following issue: BUG: KASAN: stack-out-of-bounds in tb_retimer_scan+0xffe/0x1550 [thunderbolt] Read of size 4 at addr ffff88810111fc1c by task kworker/u56:0/11 CPU: 0 UID: 0 PID: 11 Comm: kworker/u56:0 Tainted: G U 6.11.0+ #1387 Tainted: [U]=USER Workqueue: thunderbolt0 tb_handle_hotplug [thunderbolt] Call Trace: dump_stack_lvl+0x6c/0x90 print_report+0xd1/0x630 kasan_report+0xdb/0x110 __asan_report_load4_noabort+0x14/0x20 tb_retimer_scan+0xffe/0x1550 [thunderbolt] tb_scan_port+0xa6f/0x2060 [thunderbolt] tb_handle_hotplug+0x17b1/0x3080 [thunderbolt] process_one_work+0x626/0x1100 worker_thread+0x6c8/0xfa0 kthread+0x2c8/0x3a0 ret_from_fork+0x3a/0x80 ret_from_fork_asm+0x1a/0x30 This happens because the loop variable still gets incremented by one so max becomes 3 instead of 2, and this makes the second loop read past the the array declared on the stack. Fix this by assigning to max directly in the loop body. Fixes: ff6ab055e070 ("thunderbolt: Add receiver lane margining support for retimers") CC: stable@vger.kernel.org Signed-off-by: Mika Westerberg

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

2024-09-11T13:17:43Z

Mika writes: thunderbolt: Changes for v6.12 merge window This includes following USB4/Thunderbolt changes for the v6.12 merge window: - Improvements for software receiver lane margining - Enable support for optional voltage offset range for receiver lane margining. All these have been in linux-next with no reported issues. * tag 'thunderbolt-for-v6.12-rc1' of ssh://gitolite.kernel.org/pub/scm/linux/kernel/git/westeri/thunderbolt: thunderbolt: Improve software receiver lane margining thunderbolt: Add optional voltage offset range for receiver lane margining thunderbolt: Consolidate margining parameters into a structure thunderbolt: Add missing usb4_port_sb_read() to usb4_port_sw_margin()

thunderbolt: Don't create device link from USB4 Host Interface to USB3 xHC host

2024-09-03T07:54:39Z

USB core will create device links between tunneled USB3 devices and USB4 Host Interface during USB device creation. Those device links are removed with the tunneled USB3 devices, allowing USB4 Host Interface to runtime suspend if USB3 tunnels are not used. So remove device link creation between USB4 Host Interface and USB3 xHC during NHI probe Reported-by: Rajaram Regupathy Reported-by: Saranya Gopal Tested-by: Saranya Gopal Acked-by: Mika Westerberg Signed-off-by: Mathias Nyman Link: https://lore.kernel.org/r/20240830152630.3943215-5-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman