<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux-toradex.git/drivers/thunderbolt/Kconfig, branch master</title>
<subtitle>Linux kernel for Apalis and Colibri modules</subtitle>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/'/>
<entry>
<title>thunderbolt: Add support for USB4STREAM</title>
<updated>2026-05-19T12:20:18+00:00</updated>
<author>
<name>Mika Westerberg</name>
<email>mika.westerberg@linux.intel.com</email>
</author>
<published>2025-08-12T10:56:30+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=6db21d817b43f8ce5654ccc7aff80d40e4dba4ac'/>
<id>6db21d817b43f8ce5654ccc7aff80d40e4dba4ac</id>
<content type='text'>
Introduce USB4STREAM protocol and Linux implementation. This allows two
(or more) hosts to transfer data directly over Thunderbolt/USB4 cable
through a character device without need to go through the network stack.

Any application that supports read(2) and write(2) in some form should
be able to use the device without changes. The data is sent out to the
other side over a tunnel inside Thunderbolt/USB4 fabric. The character
device is called /dev/tbstreamX where X is the minor number starting
from 0.

All stream devices need to be configured first. This is done through
ConfigFS interface. There can be multiple streams at the same time (this
depends on number of DMA rings and available HopIDs) and a single stream
supports traffic in both directions. For example there could be an
application that uses one stream as control channel and another one as
bi-directional data channel.

A real use-case for this is to take a backup as a part of recovery
initramfs tooling (no need to setup networking or have ssh or similar
tooling as part of the initramfs). Say we want to backup the disk of
host1 to host2. First Thunderbolt/USB4 cable is connected between the
hosts (there can be devices in the middle too) then the receiving side
configures the stream:

  host2 # mkdir /sys/kernel/config/thunderbolt/stream/0-1.0
  host2 # mkdir /sys/kernel/config/thunderbolt/stream/0-1.0/backup
  host2 # echo -1 &gt; /sys/kernel/config/thunderbolt/stream/0-1.0/backup/in_hopid
  host2 # echo -1 &gt; /sys/kernel/config/thunderbolt/stream/0-1.0/backup/out_hopid

We use automatic HopID allocation (writing -1 to HopIDs) for simplicity.
From this point forward the /dev/tbstream0 can be used pretty much as
regular file:

  host2 # dd if=/dev/tbstream0 of=/tmp/host1.nvme0n1.backup-$(date +%F) bs=256k

The host that is being backed up then configures the stream accordingly:

  host1 # mkdir /sys/kernel/config/thunderbolt/stream/0-503.0
  host1 # mkdir /sys/kernel/config/thunderbolt/stream/0-503.0/backup

Here we take advantage of the fact that host2 also announces the active
streams through XDomain properties so the name "backup" gives us the
HopIDs. It is also possible to configure them manually in the same way
we did for host2.

Then it is just a matter of copying the data over:

  host1 # dd if=/dev/nvme0n1 of=/dev/tbstream0 bs=256k

Similarly it is possible to transfer parts of the filesystem. For
example copy contents of mydir over to the host2:

  host2 # gunzip &lt; /dev/tbstream0 | tar xf -
  host1 # tar cf - mydir | gzip &gt; /dev/tbstream0

Other end of the spectrum use-case is "borrowing" laptop (host1) camera
to desktop (host2):

  host2 # gst-launch-1.0 filesrc location=/dev/tbstream0 ! jpegdec ! videoconvert ! \
                         autovideosink

  host1 # gst-launch-1.0 v4l2src device=/dev/video0 ! video/x-raw,width=1920,height=1080 ! \
                         jpegenc quality=90 ! filesink location=/dev/tbstream0

Once the streams are no longer needed they can be removed:

  host1 # cd /sys/kernel/config/thunderbolt/stream/
  host1 # rmdir -p 0-503.0/backup

  host2 # cd /sys/kernel/config/thunderbolt/stream
  host2 # rmdir -p 0-1.0/backup

