kernel/linux
0
Fork 0
mirror of https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/ synced 2026-11-10 20:48:12 +00:00
Code Issues Releases Packages Activity
linux/drivers/thunderbolt/test.c

3188 lines
97 KiB
Raw Permalink Normal View History

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 <mika.westerberg@linux.intel.com>
2020-04-29 16:38:39 +03:00
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 <mika.westerberg@linux.intel.com>
2020-05-04 17:10:40 +03:00
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 <mika.westerberg@linux.intel.com>
2020-04-29 16:38:39 +03:00
thunderbolt: merge fix for kunix_resource changes Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2020-06-30 15:51:50 +10:00
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 <mika.westerberg@linux.intel.com>
2020-04-29 16:38:39 +03:00
thunderbolt: merge fix for kunix_resource changes Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2020-06-30 15:51:50 +10:00
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 <mika.westerberg@linux.intel.com>
2020-04-29 16:38:39 +03:00
thunderbolt: Hold a router reference for each allocated HopID tb_stop() drops the reference to all DP tunnels but does not deactivate them, thus nothing cancels a dprx_work still in flight (which holds its own tunnel reference) and the tunnel can outlive tb_switch_remove(). The HopID releases in tb_path_free() then operate on freed IDAs and trigger warnings like ida_free called for id=8 which is not allocated. This can be triggered by unbinding the driver while a DP tunnel is still waiting for the DPRX capabilities read to finish. On the Apple NHI unplugging the cable runs into just that reliably because the read can never finish right now and because the unplug powers down the entire USB4 complex and removes the NHI device. Take a router reference whenever an input or output HopID is allocated and drop it again after the HopID is released. This keeps the ports and their HopID IDAs alive for as long as they are used. The KUnit tests allocate routers without ever registering their devices so initialize the embedded struct device there as well and drop its initial reference when the test is finished. Fixes: d6d458d42e1e ("thunderbolt: Handle DisplayPort tunnel activation asynchronously") Cc: stable@vger.kernel.org Signed-off-by: Sven Peter <sven@kernel.org> Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2026-08-29 10:08:33 +02:00
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 <mika.westerberg@linux.intel.com>
2020-04-29 16:38:39 +03:00
thunderbolt: Hold a router reference for each allocated HopID tb_stop() drops the reference to all DP tunnels but does not deactivate them, thus nothing cancels a dprx_work still in flight (which holds its own tunnel reference) and the tunnel can outlive tb_switch_remove(). The HopID releases in tb_path_free() then operate on freed IDAs and trigger warnings like ida_free called for id=8 which is not allocated. This can be triggered by unbinding the driver while a DP tunnel is still waiting for the DPRX capabilities read to finish. On the Apple NHI unplugging the cable runs into just that reliably because the read can never finish right now and because the unplug powers down the entire USB4 complex and removes the NHI device. Take a router reference whenever an input or output HopID is allocated and drop it again after the HopID is released. This keeps the ports and their HopID IDAs alive for as long as they are used. The KUnit tests allocate routers without ever registering their devices so initialize the embedded struct device there as well and drop its initial reference when the test is finished. Fixes: d6d458d42e1e ("thunderbolt: Handle DisplayPort tunnel activation asynchronously") Cc: stable@vger.kernel.org Signed-off-by: Sven Peter <sven@kernel.org> Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2026-08-29 10:08:33 +02:00
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 <mika.westerberg@linux.intel.com>
2020-04-29 16:38:39 +03:00
thunderbolt: Add KUnit tests for credit allocation This adds a couple of KUnit tests for USB4 credit allocation. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2021-04-28 19:04:02 +03:00
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 <mika.westerberg@linux.intel.com>
2020-04-29 16:38:39 +03:00
thunderbolt: Add KUnit tests for credit allocation This adds a couple of KUnit tests for USB4 credit allocation. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2021-04-28 19:04:02 +03:00
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 <mika.westerberg@linux.intel.com>
2020-04-29 16:38:39 +03:00
thunderbolt: Add KUnit tests for credit allocation This adds a couple of KUnit tests for USB4 credit allocation. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2021-04-28 19:04:02 +03:00
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 <mika.westerberg@linux.intel.com>
2020-04-29 16:38:39 +03:00
thunderbolt: Add KUnit tests for credit allocation This adds a couple of KUnit tests for USB4 credit allocation. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2021-04-28 19:04:02 +03:00
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 <mika.westerberg@linux.intel.com>
2020-04-29 16:38:39 +03:00
thunderbolt: Add KUnit tests for DMA tunnels Add a couple of tests to check DMA tunneling functionality. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2021-01-08 16:32:19 +02:00
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 <mika.westerberg@linux.intel.com>
2020-04-29 16:38:39 +03:00
thunderbolt: Add KUnit tests for credit allocation This adds a couple of KUnit tests for USB4 credit allocation. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2021-04-28 19:04:02 +03:00
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 <mika.westerberg@linux.intel.com>
2022-02-14 14:09:50 +02:00
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 <mika.westerberg@linux.intel.com>
2020-04-29 16:38:39 +03:00
thunderbolt: Add KUnit tests for credit allocation This adds a couple of KUnit tests for USB4 credit allocation. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2021-04-28 19:04:02 +03:00
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 <mika.westerberg@linux.intel.com>
2020-04-29 16:38:39 +03:00
thunderbolt: Add KUnit tests for credit allocation This adds a couple of KUnit tests for USB4 credit allocation. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2021-04-28 19:04:02 +03:00
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 <mika.westerberg@linux.intel.com>
2020-04-29 16:38:39 +03:00
thunderbolt: Add KUnit tests for credit allocation This adds a couple of KUnit tests for USB4 credit allocation. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2021-04-28 19:04:02 +03:00
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 <mika.westerberg@linux.intel.com>
2020-04-29 16:38:39 +03:00
thunderbolt: Add KUnit tests for credit allocation This adds a couple of KUnit tests for USB4 credit allocation. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2021-04-28 19:04:02 +03:00
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 <mika.westerberg@linux.intel.com>
2020-04-29 16:38:39 +03:00
thunderbolt: Add KUnit tests for credit allocation This adds a couple of KUnit tests for USB4 credit allocation. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2021-04-28 19:04:02 +03:00
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 <mika.westerberg@linux.intel.com>
2020-04-29 16:38:39 +03:00
thunderbolt: Add KUnit tests for credit allocation This adds a couple of KUnit tests for USB4 credit allocation. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2021-04-28 19:04:02 +03:00
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 <mika.westerberg@linux.intel.com>
2020-04-29 16:38:39 +03:00
thunderbolt: Add KUnit tests for credit allocation This adds a couple of KUnit tests for USB4 credit allocation. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2021-04-28 19:04:02 +03:00
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 <mika.westerberg@linux.intel.com>
2020-04-29 16:38:39 +03:00
thunderbolt: Add KUnit tests for credit allocation This adds a couple of KUnit tests for USB4 credit allocation. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2021-04-28 19:04:02 +03:00
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 <mika.westerberg@linux.intel.com>
2020-04-29 16:38:39 +03:00
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 <lkp@intel.com> Reported-by: Dan Carpenter <dan.carpenter@oracle.com> Reviewed-by: Yehezkel Bernat <YehezkelShB@gmail.com> Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2021-06-07 13:37:46 +03:00
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 <mika.westerberg@linux.intel.com>
2020-04-29 16:38:39 +03:00
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@intel.com> Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2022-05-09 23:49:04 +03:00
thunderbolt: Add KUnit tests for credit allocation This adds a couple of KUnit tests for USB4 credit allocation. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2021-04-28 19:04:02 +03:00
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 <mika.westerberg@linux.intel.com>
2020-04-29 16:38:39 +03:00
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/kbuild-all@lists.01.org/thread/FDKBHAV7QNLNFU5NBI2RKV56DWDSOLGM/ Fixes: 8f0877c26e4b ("thunderbolt: test: Remove some casts which are no longer required") Reported-by: kernel test robot <lkp@intel.com> Signed-off-by: David Gow <davidgow@google.com> Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>
2021-06-24 01:48:23 -07:00
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 <mika.westerberg@linux.intel.com>
2020-04-29 16:38:39 +03:00
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 <davidgow@google.com> Acked-by: Mika Westerberg <mika.westerberg@linux.intel.com> Reviewed-by: Brendan Higgins <brendanhiggins@google.com> Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>
2021-05-13 12:32:01 -07:00
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 <mika.westerberg@linux.intel.com>
2020-04-29 16:38:39 +03:00
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/kbuild-all@lists.01.org/thread/FDKBHAV7QNLNFU5NBI2RKV56DWDSOLGM/ Fixes: 8f0877c26e4b ("thunderbolt: test: Remove some casts which are no longer required") Reported-by: kernel test robot <lkp@intel.com> Signed-off-by: David Gow <davidgow@google.com> Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>
2021-06-24 01:48:23 -07:00
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 <mika.westerberg@linux.intel.com>
2020-04-29 16:38:39 +03:00
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/kbuild-all@lists.01.org/thread/FDKBHAV7QNLNFU5NBI2RKV56DWDSOLGM/ Fixes: 8f0877c26e4b ("thunderbolt: test: Remove some casts which are no longer required") Reported-by: kernel test robot <lkp@intel.com> Signed-off-by: David Gow <davidgow@google.com> Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>
2021-06-24 01:48:23 -07:00
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 <mika.westerberg@linux.intel.com>
2020-04-29 16:38:39 +03:00
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 <davidgow@google.com> Acked-by: Mika Westerberg <mika.westerberg@linux.intel.com> Reviewed-by: Brendan Higgins <brendanhiggins@google.com> Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>
2021-05-13 12:32:01 -07:00
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 <mika.westerberg@linux.intel.com>
2020-04-29 16:38:39 +03:00
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/kbuild-all@lists.01.org/thread/FDKBHAV7QNLNFU5NBI2RKV56DWDSOLGM/ Fixes: 8f0877c26e4b ("thunderbolt: test: Remove some casts which are no longer required") Reported-by: kernel test robot <lkp@intel.com> Signed-off-by: David Gow <davidgow@google.com> Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>
2021-06-24 01:48:23 -07:00
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 <mika.westerberg@linux.intel.com>
2020-04-29 16:38:39 +03:00
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/kbuild-all@lists.01.org/thread/FDKBHAV7QNLNFU5NBI2RKV56DWDSOLGM/ Fixes: 8f0877c26e4b ("thunderbolt: test: Remove some casts which are no longer required") Reported-by: kernel test robot <lkp@intel.com> Signed-off-by: David Gow <davidgow@google.com> Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>
2021-06-24 01:48:23 -07:00
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 <mika.westerberg@linux.intel.com>
2020-04-29 16:38:39 +03:00
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 <davidgow@google.com> Acked-by: Mika Westerberg <mika.westerberg@linux.intel.com> Reviewed-by: Brendan Higgins <brendanhiggins@google.com> Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>
2021-05-13 12:32:01 -07:00
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 <mika.westerberg@linux.intel.com>
2020-04-29 16:38:39 +03:00
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/kbuild-all@lists.01.org/thread/FDKBHAV7QNLNFU5NBI2RKV56DWDSOLGM/ Fixes: 8f0877c26e4b ("thunderbolt: test: Remove some casts which are no longer required") Reported-by: kernel test robot <lkp@intel.com> Signed-off-by: David Gow <davidgow@google.com> Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>
2021-06-24 01:48:23 -07:00
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 <mika.westerberg@linux.intel.com>
2020-04-29 16:38:39 +03:00
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/kbuild-all@lists.01.org/thread/FDKBHAV7QNLNFU5NBI2RKV56DWDSOLGM/ Fixes: 8f0877c26e4b ("thunderbolt: test: Remove some casts which are no longer required") Reported-by: kernel test robot <lkp@intel.com> Signed-off-by: David Gow <davidgow@google.com> Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>
2021-06-24 01:48:23 -07:00
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 <mika.westerberg@linux.intel.com>
2020-04-29 16:38:39 +03:00
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 <davidgow@google.com> Acked-by: Mika Westerberg <mika.westerberg@linux.intel.com> Reviewed-by: Brendan Higgins <brendanhiggins@google.com> Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>
2021-05-13 12:32:01 -07:00
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 <mika.westerberg@linux.intel.com>
2020-04-29 16:38:39 +03:00
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/kbuild-all@lists.01.org/thread/FDKBHAV7QNLNFU5NBI2RKV56DWDSOLGM/ Fixes: 8f0877c26e4b ("thunderbolt: test: Remove some casts which are no longer required") Reported-by: kernel test robot <lkp@intel.com> Signed-off-by: David Gow <davidgow@google.com> Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>
2021-06-24 01:48:23 -07:00
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 <mika.westerberg@linux.intel.com>
2020-04-29 16:38:39 +03:00
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/kbuild-all@lists.01.org/thread/FDKBHAV7QNLNFU5NBI2RKV56DWDSOLGM/ Fixes: 8f0877c26e4b ("thunderbolt: test: Remove some casts which are no longer required") Reported-by: kernel test robot <lkp@intel.com> Signed-off-by: David Gow <davidgow@google.com> Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>
2021-06-24 01:48:23 -07:00
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 <mika.westerberg@linux.intel.com>
2020-04-29 16:38:39 +03:00
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 <davidgow@google.com> Acked-by: Mika Westerberg <mika.westerberg@linux.intel.com> Reviewed-by: Brendan Higgins <brendanhiggins@google.com> Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>
2021-05-13 12:32:01 -07:00
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 <mika.westerberg@linux.intel.com>
2020-04-29 16:38:39 +03:00
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/kbuild-all@lists.01.org/thread/FDKBHAV7QNLNFU5NBI2RKV56DWDSOLGM/ Fixes: 8f0877c26e4b ("thunderbolt: test: Remove some casts which are no longer required") Reported-by: kernel test robot <lkp@intel.com> Signed-off-by: David Gow <davidgow@google.com> Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>
2021-06-24 01:48:23 -07:00
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 <mika.westerberg@linux.intel.com>
2020-04-29 16:38:39 +03:00
thunderbolt: test: use NULL macros Replace the NULL checks with the more specific and idiomatic NULL macros. Acked-by: Mika Westerberg <mika.westerberg@linux.intel.com> Acked-by: Daniel Latypov <dlatypov@google.com> Signed-off-by: Ricardo Ribalda <ribalda@chromium.org> Acked-by: Brendan Higgins <brendanhiggins@google.com> Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>
2022-02-11 17:42:43 +01:00
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 <mika.westerberg@linux.intel.com>
2020-04-29 16:38:39 +03:00
thunderbolt: test: use NULL macros Replace the NULL checks with the more specific and idiomatic NULL macros. Acked-by: Mika Westerberg <mika.westerberg@linux.intel.com> Acked-by: Daniel Latypov <dlatypov@google.com> Signed-off-by: Ricardo Ribalda <ribalda@chromium.org> Acked-by: Brendan Higgins <brendanhiggins@google.com> Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>
2022-02-11 17:42:43 +01:00
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 <mika.westerberg@linux.intel.com>
2020-04-29 16:38:39 +03:00
thunderbolt: test: use NULL macros Replace the NULL checks with the more specific and idiomatic NULL macros. Acked-by: Mika Westerberg <mika.westerberg@linux.intel.com> Acked-by: Daniel Latypov <dlatypov@google.com> Signed-off-by: Ricardo Ribalda <ribalda@chromium.org> Acked-by: Brendan Higgins <brendanhiggins@google.com> Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>
2022-02-11 17:42:43 +01:00
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 <davidgow@google.com> Acked-by: Mika Westerberg <mika.westerberg@linux.intel.com> Reviewed-by: Brendan Higgins <brendanhiggins@google.com> Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>
2021-05-13 12:32:01 -07:00
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 <mika.westerberg@linux.intel.com>
2020-04-29 16:38:39 +03:00
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/kbuild-all@lists.01.org/thread/FDKBHAV7QNLNFU5NBI2RKV56DWDSOLGM/ Fixes: 8f0877c26e4b ("thunderbolt: test: Remove some casts which are no longer required") Reported-by: kernel test robot <lkp@intel.com> Signed-off-by: David Gow <davidgow@google.com> Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>
2021-06-24 01:48:23 -07:00
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 <mika.westerberg@linux.intel.com>
2020-04-29 16:38:39 +03:00
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/kbuild-all@lists.01.org/thread/FDKBHAV7QNLNFU5NBI2RKV56DWDSOLGM/ Fixes: 8f0877c26e4b ("thunderbolt: test: Remove some casts which are no longer required") Reported-by: kernel test robot <lkp@intel.com> Signed-off-by: David Gow <davidgow@google.com> Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>
2021-06-24 01:48:23 -07:00
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 <mika.westerberg@linux.intel.com>
2020-04-29 16:38:39 +03:00
thunderbolt: test: use NULL macros Replace the NULL checks with the more specific and idiomatic NULL macros. Acked-by: Mika Westerberg <mika.westerberg@linux.intel.com> Acked-by: Daniel Latypov <dlatypov@google.com> Signed-off-by: Ricardo Ribalda <ribalda@chromium.org> Acked-by: Brendan Higgins <brendanhiggins@google.com> Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>
2022-02-11 17:42:43 +01:00
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 <davidgow@google.com> Acked-by: Mika Westerberg <mika.westerberg@linux.intel.com> Reviewed-by: Brendan Higgins <brendanhiggins@google.com> Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>
2021-05-13 12:32:01 -07:00
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 <mika.westerberg@linux.intel.com>
2020-04-29 16:38:39 +03:00
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/kbuild-all@lists.01.org/thread/FDKBHAV7QNLNFU5NBI2RKV56DWDSOLGM/ Fixes: 8f0877c26e4b ("thunderbolt: test: Remove some casts which are no longer required") Reported-by: kernel test robot <lkp@intel.com> Signed-off-by: David Gow <davidgow@google.com> Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>
2021-06-24 01:48:23 -07:00
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 <mika.westerberg@linux.intel.com>
2020-04-29 16:38:39 +03:00
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/kbuild-all@lists.01.org/thread/FDKBHAV7QNLNFU5NBI2RKV56DWDSOLGM/ Fixes: 8f0877c26e4b ("thunderbolt: test: Remove some casts which are no longer required") Reported-by: kernel test robot <lkp@intel.com> Signed-off-by: David Gow <davidgow@google.com> Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>
2021-06-24 01:48:23 -07:00
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 <mika.westerberg@linux.intel.com>
2020-04-29 16:38:39 +03:00
thunderbolt: test: use NULL macros Replace the NULL checks with the more specific and idiomatic NULL macros. Acked-by: Mika Westerberg <mika.westerberg@linux.intel.com> Acked-by: Daniel Latypov <dlatypov@google.com> Signed-off-by: Ricardo Ribalda <ribalda@chromium.org> Acked-by: Brendan Higgins <brendanhiggins@google.com> Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>
2022-02-11 17:42:43 +01:00
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 <davidgow@google.com> Acked-by: Mika Westerberg <mika.westerberg@linux.intel.com> Reviewed-by: Brendan Higgins <brendanhiggins@google.com> Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>
2021-05-13 12:32:01 -07:00
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 <mika.westerberg@linux.intel.com>
2020-04-29 16:38:39 +03:00
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/kbuild-all@lists.01.org/thread/FDKBHAV7QNLNFU5NBI2RKV56DWDSOLGM/ Fixes: 8f0877c26e4b ("thunderbolt: test: Remove some casts which are no longer required") Reported-by: kernel test robot <lkp@intel.com> Signed-off-by: David Gow <davidgow@google.com> Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>
2021-06-24 01:48:23 -07:00
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 <mika.westerberg@linux.intel.com>
2020-04-29 16:38:39 +03:00
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/kbuild-all@lists.01.org/thread/FDKBHAV7QNLNFU5NBI2RKV56DWDSOLGM/ Fixes: 8f0877c26e4b ("thunderbolt: test: Remove some casts which are no longer required") Reported-by: kernel test robot <lkp@intel.com> Signed-off-by: David Gow <davidgow@google.com> Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>
2021-06-24 01:48:23 -07:00
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 <mika.westerberg@linux.intel.com>
2020-04-29 16:38:39 +03:00
thunderbolt: test: use NULL macros Replace the NULL checks with the more specific and idiomatic NULL macros. Acked-by: Mika Westerberg <mika.westerberg@linux.intel.com> Acked-by: Daniel Latypov <dlatypov@google.com> Signed-off-by: Ricardo Ribalda <ribalda@chromium.org> Acked-by: Brendan Higgins <brendanhiggins@google.com> Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>
2022-02-11 17:42:43 +01:00
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 <davidgow@google.com> Acked-by: Mika Westerberg <mika.westerberg@linux.intel.com> Reviewed-by: Brendan Higgins <brendanhiggins@google.com> Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>
2021-05-13 12:32:01 -07:00
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 <mika.westerberg@linux.intel.com>
2020-04-29 16:38:39 +03:00
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/kbuild-all@lists.01.org/thread/FDKBHAV7QNLNFU5NBI2RKV56DWDSOLGM/ Fixes: 8f0877c26e4b ("thunderbolt: test: Remove some casts which are no longer required") Reported-by: kernel test robot <lkp@intel.com> Signed-off-by: David Gow <davidgow@google.com> Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>
2021-06-24 01:48:23 -07:00
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 <mika.westerberg@linux.intel.com>
2020-04-29 16:38:39 +03:00
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/kbuild-all@lists.01.org/thread/FDKBHAV7QNLNFU5NBI2RKV56DWDSOLGM/ Fixes: 8f0877c26e4b ("thunderbolt: test: Remove some casts which are no longer required") Reported-by: kernel test robot <lkp@intel.com> Signed-off-by: David Gow <davidgow@google.com> Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>
2021-06-24 01:48:23 -07:00
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 <mika.westerberg@linux.intel.com>
2020-04-29 16:38:39 +03:00
thunderbolt: test: use NULL macros Replace the NULL checks with the more specific and idiomatic NULL macros. Acked-by: Mika Westerberg <mika.westerberg@linux.intel.com> Acked-by: Daniel Latypov <dlatypov@google.com> Signed-off-by: Ricardo Ribalda <ribalda@chromium.org> Acked-by: Brendan Higgins <brendanhiggins@google.com> Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>
2022-02-11 17:42:43 +01:00
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 <davidgow@google.com> Acked-by: Mika Westerberg <mika.westerberg@linux.intel.com> Reviewed-by: Brendan Higgins <brendanhiggins@google.com> Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>
2021-05-13 12:32:01 -07:00
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 <mika.westerberg@linux.intel.com>
2020-04-29 16:38:39 +03:00
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/kbuild-all@lists.01.org/thread/FDKBHAV7QNLNFU5NBI2RKV56DWDSOLGM/ Fixes: 8f0877c26e4b ("thunderbolt: test: Remove some casts which are no longer required") Reported-by: kernel test robot <lkp@intel.com> Signed-off-by: David Gow <davidgow@google.com> Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>
2021-06-24 01:48:23 -07:00
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 <mika.westerberg@linux.intel.com>
2020-04-29 16:38:39 +03:00
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/kbuild-all@lists.01.org/thread/FDKBHAV7QNLNFU5NBI2RKV56DWDSOLGM/ Fixes: 8f0877c26e4b ("thunderbolt: test: Remove some casts which are no longer required") Reported-by: kernel test robot <lkp@intel.com> Signed-off-by: David Gow <davidgow@google.com> Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>
2021-06-24 01:48:23 -07:00
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 <mika.westerberg@linux.intel.com>
2020-04-29 16:38:39 +03:00
thunderbolt: test: use NULL macros Replace the NULL checks with the more specific and idiomatic NULL macros. Acked-by: Mika Westerberg <mika.westerberg@linux.intel.com> Acked-by: Daniel Latypov <dlatypov@google.com> Signed-off-by: Ricardo Ribalda <ribalda@chromium.org> Acked-by: Brendan Higgins <brendanhiggins@google.com> Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>
2022-02-11 17:42:43 +01:00
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 <davidgow@google.com> Acked-by: Mika Westerberg <mika.westerberg@linux.intel.com> Reviewed-by: Brendan Higgins <brendanhiggins@google.com> Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>
2021-05-13 12:32:01 -07:00
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 <mika.westerberg@linux.intel.com>
2020-04-29 16:38:39 +03:00
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/kbuild-all@lists.01.org/thread/FDKBHAV7QNLNFU5NBI2RKV56DWDSOLGM/ Fixes: 8f0877c26e4b ("thunderbolt: test: Remove some casts which are no longer required") Reported-by: kernel test robot <lkp@intel.com> Signed-off-by: David Gow <davidgow@google.com> Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>
2021-06-24 01:48:23 -07:00
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 <mika.westerberg@linux.intel.com>
2020-04-29 16:38:39 +03:00
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/kbuild-all@lists.01.org/thread/FDKBHAV7QNLNFU5NBI2RKV56DWDSOLGM/ Fixes: 8f0877c26e4b ("thunderbolt: test: Remove some casts which are no longer required") Reported-by: kernel test robot <lkp@intel.com> Signed-off-by: David Gow <davidgow@google.com> Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>
2021-06-24 01:48:23 -07:00
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 <mika.westerberg@linux.intel.com>
2020-04-29 16:38:39 +03:00
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 <mika.westerberg@linux.intel.com>
2020-05-04 17:10:40 +03:00
thunderbolt: test: use NULL macros Replace the NULL checks with the more specific and idiomatic NULL macros. Acked-by: Mika Westerberg <mika.westerberg@linux.intel.com> Acked-by: Daniel Latypov <dlatypov@google.com> Signed-off-by: Ricardo Ribalda <ribalda@chromium.org> Acked-by: Brendan Higgins <brendanhiggins@google.com> Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>
2022-02-11 17:42:43 +01:00
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 <davidgow@google.com> Acked-by: Mika Westerberg <mika.westerberg@linux.intel.com> Reviewed-by: Brendan Higgins <brendanhiggins@google.com> Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>
2021-05-13 12:32:01 -07:00
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 <mika.westerberg@linux.intel.com>
2020-05-04 17:10:40 +03:00
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 <davidgow@google.com> Acked-by: Mika Westerberg <mika.westerberg@linux.intel.com> Reviewed-by: Brendan Higgins <brendanhiggins@google.com> Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>
2021-05-13 12:32:01 -07:00
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 <mika.westerberg@linux.intel.com>
2020-05-04 17:10:40 +03:00
thunderbolt: test: use NULL macros Replace the NULL checks with the more specific and idiomatic NULL macros. Acked-by: Mika Westerberg <mika.westerberg@linux.intel.com> Acked-by: Daniel Latypov <dlatypov@google.com> Signed-off-by: Ricardo Ribalda <ribalda@chromium.org> Acked-by: Brendan Higgins <brendanhiggins@google.com> Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>
2022-02-11 17:42:43 +01:00
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 <davidgow@google.com> Acked-by: Mika Westerberg <mika.westerberg@linux.intel.com> Reviewed-by: Brendan Higgins <brendanhiggins@google.com> Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>
2021-05-13 12:32:01 -07:00
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 <mika.westerberg@linux.intel.com>
2020-05-04 17:10:40 +03:00
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 <davidgow@google.com> Acked-by: Mika Westerberg <mika.westerberg@linux.intel.com> Reviewed-by: Brendan Higgins <brendanhiggins@google.com> Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>
2021-05-13 12:32:01 -07:00
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 <mika.westerberg@linux.intel.com>
2020-05-04 17:10:40 +03:00
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 <mika.westerberg@linux.intel.com>
2024-08-20 08:56:02 +03:00
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 <mika.westerberg@linux.intel.com>
2020-05-04 17:10:40 +03:00
thunderbolt: Make the DP tunnel activation callback mandatory tb_tunnel_alloc_dp() takes an optional callback which is run from dprx_work once the DPRX capabilities read has completed. Without that callback tb_dp_dprx_start() reads the capabilities synchronously and never queues the work. It however always takes a tunnel reference which is only dropped by dprx_work itself or by tb_dp_dprx_stop() when cancel_delayed_work() actually canceled that work. That reference is thus leaked for every tunnel without a callback. The only tunnels without one are those from tb_tunnel_discover_dp(), which are activated again when restoring from hibernation. Pass the callback to tb_tunnel_discover_dp() as well and drop the synchronous path such that the DPRX capabilities are always read from dprx_work. Hibernation restore then also no longer blocks for up to 12 seconds while waiting for that read to complete. Also fix up the KUnit tests. Fixes: d6d458d42e1e ("thunderbolt: Handle DisplayPort tunnel activation asynchronously") Cc: stable@vger.kernel.org Signed-off-by: Sven Peter <sven@kernel.org> Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2026-08-29 10:08:34 +02:00
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 <mika.westerberg@linux.intel.com>
2020-05-04 17:10:40 +03:00
thunderbolt: Make the DP tunnel activation callback mandatory tb_tunnel_alloc_dp() takes an optional callback which is run from dprx_work once the DPRX capabilities read has completed. Without that callback tb_dp_dprx_start() reads the capabilities synchronously and never queues the work. It however always takes a tunnel reference which is only dropped by dprx_work itself or by tb_dp_dprx_stop() when cancel_delayed_work() actually canceled that work. That reference is thus leaked for every tunnel without a callback. The only tunnels without one are those from tb_tunnel_discover_dp(), which are activated again when restoring from hibernation. Pass the callback to tb_tunnel_discover_dp() as well and drop the synchronous path such that the DPRX capabilities are always read from dprx_work. Hibernation restore then also no longer blocks for up to 12 seconds while waiting for that read to complete. Also fix up the KUnit tests. Fixes: d6d458d42e1e ("thunderbolt: Handle DisplayPort tunnel activation asynchronously") Cc: stable@vger.kernel.org Signed-off-by: Sven Peter <sven@kernel.org> Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2026-08-29 10:08:34 +02:00
thunderbolt: test: use NULL macros Replace the NULL checks with the more specific and idiomatic NULL macros. Acked-by: Mika Westerberg <mika.westerberg@linux.intel.com> Acked-by: Daniel Latypov <dlatypov@google.com> Signed-off-by: Ricardo Ribalda <ribalda@chromium.org> Acked-by: Brendan Higgins <brendanhiggins@google.com> Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>
2022-02-11 17:42:43 +01:00
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 <davidgow@google.com> Acked-by: Mika Westerberg <mika.westerberg@linux.intel.com> Reviewed-by: Brendan Higgins <brendanhiggins@google.com> Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>
2021-05-13 12:32:01 -07:00
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 <mika.westerberg@linux.intel.com>
2020-05-04 17:10:40 +03:00
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 <davidgow@google.com> Acked-by: Mika Westerberg <mika.westerberg@linux.intel.com> Reviewed-by: Brendan Higgins <brendanhiggins@google.com> Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>
2021-05-13 12:32:01 -07:00
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 <mika.westerberg@linux.intel.com>
2020-05-04 17:10:40 +03:00
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 <mika.westerberg@linux.intel.com>
2024-08-20 08:56:02 +03:00
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 <mika.westerberg@linux.intel.com>
2020-05-04 17:10:40 +03:00
thunderbolt: Make the DP tunnel activation callback mandatory tb_tunnel_alloc_dp() takes an optional callback which is run from dprx_work once the DPRX capabilities read has completed. Without that callback tb_dp_dprx_start() reads the capabilities synchronously and never queues the work. It however always takes a tunnel reference which is only dropped by dprx_work itself or by tb_dp_dprx_stop() when cancel_delayed_work() actually canceled that work. That reference is thus leaked for every tunnel without a callback. The only tunnels without one are those from tb_tunnel_discover_dp(), which are activated again when restoring from hibernation. Pass the callback to tb_tunnel_discover_dp() as well and drop the synchronous path such that the DPRX capabilities are always read from dprx_work. Hibernation restore then also no longer blocks for up to 12 seconds while waiting for that read to complete. Also fix up the KUnit tests. Fixes: d6d458d42e1e ("thunderbolt: Handle DisplayPort tunnel activation asynchronously") Cc: stable@vger.kernel.org Signed-off-by: Sven Peter <sven@kernel.org> Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2026-08-29 10:08:34 +02:00
thunderbolt: test: use NULL macros Replace the NULL checks with the more specific and idiomatic NULL macros. Acked-by: Mika Westerberg <mika.westerberg@linux.intel.com> Acked-by: Daniel Latypov <dlatypov@google.com> Signed-off-by: Ricardo Ribalda <ribalda@chromium.org> Acked-by: Brendan Higgins <brendanhiggins@google.com> Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>
2022-02-11 17:42:43 +01:00
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 <davidgow@google.com> Acked-by: Mika Westerberg <mika.westerberg@linux.intel.com> Reviewed-by: Brendan Higgins <brendanhiggins@google.com> Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>
2021-05-13 12:32:01 -07:00
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 <mika.westerberg@linux.intel.com>
2020-05-04 17:10:40 +03:00
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 <davidgow@google.com> Acked-by: Mika Westerberg <mika.westerberg@linux.intel.com> Reviewed-by: Brendan Higgins <brendanhiggins@google.com> Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>
2021-05-13 12:32:01 -07:00
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 <mika.westerberg@linux.intel.com>
2020-05-04 17:10:40 +03:00
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 <mika.westerberg@linux.intel.com>
2024-08-20 08:56:02 +03:00
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 <mika.westerberg@linux.intel.com>
2020-05-04 17:10:40 +03:00
thunderbolt: Make the DP tunnel activation callback mandatory tb_tunnel_alloc_dp() takes an optional callback which is run from dprx_work once the DPRX capabilities read has completed. Without that callback tb_dp_dprx_start() reads the capabilities synchronously and never queues the work. It however always takes a tunnel reference which is only dropped by dprx_work itself or by tb_dp_dprx_stop() when cancel_delayed_work() actually canceled that work. That reference is thus leaked for every tunnel without a callback. The only tunnels without one are those from tb_tunnel_discover_dp(), which are activated again when restoring from hibernation. Pass the callback to tb_tunnel_discover_dp() as well and drop the synchronous path such that the DPRX capabilities are always read from dprx_work. Hibernation restore then also no longer blocks for up to 12 seconds while waiting for that read to complete. Also fix up the KUnit tests. Fixes: d6d458d42e1e ("thunderbolt: Handle DisplayPort tunnel activation asynchronously") Cc: stable@vger.kernel.org Signed-off-by: Sven Peter <sven@kernel.org> Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2026-08-29 10:08:34 +02:00
thunderbolt: test: use NULL macros Replace the NULL checks with the more specific and idiomatic NULL macros. Acked-by: Mika Westerberg <mika.westerberg@linux.intel.com> Acked-by: Daniel Latypov <dlatypov@google.com> Signed-off-by: Ricardo Ribalda <ribalda@chromium.org> Acked-by: Brendan Higgins <brendanhiggins@google.com> Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>
2022-02-11 17:42:43 +01:00
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 <davidgow@google.com> Acked-by: Mika Westerberg <mika.westerberg@linux.intel.com> Reviewed-by: Brendan Higgins <brendanhiggins@google.com> Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>
2021-05-13 12:32:01 -07:00
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 <mika.westerberg@linux.intel.com>
2020-05-04 17:10:40 +03:00
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 <davidgow@google.com> Acked-by: Mika Westerberg <mika.westerberg@linux.intel.com> Reviewed-by: Brendan Higgins <brendanhiggins@google.com> Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>
2021-05-13 12:32:01 -07:00
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 <mika.westerberg@linux.intel.com>
2020-05-04 17:10:40 +03:00
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 <mika.westerberg@linux.intel.com>
2024-08-20 08:56:02 +03:00
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 <mika.westerberg@linux.intel.com>
2020-05-04 17:10:40 +03:00
thunderbolt: Make the DP tunnel activation callback mandatory tb_tunnel_alloc_dp() takes an optional callback which is run from dprx_work once the DPRX capabilities read has completed. Without that callback tb_dp_dprx_start() reads the capabilities synchronously and never queues the work. It however always takes a tunnel reference which is only dropped by dprx_work itself or by tb_dp_dprx_stop() when cancel_delayed_work() actually canceled that work. That reference is thus leaked for every tunnel without a callback. The only tunnels without one are those from tb_tunnel_discover_dp(), which are activated again when restoring from hibernation. Pass the callback to tb_tunnel_discover_dp() as well and drop the synchronous path such that the DPRX capabilities are always read from dprx_work. Hibernation restore then also no longer blocks for up to 12 seconds while waiting for that read to complete. Also fix up the KUnit tests. Fixes: d6d458d42e1e ("thunderbolt: Handle DisplayPort tunnel activation asynchronously") Cc: stable@vger.kernel.org Signed-off-by: Sven Peter <sven@kernel.org> Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2026-08-29 10:08:34 +02:00
thunderbolt: test: use NULL macros Replace the NULL checks with the more specific and idiomatic NULL macros. Acked-by: Mika Westerberg <mika.westerberg@linux.intel.com> Acked-by: Daniel Latypov <dlatypov@google.com> Signed-off-by: Ricardo Ribalda <ribalda@chromium.org> Acked-by: Brendan Higgins <brendanhiggins@google.com> Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>
2022-02-11 17:42:43 +01:00
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 <davidgow@google.com> Acked-by: Mika Westerberg <mika.westerberg@linux.intel.com> Reviewed-by: Brendan Higgins <brendanhiggins@google.com> Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>
2021-05-13 12:32:01 -07:00
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 <mika.westerberg@linux.intel.com>
2020-05-04 17:10:40 +03:00
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 <davidgow@google.com> Acked-by: Mika Westerberg <mika.westerberg@linux.intel.com> Reviewed-by: Brendan Higgins <brendanhiggins@google.com> Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>
2021-05-13 12:32:01 -07:00
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 <mika.westerberg@linux.intel.com>
2020-05-04 17:10:40 +03:00
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 <mika.westerberg@linux.intel.com>
2024-08-20 08:56:02 +03:00
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 <mika.westerberg@linux.intel.com>
2020-05-04 17:10:40 +03:00
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 <mika.westerberg@linux.intel.com>
2022-02-14 14:09:50 +02:00
thunderbolt: Make the DP tunnel activation callback mandatory tb_tunnel_alloc_dp() takes an optional callback which is run from dprx_work once the DPRX capabilities read has completed. Without that callback tb_dp_dprx_start() reads the capabilities synchronously and never queues the work. It however always takes a tunnel reference which is only dropped by dprx_work itself or by tb_dp_dprx_stop() when cancel_delayed_work() actually canceled that work. That reference is thus leaked for every tunnel without a callback. The only tunnels without one are those from tb_tunnel_discover_dp(), which are activated again when restoring from hibernation. Pass the callback to tb_tunnel_discover_dp() as well and drop the synchronous path such that the DPRX capabilities are always read from dprx_work. Hibernation restore then also no longer blocks for up to 12 seconds while waiting for that read to complete. Also fix up the KUnit tests. Fixes: d6d458d42e1e ("thunderbolt: Handle DisplayPort tunnel activation asynchronously") Cc: stable@vger.kernel.org Signed-off-by: Sven Peter <sven@kernel.org> Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2026-08-29 10:08:34 +02:00
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 <mika.westerberg@linux.intel.com>
2022-02-14 14:09:50 +02:00
thunderbolt: Make the DP tunnel activation callback mandatory tb_tunnel_alloc_dp() takes an optional callback which is run from dprx_work once the DPRX capabilities read has completed. Without that callback tb_dp_dprx_start() reads the capabilities synchronously and never queues the work. It however always takes a tunnel reference which is only dropped by dprx_work itself or by tb_dp_dprx_stop() when cancel_delayed_work() actually canceled that work. That reference is thus leaked for every tunnel without a callback. The only tunnels without one are those from tb_tunnel_discover_dp(), which are activated again when restoring from hibernation. Pass the callback to tb_tunnel_discover_dp() as well and drop the synchronous path such that the DPRX capabilities are always read from dprx_work. Hibernation restore then also no longer blocks for up to 12 seconds while waiting for that read to complete. Also fix up the KUnit tests. Fixes: d6d458d42e1e ("thunderbolt: Handle DisplayPort tunnel activation asynchronously") Cc: stable@vger.kernel.org Signed-off-by: Sven Peter <sven@kernel.org> Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2026-08-29 10:08:34 +02:00
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 <mika.westerberg@linux.intel.com>
2022-02-14 14:09:50 +02:00
thunderbolt: Make the DP tunnel activation callback mandatory tb_tunnel_alloc_dp() takes an optional callback which is run from dprx_work once the DPRX capabilities read has completed. Without that callback tb_dp_dprx_start() reads the capabilities synchronously and never queues the work. It however always takes a tunnel reference which is only dropped by dprx_work itself or by tb_dp_dprx_stop() when cancel_delayed_work() actually canceled that work. That reference is thus leaked for every tunnel without a callback. The only tunnels without one are those from tb_tunnel_discover_dp(), which are activated again when restoring from hibernation. Pass the callback to tb_tunnel_discover_dp() as well and drop the synchronous path such that the DPRX capabilities are always read from dprx_work. Hibernation restore then also no longer blocks for up to 12 seconds while waiting for that read to complete. Also fix up the KUnit tests. Fixes: d6d458d42e1e ("thunderbolt: Handle DisplayPort tunnel activation asynchronously") Cc: stable@vger.kernel.org Signed-off-by: Sven Peter <sven@kernel.org> Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2026-08-29 10:08:34 +02:00
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 <mika.westerberg@linux.intel.com>
2022-02-14 14:09:50 +02:00
thunderbolt: test: Release third DP tunnel 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 <raoxu@uniontech.com> Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2026-06-01 14:28:54 +08:00
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 <mika.westerberg@linux.intel.com>
2024-08-20 08:56:02 +03:00
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 <mika.westerberg@linux.intel.com>
2022-02-14 14:09:50 +02:00
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 <mika.westerberg@linux.intel.com>
2020-05-04 17:10:40 +03:00
thunderbolt: test: use NULL macros Replace the NULL checks with the more specific and idiomatic NULL macros. Acked-by: Mika Westerberg <mika.westerberg@linux.intel.com> Acked-by: Daniel Latypov <dlatypov@google.com> Signed-off-by: Ricardo Ribalda <ribalda@chromium.org> Acked-by: Brendan Higgins <brendanhiggins@google.com> Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>
2022-02-11 17:42:43 +01:00
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 <davidgow@google.com> Acked-by: Mika Westerberg <mika.westerberg@linux.intel.com> Reviewed-by: Brendan Higgins <brendanhiggins@google.com> Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>
2021-05-13 12:32:01 -07:00
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 <mika.westerberg@linux.intel.com>
2020-05-04 17:10:40 +03:00
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 <davidgow@google.com> Acked-by: Mika Westerberg <mika.westerberg@linux.intel.com> Reviewed-by: Brendan Higgins <brendanhiggins@google.com> Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>
2021-05-13 12:32:01 -07:00
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 <mika.westerberg@linux.intel.com>
2020-05-04 17:10:40 +03:00
thunderbolt: test: use NULL macros Replace the NULL checks with the more specific and idiomatic NULL macros. Acked-by: Mika Westerberg <mika.westerberg@linux.intel.com> Acked-by: Daniel Latypov <dlatypov@google.com> Signed-off-by: Ricardo Ribalda <ribalda@chromium.org> Acked-by: Brendan Higgins <brendanhiggins@google.com> Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>
2022-02-11 17:42:43 +01:00
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 <davidgow@google.com> Acked-by: Mika Westerberg <mika.westerberg@linux.intel.com> Reviewed-by: Brendan Higgins <brendanhiggins@google.com> Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>
2021-05-13 12:32:01 -07:00
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 <mika.westerberg@linux.intel.com>
2020-05-04 17:10:40 +03:00
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 <davidgow@google.com> Acked-by: Mika Westerberg <mika.westerberg@linux.intel.com> Reviewed-by: Brendan Higgins <brendanhiggins@google.com> Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>
2021-05-13 12:32:01 -07:00
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 <mika.westerberg@linux.intel.com>
2020-05-04 17:10:40 +03:00
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 <mika.westerberg@linux.intel.com>
2024-08-20 08:56:02 +03:00
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 <mika.westerberg@linux.intel.com>
2020-05-04 17:10:40 +03:00
thunderbolt: Make the DP tunnel activation callback mandatory tb_tunnel_alloc_dp() takes an optional callback which is run from dprx_work once the DPRX capabilities read has completed. Without that callback tb_dp_dprx_start() reads the capabilities synchronously and never queues the work. It however always takes a tunnel reference which is only dropped by dprx_work itself or by tb_dp_dprx_stop() when cancel_delayed_work() actually canceled that work. That reference is thus leaked for every tunnel without a callback. The only tunnels without one are those from tb_tunnel_discover_dp(), which are activated again when restoring from hibernation. Pass the callback to tb_tunnel_discover_dp() as well and drop the synchronous path such that the DPRX capabilities are always read from dprx_work. Hibernation restore then also no longer blocks for up to 12 seconds while waiting for that read to complete. Also fix up the KUnit tests. Fixes: d6d458d42e1e ("thunderbolt: Handle DisplayPort tunnel activation asynchronously") Cc: stable@vger.kernel.org Signed-off-by: Sven Peter <sven@kernel.org> Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2026-08-29 10:08:34 +02:00
thunderbolt: test: use NULL macros Replace the NULL checks with the more specific and idiomatic NULL macros. Acked-by: Mika Westerberg <mika.westerberg@linux.intel.com> Acked-by: Daniel Latypov <dlatypov@google.com> Signed-off-by: Ricardo Ribalda <ribalda@chromium.org> Acked-by: Brendan Higgins <brendanhiggins@google.com> Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>
2022-02-11 17:42:43 +01:00
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 <mika.westerberg@linux.intel.com>
2020-05-04 17:10:40 +03:00
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 <mika.westerberg@linux.intel.com>
2024-08-20 08:56:02 +03:00
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 <mika.westerberg@linux.intel.com>
2020-05-04 17:10:40 +03:00
thunderbolt: Add KUnit tests for DMA tunnels Add a couple of tests to check DMA tunneling functionality. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2021-01-08 16:32:19 +02:00
thunderbolt: test: use NULL macros Replace the NULL checks with the more specific and idiomatic NULL macros. Acked-by: Mika Westerberg <mika.westerberg@linux.intel.com> Acked-by: Daniel Latypov <dlatypov@google.com> Signed-off-by: Ricardo Ribalda <ribalda@chromium.org> Acked-by: Brendan Higgins <brendanhiggins@google.com> Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>
2022-02-11 17:42:43 +01:00
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 <davidgow@google.com> Acked-by: Mika Westerberg <mika.westerberg@linux.intel.com> Reviewed-by: Brendan Higgins <brendanhiggins@google.com> Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>
2021-05-13 12:32:01 -07:00
thunderbolt: Add KUnit tests for DMA tunnels Add a couple of tests to check DMA tunneling functionality. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2021-01-08 16:32:19 +02:00
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 <davidgow@google.com> Acked-by: Mika Westerberg <mika.westerberg@linux.intel.com> Reviewed-by: Brendan Higgins <brendanhiggins@google.com> Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>
2021-05-13 12:32:01 -07:00
thunderbolt: Add KUnit tests for DMA tunnels Add a couple of tests to check DMA tunneling functionality. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2021-01-08 16:32:19 +02:00
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 <mika.westerberg@linux.intel.com>
2024-08-20 08:56:02 +03:00
thunderbolt: Add KUnit tests for DMA tunnels Add a couple of tests to check DMA tunneling functionality. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2021-01-08 16:32:19 +02:00
thunderbolt: test: use NULL macros Replace the NULL checks with the more specific and idiomatic NULL macros. Acked-by: Mika Westerberg <mika.westerberg@linux.intel.com> Acked-by: Daniel Latypov <dlatypov@google.com> Signed-off-by: Ricardo Ribalda <ribalda@chromium.org> Acked-by: Brendan Higgins <brendanhiggins@google.com> Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>
2022-02-11 17:42:43 +01:00
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 <davidgow@google.com> Acked-by: Mika Westerberg <mika.westerberg@linux.intel.com> Reviewed-by: Brendan Higgins <brendanhiggins@google.com> Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>
2021-05-13 12:32:01 -07:00
thunderbolt: Add KUnit tests for DMA tunnels Add a couple of tests to check DMA tunneling functionality. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2021-01-08 16:32:19 +02:00
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 <davidgow@google.com> Acked-by: Mika Westerberg <mika.westerberg@linux.intel.com> Reviewed-by: Brendan Higgins <brendanhiggins@google.com> Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>
2021-05-13 12:32:01 -07:00
thunderbolt: Add KUnit tests for DMA tunnels Add a couple of tests to check DMA tunneling functionality. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2021-01-08 16:32:19 +02:00
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 <mika.westerberg@linux.intel.com>
2024-08-20 08:56:02 +03:00
thunderbolt: Add KUnit tests for DMA tunnels Add a couple of tests to check DMA tunneling functionality. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2021-01-08 16:32:19 +02:00
thunderbolt: test: use NULL macros Replace the NULL checks with the more specific and idiomatic NULL macros. Acked-by: Mika Westerberg <mika.westerberg@linux.intel.com> Acked-by: Daniel Latypov <dlatypov@google.com> Signed-off-by: Ricardo Ribalda <ribalda@chromium.org> Acked-by: Brendan Higgins <brendanhiggins@google.com> Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>
2022-02-11 17:42:43 +01:00
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 <davidgow@google.com> Acked-by: Mika Westerberg <mika.westerberg@linux.intel.com> Reviewed-by: Brendan Higgins <brendanhiggins@google.com> Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>
2021-05-13 12:32:01 -07:00
thunderbolt: Add KUnit tests for DMA tunnels Add a couple of tests to check DMA tunneling functionality. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2021-01-08 16:32:19 +02:00
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 <davidgow@google.com> Acked-by: Mika Westerberg <mika.westerberg@linux.intel.com> Reviewed-by: Brendan Higgins <brendanhiggins@google.com> Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>
2021-05-13 12:32:01 -07:00
thunderbolt: Add KUnit tests for DMA tunnels Add a couple of tests to check DMA tunneling functionality. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2021-01-08 16:32:19 +02:00
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 <mika.westerberg@linux.intel.com>
2024-08-20 08:56:02 +03:00
thunderbolt: Add KUnit tests for DMA tunnels Add a couple of tests to check DMA tunneling functionality. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2021-01-08 16:32:19 +02:00
thunderbolt: test: use NULL macros Replace the NULL checks with the more specific and idiomatic NULL macros. Acked-by: Mika Westerberg <mika.westerberg@linux.intel.com> Acked-by: Daniel Latypov <dlatypov@google.com> Signed-off-by: Ricardo Ribalda <ribalda@chromium.org> Acked-by: Brendan Higgins <brendanhiggins@google.com> Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>
2022-02-11 17:42:43 +01:00
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 <davidgow@google.com> Acked-by: Mika Westerberg <mika.westerberg@linux.intel.com> Reviewed-by: Brendan Higgins <brendanhiggins@google.com> Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>
2021-05-13 12:32:01 -07:00
thunderbolt: Add KUnit tests for DMA tunnels Add a couple of tests to check DMA tunneling functionality. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2021-01-08 16:32:19 +02:00
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 <davidgow@google.com> Acked-by: Mika Westerberg <mika.westerberg@linux.intel.com> Reviewed-by: Brendan Higgins <brendanhiggins@google.com> Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>
2021-05-13 12:32:01 -07:00
thunderbolt: Add KUnit tests for DMA tunnels Add a couple of tests to check DMA tunneling functionality. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2021-01-08 16:32:19 +02:00
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 <mika.westerberg@linux.intel.com>
2024-08-20 08:56:02 +03:00
thunderbolt: Add KUnit tests for DMA tunnels Add a couple of tests to check DMA tunneling functionality. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2021-01-08 16:32:19 +02:00
thunderbolt: test: use NULL macros Replace the NULL checks with the more specific and idiomatic NULL macros. Acked-by: Mika Westerberg <mika.westerberg@linux.intel.com> Acked-by: Daniel Latypov <dlatypov@google.com> Signed-off-by: Ricardo Ribalda <ribalda@chromium.org> Acked-by: Brendan Higgins <brendanhiggins@google.com> Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>
2022-02-11 17:42:43 +01:00
thunderbolt: Add KUnit tests for DMA tunnels Add a couple of tests to check DMA tunneling functionality. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2021-01-08 16:32:19 +02:00
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 <mika.westerberg@linux.intel.com>
2024-08-20 08:56:02 +03:00
thunderbolt: Add KUnit tests for DMA tunnels Add a couple of tests to check DMA tunneling functionality. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2021-01-08 16:32:19 +02:00
thunderbolt: test: use NULL macros Replace the NULL checks with the more specific and idiomatic NULL macros. Acked-by: Mika Westerberg <mika.westerberg@linux.intel.com> Acked-by: Daniel Latypov <dlatypov@google.com> Signed-off-by: Ricardo Ribalda <ribalda@chromium.org> Acked-by: Brendan Higgins <brendanhiggins@google.com> Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>
2022-02-11 17:42:43 +01:00
thunderbolt: Add KUnit tests for DMA tunnels Add a couple of tests to check DMA tunneling functionality. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2021-01-08 16:32:19 +02:00
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 <mika.westerberg@linux.intel.com>
2024-08-20 08:56:02 +03:00
thunderbolt: Add KUnit tests for DMA tunnels Add a couple of tests to check DMA tunneling functionality. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2021-01-08 16:32:19 +02:00
thunderbolt: test: use NULL macros Replace the NULL checks with the more specific and idiomatic NULL macros. Acked-by: Mika Westerberg <mika.westerberg@linux.intel.com> Acked-by: Daniel Latypov <dlatypov@google.com> Signed-off-by: Ricardo Ribalda <ribalda@chromium.org> Acked-by: Brendan Higgins <brendanhiggins@google.com> Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>
2022-02-11 17:42:43 +01:00
thunderbolt: Add KUnit tests for DMA tunnels Add a couple of tests to check DMA tunneling functionality. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2021-01-08 16:32:19 +02:00
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 <mika.westerberg@linux.intel.com>
2024-08-20 08:56:02 +03:00
thunderbolt: Add KUnit tests for DMA tunnels Add a couple of tests to check DMA tunneling functionality. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2021-01-08 16:32:19 +02:00
thunderbolt: Add KUnit tests for credit allocation This adds a couple of KUnit tests for USB4 credit allocation. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2021-04-28 19:04:02 +03:00
thunderbolt: test: use NULL macros Replace the NULL checks with the more specific and idiomatic NULL macros. Acked-by: Mika Westerberg <mika.westerberg@linux.intel.com> Acked-by: Daniel Latypov <dlatypov@google.com> Signed-off-by: Ricardo Ribalda <ribalda@chromium.org> Acked-by: Brendan Higgins <brendanhiggins@google.com> Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>
2022-02-11 17:42:43 +01:00
thunderbolt: Add KUnit tests for credit allocation This adds a couple of KUnit tests for USB4 credit allocation. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2021-04-28 19:04:02 +03:00
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 <mika.westerberg@linux.intel.com>
2024-08-20 08:56:02 +03:00
thunderbolt: Add KUnit tests for credit allocation This adds a couple of KUnit tests for USB4 credit allocation. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2021-04-28 19:04:02 +03:00
thunderbolt: test: use NULL macros Replace the NULL checks with the more specific and idiomatic NULL macros. Acked-by: Mika Westerberg <mika.westerberg@linux.intel.com> Acked-by: Daniel Latypov <dlatypov@google.com> Signed-off-by: Ricardo Ribalda <ribalda@chromium.org> Acked-by: Brendan Higgins <brendanhiggins@google.com> Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>
2022-02-11 17:42:43 +01:00
thunderbolt: Add KUnit tests for credit allocation This adds a couple of KUnit tests for USB4 credit allocation. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2021-04-28 19:04:02 +03:00
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 <mika.westerberg@linux.intel.com>
2024-08-20 08:56:02 +03:00
thunderbolt: Add KUnit tests for credit allocation This adds a couple of KUnit tests for USB4 credit allocation. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2021-04-28 19:04:02 +03:00
thunderbolt: test: use NULL macros Replace the NULL checks with the more specific and idiomatic NULL macros. Acked-by: Mika Westerberg <mika.westerberg@linux.intel.com> Acked-by: Daniel Latypov <dlatypov@google.com> Signed-off-by: Ricardo Ribalda <ribalda@chromium.org> Acked-by: Brendan Higgins <brendanhiggins@google.com> Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>
2022-02-11 17:42:43 +01:00
thunderbolt: Add KUnit tests for credit allocation This adds a couple of KUnit tests for USB4 credit allocation. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2021-04-28 19:04:02 +03:00
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 <mika.westerberg@linux.intel.com>
2024-08-20 08:56:02 +03:00
thunderbolt: Add KUnit tests for credit allocation This adds a couple of KUnit tests for USB4 credit allocation. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2021-04-28 19:04:02 +03:00
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@intel.com> Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2022-05-09 23:49:04 +03:00
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 <mika.westerberg@linux.intel.com>
2024-08-20 08:56:02 +03:00
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@intel.com> Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2022-05-09 23:49:04 +03:00
thunderbolt: Add KUnit tests for credit allocation This adds a couple of KUnit tests for USB4 credit allocation. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2021-04-28 19:04:02 +03:00
thunderbolt: Make the DP tunnel activation callback mandatory tb_tunnel_alloc_dp() takes an optional callback which is run from dprx_work once the DPRX capabilities read has completed. Without that callback tb_dp_dprx_start() reads the capabilities synchronously and never queues the work. It however always takes a tunnel reference which is only dropped by dprx_work itself or by tb_dp_dprx_stop() when cancel_delayed_work() actually canceled that work. That reference is thus leaked for every tunnel without a callback. The only tunnels without one are those from tb_tunnel_discover_dp(), which are activated again when restoring from hibernation. Pass the callback to tb_tunnel_discover_dp() as well and drop the synchronous path such that the DPRX capabilities are always read from dprx_work. Hibernation restore then also no longer blocks for up to 12 seconds while waiting for that read to complete. Also fix up the KUnit tests. Fixes: d6d458d42e1e ("thunderbolt: Handle DisplayPort tunnel activation asynchronously") Cc: stable@vger.kernel.org Signed-off-by: Sven Peter <sven@kernel.org> Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2026-08-29 10:08:34 +02:00
thunderbolt: test: use NULL macros Replace the NULL checks with the more specific and idiomatic NULL macros. Acked-by: Mika Westerberg <mika.westerberg@linux.intel.com> Acked-by: Daniel Latypov <dlatypov@google.com> Signed-off-by: Ricardo Ribalda <ribalda@chromium.org> Acked-by: Brendan Higgins <brendanhiggins@google.com> Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>
2022-02-11 17:42:43 +01:00
thunderbolt: Add KUnit tests for credit allocation This adds a couple of KUnit tests for USB4 credit allocation. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2021-04-28 19:04:02 +03:00
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 <mika.westerberg@linux.intel.com>
2024-08-20 08:56:02 +03:00
thunderbolt: Add KUnit tests for credit allocation This adds a couple of KUnit tests for USB4 credit allocation. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2021-04-28 19:04:02 +03:00
thunderbolt: test: use NULL macros Replace the NULL checks with the more specific and idiomatic NULL macros. Acked-by: Mika Westerberg <mika.westerberg@linux.intel.com> Acked-by: Daniel Latypov <dlatypov@google.com> Signed-off-by: Ricardo Ribalda <ribalda@chromium.org> Acked-by: Brendan Higgins <brendanhiggins@google.com> Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>
2022-02-11 17:42:43 +01:00
thunderbolt: Add KUnit tests for credit allocation This adds a couple of KUnit tests for USB4 credit allocation. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2021-04-28 19:04:02 +03:00
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 <mika.westerberg@linux.intel.com>
2024-08-20 08:56:02 +03:00
thunderbolt: Add KUnit tests for credit allocation This adds a couple of KUnit tests for USB4 credit allocation. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2021-04-28 19:04:02 +03:00
thunderbolt: test: use NULL macros Replace the NULL checks with the more specific and idiomatic NULL macros. Acked-by: Mika Westerberg <mika.westerberg@linux.intel.com> Acked-by: Daniel Latypov <dlatypov@google.com> Signed-off-by: Ricardo Ribalda <ribalda@chromium.org> Acked-by: Brendan Higgins <brendanhiggins@google.com> Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>
2022-02-11 17:42:43 +01:00
thunderbolt: Add KUnit tests for credit allocation This adds a couple of KUnit tests for USB4 credit allocation. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2021-04-28 19:04:02 +03:00
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 <mika.westerberg@linux.intel.com>
2024-08-20 08:56:02 +03:00
thunderbolt: Add KUnit tests for credit allocation This adds a couple of KUnit tests for USB4 credit allocation. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2021-04-28 19:04:02 +03:00
thunderbolt: test: use NULL macros Replace the NULL checks with the more specific and idiomatic NULL macros. Acked-by: Mika Westerberg <mika.westerberg@linux.intel.com> Acked-by: Daniel Latypov <dlatypov@google.com> Signed-off-by: Ricardo Ribalda <ribalda@chromium.org> Acked-by: Brendan Higgins <brendanhiggins@google.com> Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>
2022-02-11 17:42:43 +01:00
thunderbolt: Add KUnit tests for credit allocation This adds a couple of KUnit tests for USB4 credit allocation. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2021-04-28 19:04:02 +03:00
thunderbolt: test: use NULL macros Replace the NULL checks with the more specific and idiomatic NULL macros. Acked-by: Mika Westerberg <mika.westerberg@linux.intel.com> Acked-by: Daniel Latypov <dlatypov@google.com> Signed-off-by: Ricardo Ribalda <ribalda@chromium.org> Acked-by: Brendan Higgins <brendanhiggins@google.com> Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>
2022-02-11 17:42:43 +01:00
thunderbolt: Add KUnit tests for credit allocation This adds a couple of KUnit tests for USB4 credit allocation. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2021-04-28 19:04:02 +03:00
thunderbolt: test: use NULL macros Replace the NULL checks with the more specific and idiomatic NULL macros. Acked-by: Mika Westerberg <mika.westerberg@linux.intel.com> Acked-by: Daniel Latypov <dlatypov@google.com> Signed-off-by: Ricardo Ribalda <ribalda@chromium.org> Acked-by: Brendan Higgins <brendanhiggins@google.com> Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>
2022-02-11 17:42:43 +01:00
thunderbolt: Add KUnit tests for credit allocation This adds a couple of KUnit tests for USB4 credit allocation. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2021-04-28 19:04:02 +03:00
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 <mika.westerberg@linux.intel.com>
2024-08-20 08:56:02 +03:00
thunderbolt: Add KUnit tests for credit allocation This adds a couple of KUnit tests for USB4 credit allocation. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2021-04-28 19:04:02 +03:00
thunderbolt: test: use NULL macros Replace the NULL checks with the more specific and idiomatic NULL macros. Acked-by: Mika Westerberg <mika.westerberg@linux.intel.com> Acked-by: Daniel Latypov <dlatypov@google.com> Signed-off-by: Ricardo Ribalda <ribalda@chromium.org> Acked-by: Brendan Higgins <brendanhiggins@google.com> Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>
2022-02-11 17:42:43 +01:00
thunderbolt: Add KUnit tests for credit allocation This adds a couple of KUnit tests for USB4 credit allocation. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2021-04-28 19:04:02 +03:00
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 <mika.westerberg@linux.intel.com>
2024-08-20 08:56:02 +03:00
thunderbolt: Add KUnit tests for credit allocation This adds a couple of KUnit tests for USB4 credit allocation. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2021-04-28 19:04:02 +03:00
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 <torvalds@linux-foundation.org>
2021-09-06 12:27:03 -07:00
thunderbolt: Add KUnit tests for credit allocation This adds a couple of KUnit tests for USB4 credit allocation. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2021-04-28 19:04:02 +03:00
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 <torvalds@linux-foundation.org>
2021-09-06 12:27:03 -07:00
thunderbolt: Add KUnit tests for credit allocation This adds a couple of KUnit tests for USB4 credit allocation. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2021-04-28 19:04:02 +03:00
thunderbolt: test: use NULL macros Replace the NULL checks with the more specific and idiomatic NULL macros. Acked-by: Mika Westerberg <mika.westerberg@linux.intel.com> Acked-by: Daniel Latypov <dlatypov@google.com> Signed-off-by: Ricardo Ribalda <ribalda@chromium.org> Acked-by: Brendan Higgins <brendanhiggins@google.com> Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>
2022-02-11 17:42:43 +01:00
thunderbolt: Add KUnit tests for credit allocation This adds a couple of KUnit tests for USB4 credit allocation. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2021-04-28 19:04:02 +03:00
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 <torvalds@linux-foundation.org>
2021-09-06 12:27:03 -07:00
thunderbolt: Add KUnit tests for credit allocation This adds a couple of KUnit tests for USB4 credit allocation. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2021-04-28 19:04:02 +03:00
thunderbolt: Make the DP tunnel activation callback mandatory tb_tunnel_alloc_dp() takes an optional callback which is run from dprx_work once the DPRX capabilities read has completed. Without that callback tb_dp_dprx_start() reads the capabilities synchronously and never queues the work. It however always takes a tunnel reference which is only dropped by dprx_work itself or by tb_dp_dprx_stop() when cancel_delayed_work() actually canceled that work. That reference is thus leaked for every tunnel without a callback. The only tunnels without one are those from tb_tunnel_discover_dp(), which are activated again when restoring from hibernation. Pass the callback to tb_tunnel_discover_dp() as well and drop the synchronous path such that the DPRX capabilities are always read from dprx_work. Hibernation restore then also no longer blocks for up to 12 seconds while waiting for that read to complete. Also fix up the KUnit tests. Fixes: d6d458d42e1e ("thunderbolt: Handle DisplayPort tunnel activation asynchronously") Cc: stable@vger.kernel.org Signed-off-by: Sven Peter <sven@kernel.org> Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2026-08-29 10:08:34 +02:00
thunderbolt: test: use NULL macros Replace the NULL checks with the more specific and idiomatic NULL macros. Acked-by: Mika Westerberg <mika.westerberg@linux.intel.com> Acked-by: Daniel Latypov <dlatypov@google.com> Signed-off-by: Ricardo Ribalda <ribalda@chromium.org> Acked-by: Brendan Higgins <brendanhiggins@google.com> Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>
2022-02-11 17:42:43 +01:00
thunderbolt: Add KUnit tests for credit allocation This adds a couple of KUnit tests for USB4 credit allocation. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2021-04-28 19:04:02 +03:00
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 <torvalds@linux-foundation.org>
2021-09-06 12:27:03 -07:00
thunderbolt: Add KUnit tests for credit allocation This adds a couple of KUnit tests for USB4 credit allocation. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2021-04-28 19:04:02 +03:00
thunderbolt: Make the DP tunnel activation callback mandatory tb_tunnel_alloc_dp() takes an optional callback which is run from dprx_work once the DPRX capabilities read has completed. Without that callback tb_dp_dprx_start() reads the capabilities synchronously and never queues the work. It however always takes a tunnel reference which is only dropped by dprx_work itself or by tb_dp_dprx_stop() when cancel_delayed_work() actually canceled that work. That reference is thus leaked for every tunnel without a callback. The only tunnels without one are those from tb_tunnel_discover_dp(), which are activated again when restoring from hibernation. Pass the callback to tb_tunnel_discover_dp() as well and drop the synchronous path such that the DPRX capabilities are always read from dprx_work. Hibernation restore then also no longer blocks for up to 12 seconds while waiting for that read to complete. Also fix up the KUnit tests. Fixes: d6d458d42e1e ("thunderbolt: Handle DisplayPort tunnel activation asynchronously") Cc: stable@vger.kernel.org Signed-off-by: Sven Peter <sven@kernel.org> Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2026-08-29 10:08:34 +02:00
thunderbolt: test: use NULL macros Replace the NULL checks with the more specific and idiomatic NULL macros. Acked-by: Mika Westerberg <mika.westerberg@linux.intel.com> Acked-by: Daniel Latypov <dlatypov@google.com> Signed-off-by: Ricardo Ribalda <ribalda@chromium.org> Acked-by: Brendan Higgins <brendanhiggins@google.com> Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>
2022-02-11 17:42:43 +01:00
thunderbolt: Add KUnit tests for credit allocation This adds a couple of KUnit tests for USB4 credit allocation. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2021-04-28 19:04:02 +03:00
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 <torvalds@linux-foundation.org>
2021-09-06 12:27:03 -07:00
thunderbolt: Add KUnit tests for credit allocation This adds a couple of KUnit tests for USB4 credit allocation. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2021-04-28 19:04:02 +03:00
thunderbolt: test: use NULL macros Replace the NULL checks with the more specific and idiomatic NULL macros. Acked-by: Mika Westerberg <mika.westerberg@linux.intel.com> Acked-by: Daniel Latypov <dlatypov@google.com> Signed-off-by: Ricardo Ribalda <ribalda@chromium.org> Acked-by: Brendan Higgins <brendanhiggins@google.com> Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>
2022-02-11 17:42:43 +01:00
thunderbolt: Add KUnit tests for credit allocation This adds a couple of KUnit tests for USB4 credit allocation. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2021-04-28 19:04:02 +03:00
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 <torvalds@linux-foundation.org>
2021-09-06 12:27:03 -07:00
thunderbolt: Add KUnit tests for credit allocation This adds a couple of KUnit tests for USB4 credit allocation. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2021-04-28 19:04:02 +03:00
thunderbolt: test: use NULL macros Replace the NULL checks with the more specific and idiomatic NULL macros. Acked-by: Mika Westerberg <mika.westerberg@linux.intel.com> Acked-by: Daniel Latypov <dlatypov@google.com> Signed-off-by: Ricardo Ribalda <ribalda@chromium.org> Acked-by: Brendan Higgins <brendanhiggins@google.com> Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>
2022-02-11 17:42:43 +01:00
thunderbolt: Add KUnit tests for credit allocation This adds a couple of KUnit tests for USB4 credit allocation. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2021-04-28 19:04:02 +03:00
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 <torvalds@linux-foundation.org>
2021-09-06 12:27:03 -07:00
thunderbolt: Add KUnit tests for credit allocation This adds a couple of KUnit tests for USB4 credit allocation. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2021-04-28 19:04:02 +03:00
thunderbolt: test: use NULL macros Replace the NULL checks with the more specific and idiomatic NULL macros. Acked-by: Mika Westerberg <mika.westerberg@linux.intel.com> Acked-by: Daniel Latypov <dlatypov@google.com> Signed-off-by: Ricardo Ribalda <ribalda@chromium.org> Acked-by: Brendan Higgins <brendanhiggins@google.com> Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>
2022-02-11 17:42:43 +01:00
thunderbolt: Add KUnit tests for credit allocation This adds a couple of KUnit tests for USB4 credit allocation. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2021-04-28 19:04:02 +03:00
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 <torvalds@linux-foundation.org>
2021-09-06 12:27:03 -07:00
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 <mika.westerberg@linux.intel.com>
2024-08-20 08:56:02 +03:00
thunderbolt: Add KUnit tests for credit allocation This adds a couple of KUnit tests for USB4 credit allocation. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2021-04-28 19:04:02 +03:00
thunderbolt: Add KUnit tests for XDomain properties This adds KUnit tests for parsing, formatting and copying of XDomain properties. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2020-05-04 17:00:38 +03:00
thunderbolt: test: use NULL macros Replace the NULL checks with the more specific and idiomatic NULL macros. Acked-by: Mika Westerberg <mika.westerberg@linux.intel.com> Acked-by: Daniel Latypov <dlatypov@google.com> Signed-off-by: Ricardo Ribalda <ribalda@chromium.org> Acked-by: Brendan Higgins <brendanhiggins@google.com> Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>
2022-02-11 17:42:43 +01:00
thunderbolt: Add KUnit tests for XDomain properties This adds KUnit tests for parsing, formatting and copying of XDomain properties. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2020-05-04 17:00:38 +03:00
thunderbolt: test: use NULL macros Replace the NULL checks with the more specific and idiomatic NULL macros. Acked-by: Mika Westerberg <mika.westerberg@linux.intel.com> Acked-by: Daniel Latypov <dlatypov@google.com> Signed-off-by: Ricardo Ribalda <ribalda@chromium.org> Acked-by: Brendan Higgins <brendanhiggins@google.com> Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>
2022-02-11 17:42:43 +01:00
thunderbolt: Add KUnit tests for XDomain properties This adds KUnit tests for parsing, formatting and copying of XDomain properties. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2020-05-04 17:00:38 +03:00
thunderbolt: test: use NULL macros Replace the NULL checks with the more specific and idiomatic NULL macros. Acked-by: Mika Westerberg <mika.westerberg@linux.intel.com> Acked-by: Daniel Latypov <dlatypov@google.com> Signed-off-by: Ricardo Ribalda <ribalda@chromium.org> Acked-by: Brendan Higgins <brendanhiggins@google.com> Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>
2022-02-11 17:42:43 +01:00
thunderbolt: Add KUnit tests for XDomain properties This adds KUnit tests for parsing, formatting and copying of XDomain properties. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2020-05-04 17:00:38 +03:00
thunderbolt: test: use NULL macros Replace the NULL checks with the more specific and idiomatic NULL macros. Acked-by: Mika Westerberg <mika.westerberg@linux.intel.com> Acked-by: Daniel Latypov <dlatypov@google.com> Signed-off-by: Ricardo Ribalda <ribalda@chromium.org> Acked-by: Brendan Higgins <brendanhiggins@google.com> Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>
2022-02-11 17:42:43 +01:00
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 <davidgow@google.com> Acked-by: Mika Westerberg <mika.westerberg@linux.intel.com> Reviewed-by: Brendan Higgins <brendanhiggins@google.com> Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>
2021-05-13 12:32:01 -07:00
thunderbolt: Add KUnit tests for XDomain properties This adds KUnit tests for parsing, formatting and copying of XDomain properties. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2020-05-04 17:00:38 +03:00
thunderbolt: test: use NULL macros Replace the NULL checks with the more specific and idiomatic NULL macros. Acked-by: Mika Westerberg <mika.westerberg@linux.intel.com> Acked-by: Daniel Latypov <dlatypov@google.com> Signed-off-by: Ricardo Ribalda <ribalda@chromium.org> Acked-by: Brendan Higgins <brendanhiggins@google.com> Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>
2022-02-11 17:42:43 +01:00
thunderbolt: Add KUnit tests for XDomain properties This adds KUnit tests for parsing, formatting and copying of XDomain properties. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2020-05-04 17:00:38 +03:00
thunderbolt: test: use NULL macros Replace the NULL checks with the more specific and idiomatic NULL macros. Acked-by: Mika Westerberg <mika.westerberg@linux.intel.com> Acked-by: Daniel Latypov <dlatypov@google.com> Signed-off-by: Ricardo Ribalda <ribalda@chromium.org> Acked-by: Brendan Higgins <brendanhiggins@google.com> Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>
2022-02-11 17:42:43 +01:00
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 <davidgow@google.com> Acked-by: Mika Westerberg <mika.westerberg@linux.intel.com> Reviewed-by: Brendan Higgins <brendanhiggins@google.com> Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>
2021-05-13 12:32:01 -07:00
thunderbolt: Add KUnit tests for XDomain properties This adds KUnit tests for parsing, formatting and copying of XDomain properties. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2020-05-04 17:00:38 +03:00
thunderbolt: test: use NULL macros Replace the NULL checks with the more specific and idiomatic NULL macros. Acked-by: Mika Westerberg <mika.westerberg@linux.intel.com> Acked-by: Daniel Latypov <dlatypov@google.com> Signed-off-by: Ricardo Ribalda <ribalda@chromium.org> Acked-by: Brendan Higgins <brendanhiggins@google.com> Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>
2022-02-11 17:42:43 +01:00
thunderbolt: Add KUnit tests for XDomain properties This adds KUnit tests for parsing, formatting and copying of XDomain properties. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2020-05-04 17:00:38 +03:00
thunderbolt: test: use NULL macros Replace the NULL checks with the more specific and idiomatic NULL macros. Acked-by: Mika Westerberg <mika.westerberg@linux.intel.com> Acked-by: Daniel Latypov <dlatypov@google.com> Signed-off-by: Ricardo Ribalda <ribalda@chromium.org> Acked-by: Brendan Higgins <brendanhiggins@google.com> Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>
2022-02-11 17:42:43 +01:00
thunderbolt: Add KUnit tests for XDomain properties This adds KUnit tests for parsing, formatting and copying of XDomain properties. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2020-05-04 17:00:38 +03:00
thunderbolt: test: use NULL macros Replace the NULL checks with the more specific and idiomatic NULL macros. Acked-by: Mika Westerberg <mika.westerberg@linux.intel.com> Acked-by: Daniel Latypov <dlatypov@google.com> Signed-off-by: Ricardo Ribalda <ribalda@chromium.org> Acked-by: Brendan Higgins <brendanhiggins@google.com> Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>
2022-02-11 17:42:43 +01:00
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 <davidgow@google.com> Acked-by: Mika Westerberg <mika.westerberg@linux.intel.com> Reviewed-by: Brendan Higgins <brendanhiggins@google.com> Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>
2021-05-13 12:32:01 -07:00
thunderbolt: Add KUnit tests for XDomain properties This adds KUnit tests for parsing, formatting and copying of XDomain properties. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2020-05-04 17:00:38 +03:00
thunderbolt: test: use NULL macros Replace the NULL checks with the more specific and idiomatic NULL macros. Acked-by: Mika Westerberg <mika.westerberg@linux.intel.com> Acked-by: Daniel Latypov <dlatypov@google.com> Signed-off-by: Ricardo Ribalda <ribalda@chromium.org> Acked-by: Brendan Higgins <brendanhiggins@google.com> Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>
2022-02-11 17:42:43 +01:00
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 <davidgow@google.com> Acked-by: Mika Westerberg <mika.westerberg@linux.intel.com> Reviewed-by: Brendan Higgins <brendanhiggins@google.com> Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>
2021-05-13 12:32:01 -07:00
thunderbolt: Add KUnit tests for XDomain properties This adds KUnit tests for parsing, formatting and copying of XDomain properties. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2020-05-04 17:00:38 +03:00
thunderbolt: test: use NULL macros Replace the NULL checks with the more specific and idiomatic NULL macros. Acked-by: Mika Westerberg <mika.westerberg@linux.intel.com> Acked-by: Daniel Latypov <dlatypov@google.com> Signed-off-by: Ricardo Ribalda <ribalda@chromium.org> Acked-by: Brendan Higgins <brendanhiggins@google.com> Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>
2022-02-11 17:42:43 +01:00
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 <davidgow@google.com> Acked-by: Mika Westerberg <mika.westerberg@linux.intel.com> Reviewed-by: Brendan Higgins <brendanhiggins@google.com> Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>
2021-05-13 12:32:01 -07:00
thunderbolt: Add KUnit tests for XDomain properties This adds KUnit tests for parsing, formatting and copying of XDomain properties. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2020-05-04 17:00:38 +03:00
thunderbolt: test: use NULL macros Replace the NULL checks with the more specific and idiomatic NULL macros. Acked-by: Mika Westerberg <mika.westerberg@linux.intel.com> Acked-by: Daniel Latypov <dlatypov@google.com> Signed-off-by: Ricardo Ribalda <ribalda@chromium.org> Acked-by: Brendan Higgins <brendanhiggins@google.com> Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>
2022-02-11 17:42:43 +01:00
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 <davidgow@google.com> Acked-by: Mika Westerberg <mika.westerberg@linux.intel.com> Reviewed-by: Brendan Higgins <brendanhiggins@google.com> Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>
2021-05-13 12:32:01 -07:00
thunderbolt: Add KUnit tests for XDomain properties This adds KUnit tests for parsing, formatting and copying of XDomain properties. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2020-05-04 17:00:38 +03:00
thunderbolt: test: use NULL macros Replace the NULL checks with the more specific and idiomatic NULL macros. Acked-by: Mika Westerberg <mika.westerberg@linux.intel.com> Acked-by: Daniel Latypov <dlatypov@google.com> Signed-off-by: Ricardo Ribalda <ribalda@chromium.org> Acked-by: Brendan Higgins <brendanhiggins@google.com> Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>
2022-02-11 17:42:43 +01:00
thunderbolt: Add KUnit tests for XDomain properties This adds KUnit tests for parsing, formatting and copying of XDomain properties. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2020-05-04 17:00:38 +03:00
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 <davidgow@google.com> Acked-by: Mika Westerberg <mika.westerberg@linux.intel.com> Reviewed-by: Brendan Higgins <brendanhiggins@google.com> Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>
2021-05-13 12:32:01 -07:00
thunderbolt: Add KUnit tests for XDomain properties This adds KUnit tests for parsing, formatting and copying of XDomain properties. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2020-05-04 17:00:38 +03:00
thunderbolt: test: use NULL macros Replace the NULL checks with the more specific and idiomatic NULL macros. Acked-by: Mika Westerberg <mika.westerberg@linux.intel.com> Acked-by: Daniel Latypov <dlatypov@google.com> Signed-off-by: Ricardo Ribalda <ribalda@chromium.org> Acked-by: Brendan Higgins <brendanhiggins@google.com> Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>
2022-02-11 17:42:43 +01:00
thunderbolt: Add KUnit tests for XDomain properties This adds KUnit tests for parsing, formatting and copying of XDomain properties. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2020-05-04 17:00:38 +03:00
thunderbolt: test: use NULL macros Replace the NULL checks with the more specific and idiomatic NULL macros. Acked-by: Mika Westerberg <mika.westerberg@linux.intel.com> Acked-by: Daniel Latypov <dlatypov@google.com> Signed-off-by: Ricardo Ribalda <ribalda@chromium.org> Acked-by: Brendan Higgins <brendanhiggins@google.com> Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>
2022-02-11 17:42:43 +01:00
thunderbolt: Add KUnit tests for XDomain properties This adds KUnit tests for parsing, formatting and copying of XDomain properties. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2020-05-04 17:00:38 +03:00
thunderbolt: test: use NULL macros Replace the NULL checks with the more specific and idiomatic NULL macros. Acked-by: Mika Westerberg <mika.westerberg@linux.intel.com> Acked-by: Daniel Latypov <dlatypov@google.com> Signed-off-by: Ricardo Ribalda <ribalda@chromium.org> Acked-by: Brendan Higgins <brendanhiggins@google.com> Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>
2022-02-11 17:42:43 +01:00
thunderbolt: Add KUnit tests for XDomain properties This adds KUnit tests for parsing, formatting and copying of XDomain properties. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2020-05-04 17:00:38 +03:00
thunderbolt: test: use NULL macros Replace the NULL checks with the more specific and idiomatic NULL macros. Acked-by: Mika Westerberg <mika.westerberg@linux.intel.com> Acked-by: Daniel Latypov <dlatypov@google.com> Signed-off-by: Ricardo Ribalda <ribalda@chromium.org> Acked-by: Brendan Higgins <brendanhiggins@google.com> Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>
2022-02-11 17:42:43 +01:00
thunderbolt: Add KUnit tests for XDomain properties This adds KUnit tests for parsing, formatting and copying of XDomain properties. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2020-05-04 17:00:38 +03:00
thunderbolt: test: use NULL macros Replace the NULL checks with the more specific and idiomatic NULL macros. Acked-by: Mika Westerberg <mika.westerberg@linux.intel.com> Acked-by: Daniel Latypov <dlatypov@google.com> Signed-off-by: Ricardo Ribalda <ribalda@chromium.org> Acked-by: Brendan Higgins <brendanhiggins@google.com> Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>
2022-02-11 17:42:43 +01:00
thunderbolt: Add KUnit tests for XDomain properties This adds KUnit tests for parsing, formatting and copying of XDomain properties. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2020-05-04 17:00:38 +03:00
thunderbolt: test: use NULL macros Replace the NULL checks with the more specific and idiomatic NULL macros. Acked-by: Mika Westerberg <mika.westerberg@linux.intel.com> Acked-by: Daniel Latypov <dlatypov@google.com> Signed-off-by: Ricardo Ribalda <ribalda@chromium.org> Acked-by: Brendan Higgins <brendanhiggins@google.com> Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>
2022-02-11 17:42:43 +01:00
thunderbolt: Add KUnit tests for XDomain properties This adds KUnit tests for parsing, formatting and copying of XDomain properties. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2020-05-04 17:00:38 +03:00
thunderbolt: test: use NULL macros Replace the NULL checks with the more specific and idiomatic NULL macros. Acked-by: Mika Westerberg <mika.westerberg@linux.intel.com> Acked-by: Daniel Latypov <dlatypov@google.com> Signed-off-by: Ricardo Ribalda <ribalda@chromium.org> Acked-by: Brendan Higgins <brendanhiggins@google.com> Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>
2022-02-11 17:42:43 +01:00
thunderbolt: Add KUnit tests for XDomain properties This adds KUnit tests for parsing, formatting and copying of XDomain properties. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2020-05-04 17:00:38 +03:00
thunderbolt: test: use NULL macros Replace the NULL checks with the more specific and idiomatic NULL macros. Acked-by: Mika Westerberg <mika.westerberg@linux.intel.com> Acked-by: Daniel Latypov <dlatypov@google.com> Signed-off-by: Ricardo Ribalda <ribalda@chromium.org> Acked-by: Brendan Higgins <brendanhiggins@google.com> Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>
2022-02-11 17:42:43 +01:00
thunderbolt: Add KUnit tests for XDomain properties This adds KUnit tests for parsing, formatting and copying of XDomain properties. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2020-05-04 17:00:38 +03:00
thunderbolt: test: use NULL macros Replace the NULL checks with the more specific and idiomatic NULL macros. Acked-by: Mika Westerberg <mika.westerberg@linux.intel.com> Acked-by: Daniel Latypov <dlatypov@google.com> Signed-off-by: Ricardo Ribalda <ribalda@chromium.org> Acked-by: Brendan Higgins <brendanhiggins@google.com> Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>
2022-02-11 17:42:43 +01:00
thunderbolt: Add KUnit tests for XDomain properties This adds KUnit tests for parsing, formatting and copying of XDomain properties. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2020-05-04 17:00:38 +03:00
thunderbolt: test: use NULL macros Replace the NULL checks with the more specific and idiomatic NULL macros. Acked-by: Mika Westerberg <mika.westerberg@linux.intel.com> Acked-by: Daniel Latypov <dlatypov@google.com> Signed-off-by: Ricardo Ribalda <ribalda@chromium.org> Acked-by: Brendan Higgins <brendanhiggins@google.com> Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>
2022-02-11 17:42:43 +01:00
thunderbolt: Add KUnit tests for XDomain properties This adds KUnit tests for parsing, formatting and copying of XDomain properties. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2020-05-04 17:00:38 +03:00
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 <davidgow@google.com> Acked-by: Mika Westerberg <mika.westerberg@linux.intel.com> Reviewed-by: Brendan Higgins <brendanhiggins@google.com> Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>
2021-05-13 12:32:01 -07:00
thunderbolt: Add KUnit tests for XDomain properties This adds KUnit tests for parsing, formatting and copying of XDomain properties. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2020-05-04 17:00:38 +03:00
thunderbolt: test: use NULL macros Replace the NULL checks with the more specific and idiomatic NULL macros. Acked-by: Mika Westerberg <mika.westerberg@linux.intel.com> Acked-by: Daniel Latypov <dlatypov@google.com> Signed-off-by: Ricardo Ribalda <ribalda@chromium.org> Acked-by: Brendan Higgins <brendanhiggins@google.com> Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>
2022-02-11 17:42:43 +01:00
thunderbolt: Add KUnit tests for XDomain properties This adds KUnit tests for parsing, formatting and copying of XDomain properties. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2020-05-04 17:00:38 +03:00
thunderbolt: test: add KUnit regression tests for XDomain property parser 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 <michael.bommarito@gmail.com> Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2026-05-10 19:16:59 -04:00
thunderbolt: test: Add KUnit tests for property parser bounds checks 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 <michael.bommarito@gmail.com> Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2026-05-25 05:28:30 -04:00
thunderbolt: Add KUnit test for tb_property_merge_dir() This makes sure it keeps working if we ever need to change it. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2025-09-23 12:46:11 +03:00
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 <mika.westerberg@linux.intel.com>
2020-04-29 16:38:39 +03:00
thunderbolt: test: add KUnit regression tests for XDomain property parser 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 <michael.bommarito@gmail.com> Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2026-05-10 19:16:59 -04:00
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 <mika.westerberg@linux.intel.com>
2020-04-29 16:38:39 +03:00
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 <mika.westerberg@linux.intel.com>
2020-05-04 17:10:40 +03:00
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 <mika.westerberg@linux.intel.com>
2022-02-14 14:09:50 +02:00
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 <mika.westerberg@linux.intel.com>
2020-05-04 17:10:40 +03:00
thunderbolt: Add KUnit tests for DMA tunnels Add a couple of tests to check DMA tunneling functionality. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2021-01-08 16:32:19 +02:00
thunderbolt: Add KUnit tests for credit allocation This adds a couple of KUnit tests for USB4 credit allocation. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2021-04-28 19:04:02 +03:00
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@intel.com> Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2022-05-09 23:49:04 +03:00
thunderbolt: Add KUnit tests for credit allocation This adds a couple of KUnit tests for USB4 credit allocation. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2021-04-28 19:04:02 +03:00
thunderbolt: Add KUnit tests for XDomain properties This adds KUnit tests for parsing, formatting and copying of XDomain properties. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2020-05-04 17:00:38 +03:00
thunderbolt: test: Add KUnit tests for property parser bounds checks 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 <michael.bommarito@gmail.com> Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2026-05-25 05:28:30 -04:00
thunderbolt: Add KUnit test for tb_property_merge_dir() This makes sure it keeps working if we ever need to change it. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2025-09-23 12:46:11 +03:00
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 <mika.westerberg@linux.intel.com>
2020-04-29 16:38:39 +03:00
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 <mika.westerberg@linux.intel.com>
2020-08-24 12:46:52 +03:00
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 <mika.westerberg@linux.intel.com> Acked-by: Daniel Latypov <dlatypov@google.com> Acked-by: Brendan Higgins <brendanhiggins@google.com> Signed-off-by: David Gow <davidgow@google.com> Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>
2022-07-09 11:19:59 +08:00