thunderbolt: Handle DisplayPort tunnel activation asynchronously

Sometimes setting up a DisplayPort tunnel may take quite long time. The
reason is that the graphics driver (DPRX) is expected to issu

thunderbolt: Handle DisplayPort tunnel activation asynchronously

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 <[email protected]>

show more ...

thunderbolt: Add test case for 3 DisplayPort tunnels

Intel Barlow Ridge Thunderbolt controller has 3 DP IN adapters. This
allows 3 simultaneus DisplayPort tunnels through either one or two USB4
down

thunderbolt: Add test case for 3 DisplayPort tunnels

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 <[email protected]>

show more ...

thunderbolt: test: Use kunit_test_suite() macro

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 upda

thunderbolt: test: Use kunit_test_suite() macro

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 <[email protected]>
Acked-by: Daniel Latypov <[email protected]>
Acked-by: Brendan Higgins <[email protected]>
Signed-off-by: David Gow <[email protected]>
Signed-off-by: Shuah Khan <[email protected]>

show more ...

thunderbolt: Add KUnit test for devices with no DisplayPort adapters

Add a KUnit test to check that buffer allocation works also for devices
with no DP adapters.

Signed-off-by: Gil Fine <gil.fine@i

thunderbolt: Add KUnit test for devices with no DisplayPort adapters

Add a KUnit test to check that buffer allocation works also for devices
with no DP adapters.

Signed-off-by: Gil Fine <[email protected]>
Signed-off-by: Mika Westerberg <[email protected]>

show more ...

thunderbolt: Use different lane for second DisplayPort tunnel