Co-developed-by: Alan Borzeszkowski &lt;alan.borzeszkowski@linux.intel.com&gt;
Signed-off-by: Alan Borzeszkowski &lt;alan.borzeszkowski@linux.intel.com&gt;
Signed-off-by: Mika Westerberg &lt;mika.westerberg@linux.intel.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Introduce USB4STREAM protocol and Linux implementation. This allows two
(or more) hosts to transfer data directly over Thunderbolt/USB4 cable
through a character device without need to go through the network stack.

Any application that supports read(2) and write(2) in some form should
be able to use the device without changes. The data is sent out to the
other side over a tunnel inside Thunderbolt/USB4 fabric. The character
device is called /dev/tbstreamX where X is the minor number starting
from 0.

All stream devices need to be configured first. This is done through
ConfigFS interface. There can be multiple streams at the same time (this
depends on number of DMA rings and available HopIDs) and a single stream
supports traffic in both directions. For example there could be an
application that uses one stream as control channel and another one as
bi-directional data channel.

A real use-case for this is to take a backup as a part of recovery
initramfs tooling (no need to setup networking or have ssh or similar
tooling as part of the initramfs). Say we want to backup the disk of
host1 to host2. First Thunderbolt/USB4 cable is connected between the
hosts (there can be devices in the middle too) then the receiving side
configures the stream:

  host2 # mkdir /sys/kernel/config/thunderbolt/stream/0-1.0
  host2 # mkdir /sys/kernel/config/thunderbolt/stream/0-1.0/backup
  host2 # echo -1 &gt; /sys/kernel/config/thunderbolt/stream/0-1.0/backup/in_hopid
  host2 # echo -1 &gt; /sys/kernel/config/thunderbolt/stream/0-1.0/backup/out_hopid

We use automatic HopID allocation (writing -1 to HopIDs) for simplicity.
From this point forward the /dev/tbstream0 can be used pretty much as
regular file:

  host2 # dd if=/dev/tbstream0 of=/tmp/host1.nvme0n1.backup-$(date +%F) bs=256k

The host that is being backed up then configures the stream accordingly:

  host1 # mkdir /sys/kernel/config/thunderbolt/stream/0-503.0
  host1 # mkdir /sys/kernel/config/thunderbolt/stream/0-503.0/backup

Here we take advantage of the fact that host2 also announces the active
streams through XDomain properties so the name "backup" gives us the
HopIDs. It is also possible to configure them manually in the same way
we did for host2.

Then it is just a matter of copying the data over:

  host1 # dd if=/dev/nvme0n1 of=/dev/tbstream0 bs=256k

Similarly it is possible to transfer parts of the filesystem. For
example copy contents of mydir over to the host2:

  host2 # gunzip &lt; /dev/tbstream0 | tar xf -
  host1 # tar cf - mydir | gzip &gt; /dev/tbstream0

Other end of the spectrum use-case is "borrowing" laptop (host1) camera
to desktop (host2):

  host2 # gst-launch-1.0 filesrc location=/dev/tbstream0 ! jpegdec ! videoconvert ! \
                         autovideosink

  host1 # gst-launch-1.0 v4l2src device=/dev/video0 ! video/x-raw,width=1920,height=1080 ! \
                         jpegenc quality=90 ! filesink location=/dev/tbstream0

Once the streams are no longer needed they can be removed:

  host1 # cd /sys/kernel/config/thunderbolt/stream/
  host1 # rmdir -p 0-503.0/backup

  host2 # cd /sys/kernel/config/thunderbolt/stream
  host2 # rmdir -p 0-1.0/backup

