kernel/linux.git/drivers/thunderbolt/test.c, branch v7.2-rc1

thunderbolt: test: Release third DP tunnel

2026-06-01T10:37:32+00:00

tb_test_tunnel_3dp() allocates three DisplayPort tunnels but only releases the first two before returning. Release the third tunnel as well to keep the test cleanup balanced. Signed-off-by: Xu Rao Signed-off-by: Mika Westerberg

thunderbolt: test: Add KUnit tests for property parser bounds checks

2026-05-26T13:27:14+00:00

Add regression tests for the zero-length entry and root directory bounds fixes: - tb_test_property_parse_zero_length: TEXT entry with length 0 must be rejected by the validator. - tb_test_property_parse_rootdir_overflow: root directory whose content_offset + content_len exceeds block_len must be rejected. Assisted-by: Claude:claude-opus-4-7 Signed-off-by: Michael Bommarito Signed-off-by: Mika Westerberg

thunderbolt: Add KUnit test for tb_property_merge_dir()

2026-05-19T12:20:18+00:00

This makes sure it keeps working if we ever need to change it. Signed-off-by: Mika Westerberg

thunderbolt: test: add KUnit regression tests for XDomain property parser

2026-05-11T09:32:44+00:00

Add three KUnit cases that exercise the defects fixed by the sibling commits in this series by feeding crafted XDomain property blocks to tb_property_parse_dir(): tb_test_property_parse_u32_wrap - entry->value = 0xffffff00 and entry->length = 0x100 so their u32 sum 0x100000000 wraps to 0 under the block_len guard; without the fix the subsequent parse_dwdata() reads attacker-directed OOB memory. tb_test_property_parse_recursion - two DIRECTORY entries pointing at each other, driving __tb_property_parse_dir() recursion; without the fix the kernel stack is exhausted. tb_test_property_parse_dir_len_underflow - a DIRECTORY entry with length < 4 placed near the end of the block so the non-root UUID kmemdup of 4 dwords from dir_offset reads OOB before the later content_len = dir_len - 4 underflow path is reached. Each test asserts tb_property_parse_dir() returns NULL on the crafted input. With CONFIG_KASAN=y, running these on the pre-fix kernel produces an oops inside __tb_property_parse_dir or its callees: u32_wrap takes a page fault on the KASAN shadow lookup for the wild ~16 GiB OOB offset; recursion trips a KASAN out-of-bounds report in __unwind_start as the per-task kernel stack is consumed; dir_len_underflow trips a KASAN slab-out-of-bounds report in kmemdup_noprof reading 16 bytes past the 28-byte block. Post-fix they pass cleanly. The crafted blocks are populated by writing u32 dwords directly, matching the existing root_directory[] style used elsewhere in this file rather than imposing a private struct overlay. Run with: ./tools/testing/kunit/kunit.py run --arch=x86_64 \ --kconfig_add CONFIG_PCI=y --kconfig_add CONFIG_NVMEM=y \ --kconfig_add CONFIG_USB4=y --kconfig_add CONFIG_USB4_KUNIT_TEST=y \ --kconfig_add CONFIG_KASAN=y 'thunderbolt.tb_test_property_parse_*' Assisted-by: Claude:claude-opus-4-7 Signed-off-by: Michael Bommarito 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: Add test case for 3 DisplayPort tunnels

2023-06-16T06:53:29+00:00

Intel Barlow Ridge Thunderbolt controller has 3 DP IN adapters. This allows 3 simultaneus DisplayPort tunnels through either one or two USB4 downstream ports (in any possible configuration). Add test case for this. Signed-off-by: Mika Westerberg

thunderbolt: test: Use kunit_test_suite() macro

2022-07-11T23:13:21+00:00

The new implementation of kunit_test_suite() for modules no longer conflicts with module_init, so can now be used by the thunderbolt tests. Also update the Kconfig entry to enable the test when KUNIT_ALL_TESTS is enabled. This means that kunit_tool can now successfully run and parse the test results with, for example: ./tools/testing/kunit/kunit.py run --arch=x86_64 \ --kconfig_add CONFIG_PCI=y --kconfig_add CONFIG_USB4=y \ 'thunderbolt' Acked-by: Mika Westerberg Acked-by: Daniel Latypov Acked-by: Brendan Higgins Signed-off-by: David Gow Signed-off-by: Shuah Khan

Merge tag 'usb-5.19-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb

2022-06-03T18:17:49+00:00

Pull USB / Thunderbolt updates from Greg KH: "Here is the "big" set of USB and Thunderbolt driver changes for 5.18-rc1. For the most part it's been a quiet development cycle for the USB core, but there are the usual "hot spots" of development activity. Included in here are: - Thunderbolt driver updates: - fixes for devices without displayport adapters - lane bonding support and improvements - other minor changes based on device testing - dwc3 gadget driver changes. It seems this driver will never be finished given that the IP core is showing up in zillions of new devices and each implementation decides to do something different with it... - uvc gadget driver updates as more devices start to use and rely on this hardware as well - usb_maxpacket() api changes to remove an unneeded and unused parameter. - usb-serial driver device id updates and small cleanups - typec cleanups and fixes based on device testing - device tree updates for usb properties - lots of other small fixes and driver updates. All of these have been in linux-next for weeks with no reported problems" * tag 'usb-5.19-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb: (154 commits) USB: new quirk for Dell Gen 2 devices usb: dwc3: core: Add error log when core soft reset failed usb: dwc3: gadget: Move null pinter check to proper place usb: hub: Simplify error and success path in port_over_current_notify usb: cdns3: allocate TX FIFO size according to composite EP number usb: dwc3: Fix ep0 handling when getting reset while doing control transfer usb: Probe EHCI, OHCI controllers asynchronously usb: isp1760: Fix out-of-bounds array access xhci: Don't defer primary roothub registration if there is only one roothub USB: serial: option: add Quectel BG95 modem USB: serial: pl2303: fix type detection for odd device xhci: Allow host runtime PM as default for Intel Alder Lake N xHCI xhci: Remove quirk for over 10 year old evaluation hardware xhci: prevent U2 link power state if Intel tier policy prevented U1 xhci: use generic command timer for stop endpoint commands. usb: host: xhci-plat: omit shared hcd if either root hub has no ports usb: host: xhci-plat: prepare operation w/o shared hcd usb: host: xhci-plat: create shared hcd after having added main hcd xhci: prepare for operation w/o shared hcd xhci: factor out parts of xhci_gen_setup() ...

thunderbolt: Add KUnit test for devices with no DisplayPort adapters

2022-05-12T06:22:36+00:00

Add a KUnit test to check that buffer allocation works also for devices with no DP adapters. Signed-off-by: Gil Fine Signed-off-by: Mika Westerberg

thunderbolt: Use different lane for second DisplayPort tunnel

2022-04-19T07:26:18+00:00

Brad reported that on Apple hardware with Light Ridge or Falcon Ridge controller, plugging in a chain of Thunderbolt displays (Light Ridge based controllers) causes all kinds of tearing and flickering. The reason for this is that on Thunderbolt 1 hardware there is no lane bonding so we have two independent 10 Gb/s lanes, and currently Linux tunnels both displays through the lane 1. This makes the displays to share the 10 Gb/s bandwidth which may not be enough for higher resolutions. For this reason make the second tunnel go through the lane 0 instead. This seems to match what the macOS connection manager is also doing. Reported-by: Brad Campbell Signed-off-by: Mika Westerberg Tested-by: Brad Campbell