Brad reported that on Apple hardware with Light Ridge or Falcon Ridge
controller, plugging in a chain of Thunderbolt displays (Light Rid

thunderbolt: Use different lane for second DisplayPort tunnel

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 <[email protected]>
Signed-off-by: Mika Westerberg <[email protected]>
Tested-by: Brad Campbell <[email protected]>

show more ...

thunderbolt: test: use NULL macros

Replace the NULL checks with the more specific and idiomatic NULL macros.

Acked-by: Mika Westerberg <[email protected]>
Acked-by: Daniel Latypov <dl

thunderbolt: test: use NULL macros

Replace the NULL checks with the more specific and idiomatic NULL macros.

Acked-by: Mika Westerberg <[email protected]>
Acked-by: Daniel Latypov <[email protected]>
Signed-off-by: Ricardo Ribalda <[email protected]>
Acked-by: Brendan Higgins <[email protected]>
Signed-off-by: Shuah Khan <[email protected]>

show more ...

thunderbolt: test: split up test cases in tb_test_credit_alloc_all

The tb_test_credit_alloc_all() function had a huge number of
KUNIT_ASSERT() statements, all of which (though the magic of many many

thunderbolt: test: split up test cases in tb_test_credit_alloc_all

The tb_test_credit_alloc_all() function had a huge number of
KUNIT_ASSERT() statements, all of which (though the magic of many many
layers of inscrutable macros) ended up allocating and initializing
various test assertion structures on the stack.

Don't do that. The kernel stack isn't infinite, and we have compiler
warnings (now errors) for the case where a stack frame grows too large.

Like it did here, by not an inconsiderable margin:

drivers/thunderbolt/test.c: In function ‘tb_test_credit_alloc_all’:
drivers/thunderbolt/test.c:2367:1: error: the frame size of 4500 bytes is larger than 2048 bytes [-Werror=frame-larger-than=]
2367 | }
| ^

Solve this similarly to the lib/test_scanf case: split out the tests
into several smaller functions, each just testing one particular tunnel
credit allocation.

This makes the i386 allyesconfig build work for me again.

Signed-off-by: Linus Torvalds <[email protected]>

show more ...

thunderbolt: test: Reinstate a few casts of bitfields

Partially revert "thunderbolt: test: Remove some casts which are no
longer required". It turns out that typeof() doesn't support bitfields,
so t

thunderbolt: test: Reinstate a few casts of bitfields

Partially revert "thunderbolt: test: Remove some casts which are no
longer required". It turns out that typeof() doesn't support bitfields,
so these still need to be cast to the appropriate enum.

The only mention of typeof() and bitfields I can find is in the proposal
to standardise them:
http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2619.htm

This was caught by the kernel test robot:
https://lists.01.org/hyperkitty/list/[email protected]/thread/FDKBHAV7QNLNFU5NBI2RKV56DWDSOLGM/

Fixes: 8f0877c26e4b ("thunderbolt: test: Remove some casts which are no longer required")
Reported-by: kernel test robot <[email protected]>
Signed-off-by: David Gow <[email protected]>
Signed-off-by: Shuah Khan <[email protected]>

show more ...

thunderbolt: test: Remove some casts which are no longer required

With some of the stricter type checking in KUnit's EXPECT macros
removed, several casts in the thunderbolt KUnit tests are no longer

thunderbolt: test: Remove some casts which are no longer required

With some of the stricter type checking in KUnit's EXPECT macros
removed, several casts in the thunderbolt KUnit tests are no longer
required.

Remove the unnecessary casts, making the conditions clearer.

Signed-off-by: David Gow <[email protected]>
Acked-by: Mika Westerberg <[email protected]>
Reviewed-by: Brendan Higgins <[email protected]>
Signed-off-by: Shuah Khan <[email protected]>

show more ...

thunderbolt: Bond lanes only when dual_link_port != NULL in alloc_dev_default()

We should not dereference ->dual_link_port if it is NULL and lane bonding
is requested. For this reason move lane bond

thunderbolt: Bond lanes only when dual_link_port != NULL in alloc_dev_default()

We should not dereference ->dual_link_port if it is NULL and lane bonding
is requested. For this reason move lane bonding configuration happen
inside the block where ->dual_link_port != NULL.

Fixes: 54509f5005ca ("thunderbolt: Add KUnit tests for path walking")
Reported-by: kernel test robot <[email protected]>
Reported-by: Dan Carpenter <[email protected]>
Reviewed-by: Yehezkel Bernat <[email protected]>
Signed-off-by: Mika Westerberg <[email protected]>

show more ...

thunderbolt: Add KUnit tests for credit allocation

This adds a couple of KUnit tests for USB4 credit allocation.

Signed-off-by: Mika Westerberg <[email protected]>

thunderbolt: Add KUnit tests for DMA tunnels

Add a couple of tests to check DMA tunneling functionality.

Signed-off-by: Mika Westerberg <[email protected]>

thunderbolt: Add KUnit tests for XDomain properties

This adds KUnit tests for parsing, formatting and copying of XDomain
properties.

Signed-off-by: Mika Westerberg <[email protected]>

thunderbolt: Allow KUnit tests to be built also when CONFIG_USB4=m

This adds a bit more build coverage for the tests even though these are
not expected to be enabled by normal users and distros. In

thunderbolt: Allow KUnit tests to be built also when CONFIG_USB4=m

This adds a bit more build coverage for the tests even though these are
not expected to be enabled by normal users and distros. In order to make
this working we need to open-code kunit_test_suite() and call the
relevant functions directly in the driver init/exit hook.

Signed-off-by: Mika Westerberg <[email protected]>

show more ...

thunderbolt: merge fix for kunix_resource changes

Signed-off-by: Stephen Rothwell <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>

thunderbolt: Add KUnit tests for tunneling

We can test some parts of tunneling, like path allocation without access
to test hardware so add KUnit tests for PCIe, DP and USB3 tunneling.

Signed-off-b

thunderbolt: Add KUnit tests for tunneling

We can test some parts of tunneling, like path allocation without access
to test hardware so add KUnit tests for PCIe, DP and USB3 tunneling.

Signed-off-by: Mika Westerberg <[email protected]>

show more ...

thunderbolt: Add KUnit tests for path walking

This adds KUnit tests for path walking which is only dependent on
software structures, so no hardware is needed to run these.

We make these available o

thunderbolt: Add KUnit tests for path walking

This adds KUnit tests for path walking which is only dependent on
software structures, so no hardware is needed to run these.

We make these available only when both KUnit and the driver itself are
built into the kernel image. The reason for this is that KUnit adds its
own module_init() call in kunit_test_suite() which generates linker
error because the driver does the same in nhi.c. This should be fine for
now because these tests are only meant to run by developers anyway.

Signed-off-by: Mika Westerberg <[email protected]>

show more ...