Co-developed-by: Alan Borzeszkowski &lt;alan.borzeszkowski@linux.intel.com&gt;
Signed-off-by: Alan Borzeszkowski &lt;alan.borzeszkowski@linux.intel.com&gt;
Signed-off-by: Mika Westerberg &lt;mika.westerberg@linux.intel.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>thunderbolt: Add support for ConfigFS</title>
<updated>2026-05-19T12:20:18+00:00</updated>
<author>
<name>Mika Westerberg</name>
<email>mika.westerberg@linux.intel.com</email>
</author>
<published>2025-08-12T10:53:49+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=cba57ed6f1e7529498cebbbe135c5132667fa923'/>
<id>cba57ed6f1e7529498cebbbe135c5132667fa923</id>
<content type='text'>
This adds ConfigFS support to USB4/Thunderbolt bus. By itself this just
creates the subsystem but it exposes functions that can be used to
register groups under it.

Signed-off-by: Mika Westerberg &lt;mika.westerberg@linux.intel.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
This adds ConfigFS support to USB4/Thunderbolt bus. By itself this just
creates the subsystem but it exposes functions that can be used to
register groups under it.

Signed-off-by: Mika Westerberg &lt;mika.westerberg@linux.intel.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>thunderbolt: Use HMAC-SHA256 library instead of crypto_shash</title>
<updated>2025-08-11T05:56:14+00:00</updated>
<author>
<name>Eric Biggers</name>
<email>ebiggers@kernel.org</email>
</author>
<published>2025-07-31T19:25:45+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=0eff12ce88e1e77c465cbaa22d450fd268cd9b74'/>
<id>0eff12ce88e1e77c465cbaa22d450fd268cd9b74</id>
<content type='text'>
Use the hmac_sha256_usingrawkey() library function instead of the
"hmac(sha256)" crypto_shash.  This is simpler and faster.

As a cleanup, change the input data parameters from "challenge,
sizeof(hmac)" to "challenge, sizeof(challenge)", so that the size is
being taken of the correct buffer.  This is not a functional change,
since it happens that sizeof(hmac) == sizeof(challenge).

Replace the selection of CRYPTO and CRYPTO_HASH with CRYPTO_LIB_SHA256
and CRYPTO_LIB_UTILS.  The latter is needed for crypto_memneq() which
was previously being pulled in via CRYPTO.

Signed-off-by: Eric Biggers &lt;ebiggers@kernel.org&gt;
Signed-off-by: Mika Westerberg &lt;mika.westerberg@linux.intel.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Use the hmac_sha256_usingrawkey() library function instead of the
"hmac(sha256)" crypto_shash.  This is simpler and faster.

As a cleanup, change the input data parameters from "challenge,
sizeof(hmac)" to "challenge, sizeof(challenge)", so that the size is
being taken of the correct buffer.  This is not a functional change,
since it happens that sizeof(hmac) == sizeof(challenge).

Replace the selection of CRYPTO and CRYPTO_HASH with CRYPTO_LIB_SHA256
and CRYPTO_LIB_UTILS.  The latter is needed for crypto_memneq() which
was previously being pulled in via CRYPTO.

Signed-off-by: Eric Biggers &lt;ebiggers@kernel.org&gt;
Signed-off-by: Mika Westerberg &lt;mika.westerberg@linux.intel.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>thunderbolt: Add receiver lane margining support for retimers</title>
<updated>2024-06-17T09:47:12+00:00</updated>
<author>
<name>Mika Westerberg</name>
<email>mika.westerberg@linux.intel.com</email>
</author>
<published>2023-03-21T09:40:49+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=ff6ab055e070d819f51196622e08f8941b6d2a4b'/>
<id>ff6ab055e070d819f51196622e08f8941b6d2a4b</id>
<content type='text'>
Retimers support lane margining as well so make this available through
debugfs in the same way as we do for the USB4 ports. When this is
enabled we also expose retimers on the other side of the cable because
typically margining is implemented only on direction towards the cable.
However, for the retimers on the other side of the cable we do not allow
NVM upgrade to avoid confusing the existing userspace (the same retimer
may now appear twice with different name) and is probably not a good
idea anyway.

Signed-off-by: Mika Westerberg &lt;mika.westerberg@linux.intel.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Retimers support lane margining as well so make this available through
debugfs in the same way as we do for the USB4 ports. When this is
enabled we also expose retimers on the other side of the cable because
typically margining is implemented only on direction towards the cable.
However, for the retimers on the other side of the cable we do not allow
NVM upgrade to avoid confusing the existing userspace (the same retimer
may now appear twice with different name) and is probably not a good
idea anyway.

Signed-off-by: Mika Westerberg &lt;mika.westerberg@linux.intel.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>thunderbolt: Mention Thunderbolt/USB4 debugging tools in Kconfig</title>
<updated>2024-06-17T09:46:55+00:00</updated>
<author>
<name>Mika Westerberg</name>
<email>mika.westerberg@linux.intel.com</email>
</author>
<published>2024-04-23T11:23:23+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=2b43506774186be99e1003cac14f3c8ab7067935'/>
<id>2b43506774186be99e1003cac14f3c8ab7067935</id>
<content type='text'>
This allows the interested parties to find the Thunderbolt/USB4
debugging tools (aka tbtools) easier in case they need to look at the
information under debugfs entries.

Signed-off-by: Mika Westerberg &lt;mika.westerberg@linux.intel.com&gt;
Suggested-by: Mario Limonciello &lt;mario.limonciello@amd.com&gt;
Reviewed-by: Mario Limonciello &lt;mario.limonciello@amd.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
This allows the interested parties to find the Thunderbolt/USB4
debugging tools (aka tbtools) easier in case they need to look at the
information under debugfs entries.

Signed-off-by: Mika Westerberg &lt;mika.westerberg@linux.intel.com&gt;
Suggested-by: Mario Limonciello &lt;mario.limonciello@amd.com&gt;
Reviewed-by: Mario Limonciello &lt;mario.limonciello@amd.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>Merge tag 'thunderbolt-for-v6.1-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/westeri/thunderbolt into usb-next</title>
<updated>2022-09-30T11:44:59+00:00</updated>
<author>
<name>Greg Kroah-Hartman</name>
<email>gregkh@linuxfoundation.org</email>
</author>
<published>2022-09-30T11:44:59+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=bffcd14facbdc25ba4da9993cc7811b55b50b6e8'/>
<id>bffcd14facbdc25ba4da9993cc7811b55b50b6e8</id>
<content type='text'>
Mika writes:
  "thunderbolt: Changes for v6.1 merge window

   This includes following Thunderbolt/USB4 changes for the v6.1 merge
   window:
     - Support for Intel Meteor Lake integrated Thunderbolt/USB4 controller
     - Support for ASMedia USB4 controller NVM firmware upgrade
     - Receiver lane margining support
     - Few fixes and cleanups.

   All these have been in linux-next with no reported issues."

* tag 'thunderbolt-for-v6.1-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/westeri/thunderbolt:
  thunderbolt: Explicitly enable lane adapter hotplug events at startup
  thunderbolt: Use dev_err_probe()
  thunderbolt: Convert to use sysfs_emit()/sysfs_emit_at() APIs
  thunderbolt: Fix spelling mistake "simultaneusly" -&gt; "simultaneously"
  thunderbolt: debugfs: Fix spelling mistakes in seq_puts text
  thunderbolt: Add support for ASMedia NVM image format
  thunderbolt: Move vendor specific NVM handling into nvm.c
  thunderbolt: Provide tb_retimer_nvm_read() analogous to tb_switch_nvm_read()
  thunderbolt: Rename and make nvm_read() available for other files
  thunderbolt: Extend NVM version fields to 32-bits
  thunderbolt: Allow NVM upgrade of USB4 host routers
  thunderbolt: Add support for receiver lane margining
  thunderbolt: Add helper to check if CL states are enabled on port
  thunderbolt: Pass CL state bitmask to tb_port_clx_supported()
  thunderbolt: Move port CL state functions into correct place in switch.c
  thunderbolt: Move tb_xdomain_parent() to tb.h
  thunderbolt: Add support for Intel Meteor Lake
  thunderbolt: Add comment where Thunderbolt 4 PCI IDs start
  thunderbolt: Add DP OUT resource when DP tunnel is discovered
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Mika writes:
  "thunderbolt: Changes for v6.1 merge window

   This includes following Thunderbolt/USB4 changes for the v6.1 merge
   window:
     - Support for Intel Meteor Lake integrated Thunderbolt/USB4 controller
     - Support for ASMedia USB4 controller NVM firmware upgrade
     - Receiver lane margining support
     - Few fixes and cleanups.

   All these have been in linux-next with no reported issues."

* tag 'thunderbolt-for-v6.1-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/westeri/thunderbolt:
  thunderbolt: Explicitly enable lane adapter hotplug events at startup
  thunderbolt: Use dev_err_probe()
  thunderbolt: Convert to use sysfs_emit()/sysfs_emit_at() APIs
  thunderbolt: Fix spelling mistake "simultaneusly" -&gt; "simultaneously"
  thunderbolt: debugfs: Fix spelling mistakes in seq_puts text
  thunderbolt: Add support for ASMedia NVM image format
  thunderbolt: Move vendor specific NVM handling into nvm.c
  thunderbolt: Provide tb_retimer_nvm_read() analogous to tb_switch_nvm_read()
  thunderbolt: Rename and make nvm_read() available for other files
  thunderbolt: Extend NVM version fields to 32-bits
  thunderbolt: Allow NVM upgrade of USB4 host routers
  thunderbolt: Add support for receiver lane margining
  thunderbolt: Add helper to check if CL states are enabled on port
  thunderbolt: Pass CL state bitmask to tb_port_clx_supported()
  thunderbolt: Move port CL state functions into correct place in switch.c
  thunderbolt: Move tb_xdomain_parent() to tb.h
  thunderbolt: Add support for Intel Meteor Lake
  thunderbolt: Add comment where Thunderbolt 4 PCI IDs start
  thunderbolt: Add DP OUT resource when DP tunnel is discovered
</pre>
</div>
</content>
</entry>
<entry>
<title>thunderbolt: Add support for receiver lane margining</title>
<updated>2022-09-05T06:02:16+00:00</updated>
<author>
<name>Mika Westerberg</name>
<email>mika.westerberg@linux.intel.com</email>
</author>
<published>2022-02-22T17:31:47+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=d0f1e0c2a6990922818d6616a48d3d92bb7ddac1'/>
<id>d0f1e0c2a6990922818d6616a48d3d92bb7ddac1</id>
<content type='text'>
USB4 spec defines standard set of registers to be used for receiver lane
margining. This is useful for I/O interface quality and electrical
robustness validation during manufacturing. Expose receiver lane
margining through new debugfs directory "margining" that is added under
each connected USB4 port. Users can then run the margining by writing to
the exposed attributes under that directory.

Signed-off-by: Mika Westerberg &lt;mika.westerberg@linux.intel.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
USB4 spec defines standard set of registers to be used for receiver lane
margining. This is useful for I/O interface quality and electrical
robustness validation during manufacturing. Expose receiver lane
margining through new debugfs directory "margining" that is added under
each connected USB4 port. Users can then run the margining by writing to
the exposed attributes under that directory.

Signed-off-by: Mika Westerberg &lt;mika.westerberg@linux.intel.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>kunit: fix Kconfig for build-in tests USB4 and Nitro Enclaves</title>
<updated>2022-09-01T19:00:48+00:00</updated>
<author>
<name>Nico Pache</name>
<email>npache@redhat.com</email>
</author>
<published>2022-08-10T23:40:56+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=793f55b2971e3a95d77ad08e9da2a3dc6c946cd7'/>
<id>793f55b2971e3a95d77ad08e9da2a3dc6c946cd7</id>
<content type='text'>
Both the USB4 and Nitro Enclaves KUNIT tests are now able to be compiled
if KUNIT is compiled as a module. This leads to issues if KUNIT is being
packaged separately from the core kernel and when KUNIT is run baremetal
without the required driver compiled into the kernel.

Fixes: 635dcd16844b ("thunderbolt: test: Use kunit_test_suite() macro")
Fixes: fe5be808fa6c ("nitro_enclaves: test: Use kunit_test_suite() macro")
Signed-off-by: Nico Pache &lt;npache@redhat.com&gt;
Reviewed-by: David Gow &lt;davidgow@google.com&gt;
Reviewed-by: Andra Paraschiv &lt;andraprs@amazon.com&gt;
Acked-by: Brendan Higgins &lt;brendanhiggins@google.com&gt;
Signed-off-by: Shuah Khan &lt;skhan@linuxfoundation.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Both the USB4 and Nitro Enclaves KUNIT tests are now able to be compiled
if KUNIT is compiled as a module. This leads to issues if KUNIT is being
packaged separately from the core kernel and when KUNIT is run baremetal
without the required driver compiled into the kernel.

Fixes: 635dcd16844b ("thunderbolt: test: Use kunit_test_suite() macro")
Fixes: fe5be808fa6c ("nitro_enclaves: test: Use kunit_test_suite() macro")
Signed-off-by: Nico Pache &lt;npache@redhat.com&gt;
Reviewed-by: David Gow &lt;davidgow@google.com&gt;
Reviewed-by: Andra Paraschiv &lt;andraprs@amazon.com&gt;
Acked-by: Brendan Higgins &lt;brendanhiggins@google.com&gt;
Signed-off-by: Shuah Khan &lt;skhan@linuxfoundation.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>thunderbolt: test: Use kunit_test_suite() macro</title>
<updated>2022-07-11T23:13:21+00:00</updated>
<author>
<name>David Gow</name>
<email>davidgow@google.com</email>
</author>
<published>2022-07-09T03:19:59+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=635dcd16844b08adcc1aa7a934893e47260619e4'/>
<id>635dcd16844b08adcc1aa7a934893e47260619e4</id>
<content type='text'>
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 &lt;mika.westerberg@linux.intel.com&gt;
Acked-by: Daniel Latypov &lt;dlatypov@google.com&gt;
Acked-by: Brendan Higgins &lt;brendanhiggins@google.com&gt;
Signed-off-by: David Gow &lt;davidgow@google.com&gt;
Signed-off-by: Shuah Khan &lt;skhan@linuxfoundation.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
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 &lt;mika.westerberg@linux.intel.com&gt;
Acked-by: Daniel Latypov &lt;dlatypov@google.com&gt;
Acked-by: Brendan Higgins &lt;brendanhiggins@google.com&gt;
Signed-off-by: David Gow &lt;davidgow@google.com&gt;
Signed-off-by: Shuah Khan &lt;skhan@linuxfoundation.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>thunderbolt: Add DMA traffic test driver</title>
<updated>2020-11-11T07:20:16+00:00</updated>
<author>
<name>Isaac Hazan</name>
<email>isaac.hazan@intel.com</email>
</author>
<published>2020-09-24T08:44:02+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=edc0f494ed966e39e5619be7cdaeb9873e1f4fe1'/>
<id>edc0f494ed966e39e5619be7cdaeb9873e1f4fe1</id>
<content type='text'>
This driver allows sending DMA traffic over XDomain connection.
Specifically over a loopback connection using either a Thunderbolt/USB4
cable that is connected back to the host router port, or a special
loopback dongle that has RX and TX lines crossed. This can be useful at
manufacturing floor to check whether Thunderbolt/USB4 ports are
functional.

The driver exposes debugfs directory under the XDomain service that can
be used to configure the driver, start the test and check the results.

If a loopback dongle is used the steps to send and receive 1000 packets
can be done like:

  # modprobe thunderbolt_dma_test
  # echo 1000 &gt; /sys/kernel/debug/thunderbolt/&lt;service_id&gt;/dma_test/packets_to_receive
  # echo 1000 &gt; /sys/kernel/debug/thunderbolt/&lt;service_id&gt;/dma_test/packets_to_send
  # echo 1 &gt; /sys/kernel/debug/thunderbolt/&lt;service_id&gt;/dma_test/test
  # cat /sys/kernel/debug/thunderbolt/&lt;service_id&gt;/dma_test/status

When a cable is connected back to host then there are two Thunderbolt
services, one is configured for receiving (does not matter which one):

  # modprobe thunderbolt_dma_test
  # echo 1000 &gt; /sys/kernel/debug/thunderbolt/&lt;service_a&gt;/dma_test/packets_to_receive
  # echo 1 &gt; /sys/kernel/debug/thunderbolt/&lt;service_a&gt;/dma_test/test

The other one for sending:

  # echo 1000 &gt; /sys/kernel/debug/thunderbolt/&lt;service_b&gt;/dma_test/packets_to_send
  # echo 1 &gt; /sys/kernel/debug/thunderbolt/&lt;service_b&gt;/dma_test/test

Results can be read from both services status attributes.

Signed-off-by: Isaac Hazan &lt;isaac.hazan@intel.com&gt;
Signed-off-by: Mika Westerberg &lt;mika.westerberg@linux.intel.com&gt;
Acked-by: Yehezkel Bernat &lt;YehezkelShB@gmail.com&gt;
Reviewed-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
This driver allows sending DMA traffic over XDomain connection.
Specifically over a loopback connection using either a Thunderbolt/USB4
cable that is connected back to the host router port, or a special
loopback dongle that has RX and TX lines crossed. This can be useful at
manufacturing floor to check whether Thunderbolt/USB4 ports are
functional.

The driver exposes debugfs directory under the XDomain service that can
be used to configure the driver, start the test and check the results.

If a loopback dongle is used the steps to send and receive 1000 packets
can be done like:

  # modprobe thunderbolt_dma_test
  # echo 1000 &gt; /sys/kernel/debug/thunderbolt/&lt;service_id&gt;/dma_test/packets_to_receive
  # echo 1000 &gt; /sys/kernel/debug/thunderbolt/&lt;service_id&gt;/dma_test/packets_to_send
  # echo 1 &gt; /sys/kernel/debug/thunderbolt/&lt;service_id&gt;/dma_test/test
  # cat /sys/kernel/debug/thunderbolt/&lt;service_id&gt;/dma_test/status

When a cable is connected back to host then there are two Thunderbolt
services, one is configured for receiving (does not matter which one):

  # modprobe thunderbolt_dma_test
  # echo 1000 &gt; /sys/kernel/debug/thunderbolt/&lt;service_a&gt;/dma_test/packets_to_receive
  # echo 1 &gt; /sys/kernel/debug/thunderbolt/&lt;service_a&gt;/dma_test/test

The other one for sending:

  # echo 1000 &gt; /sys/kernel/debug/thunderbolt/&lt;service_b&gt;/dma_test/packets_to_send
  # echo 1 &gt; /sys/kernel/debug/thunderbolt/&lt;service_b&gt;/dma_test/test

Results can be read from both services status attributes.

Signed-off-by: Isaac Hazan &lt;isaac.hazan@intel.com&gt;
Signed-off-by: Mika Westerberg &lt;mika.westerberg@linux.intel.com&gt;
Acked-by: Yehezkel Bernat &lt;YehezkelShB@gmail.com&gt;
Reviewed-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</pre>
</div>
</content>
</entry>
</feed>
