<feed xmlns='http://www.w3.org/2005/Atom'>
<title>kernel/linux.git/drivers/thunderbolt/domain.c, branch v6.6.131</title>
<subtitle>Linux kernel stable tree (mirror)</subtitle>
<id>https://git.radix-linux.su/kernel/linux.git/atom?h=v6.6.131</id>
<link rel='self' href='https://git.radix-linux.su/kernel/linux.git/atom?h=v6.6.131'/>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/'/>
<updated>2025-08-28T14:28:31+00:00</updated>
<entry>
<title>thunderbolt: Fix copy+paste error in match_service_id()</title>
<updated>2025-08-28T14:28:31+00:00</updated>
<author>
<name>Eric Biggers</name>
<email>ebiggers@kernel.org</email>
</author>
<published>2025-07-21T05:01:36+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=729ac69a3e81038b959df1c22a949407ab2fadde'/>
<id>urn:sha1:729ac69a3e81038b959df1c22a949407ab2fadde</id>
<content type='text'>
commit 5cc1f66cb23cccc704e3def27ad31ed479e934a5 upstream.

The second instance of TBSVC_MATCH_PROTOCOL_VERSION seems to have been
intended to be TBSVC_MATCH_PROTOCOL_REVISION.

Fixes: d1ff70241a27 ("thunderbolt: Add support for XDomain discovery protocol")
Cc: stable &lt;stable@kernel.org&gt;
Signed-off-by: Eric Biggers &lt;ebiggers@kernel.org&gt;
Link: https://lore.kernel.org/r/20250721050136.30004-1-ebiggers@kernel.org
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>thunderbolt: Reset topology created by the boot firmware</title>
<updated>2024-04-27T15:11:35+00:00</updated>
<author>
<name>Sanath S</name>
<email>Sanath.S@amd.com</email>
</author>
<published>2024-01-13T09:52:48+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=3c1d704d9266741fc5a9a0a287a5c6b72ddbea55'/>
<id>urn:sha1:3c1d704d9266741fc5a9a0a287a5c6b72ddbea55</id>
<content type='text'>
commit 59a54c5f3dbde00b8ad30aef27fe35b1fe07bf5c upstream.

Boot firmware (typically BIOS) might have created tunnels of its own.
The tunnel configuration that it does might be sub-optimal. For instance
it may only support HBR2 monitors so the DisplayPort tunnels it created
may limit Linux graphics drivers. In addition there is an issue on some
AMD based systems where the BIOS does not allocate enough PCIe resources
for future topology extension. By resetting the USB4 topology the PCIe
links will be reset as well allowing Linux to re-allocate.

This aligns the behavior with Windows Connection Manager.

We already issued host router reset for USB4 v2 routers, now extend it
to USB4 v1 routers as well. For pre-USB4 (that's Apple systems) we leave
it as is and continue to discover the existing tunnels.

Suggested-by: Mario Limonciello &lt;mario.limonciello@amd.com&gt;
Signed-off-by: Sanath S &lt;Sanath.S@amd.com&gt;
Signed-off-by: Mika Westerberg &lt;mika.westerberg@linux.intel.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>thunderbolt: Convert to use sysfs_emit()/sysfs_emit_at() APIs</title>
<updated>2022-09-24T06:22:01+00:00</updated>
<author>
<name>Andy Shevchenko</name>
<email>andriy.shevchenko@linux.intel.com</email>
</author>
<published>2022-09-22T14:32:39+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=8283fb57e46246ae998c6961c89a76ef7f14c6d9'/>
<id>urn:sha1:8283fb57e46246ae998c6961c89a76ef7f14c6d9</id>
<content type='text'>
Follow the advice of the Documentation/filesystems/sysfs.rst and show()
should only use sysfs_emit() or sysfs_emit_at() when formatting the value
to be returned to user space.

While at it, use Elvis operator in some cases.

Signed-off-by: Andy Shevchenko &lt;andriy.shevchenko@linux.intel.com&gt;
Signed-off-by: Mika Westerberg &lt;mika.westerberg@linux.intel.com&gt;
</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.radix-linux.su/kernel/linux.git/commit/?id=635dcd16844b08adcc1aa7a934893e47260619e4'/>
<id>urn:sha1: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>
</entry>
<entry>
<title>thunderbolt: Make iommu_dma_protection more accurate</title>
<updated>2022-04-28T08:30:25+00:00</updated>
<author>
<name>Robin Murphy</name>
<email>robin.murphy@arm.com</email>
</author>
<published>2022-04-25T12:42:04+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=86eaf4a5b4312bea8676fb79399d9e08b53d8e71'/>
<id>urn:sha1:86eaf4a5b4312bea8676fb79399d9e08b53d8e71</id>
<content type='text'>
Between me trying to get rid of iommu_present() and Mario wanting to
support the AMD equivalent of DMAR_PLATFORM_OPT_IN, scrutiny has shown
that the iommu_dma_protection attribute is being far too optimistic.
Even if an IOMMU might be present for some PCI segment in the system,
that doesn't necessarily mean it provides translation for the device(s)
we care about. Furthermore, all that DMAR_PLATFORM_OPT_IN really does
is tell us that memory was protected before the kernel was loaded, and
prevent the user from disabling the intel-iommu driver entirely. While
that lets us assume kernel integrity, what matters for actual runtime
DMA protection is whether we trust individual devices, based on the
"external facing" property that we expect firmware to describe for
Thunderbolt ports.

It's proven challenging to determine the appropriate ports accurately
given the variety of possible topologies, so while still not getting a
perfect answer, by putting enough faith in firmware we can at least get
a good bit closer. If we can see that any device near a Thunderbolt NHI
has all the requisites for Kernel DMA Protection, chances are that it
*is* a relevant port, but moreover that implies that firmware is playing
the game overall, so we'll use that to assume that all Thunderbolt ports
should be correctly marked and thus will end up fully protected.

CC: Mario Limonciello &lt;mario.limonciello@amd.com&gt;
Reviewed-by: Christoph Hellwig &lt;hch@lst.de&gt;
Acked-by: Mika Westerberg &lt;mika.westerberg@linux.intel.com&gt;
Signed-off-by: Robin Murphy &lt;robin.murphy@arm.com&gt;
Link: https://lore.kernel.org/r/b153f208bc9eafab5105bad0358b77366509d2d4.1650878781.git.robin.murphy@arm.com
Signed-off-by: Joerg Roedel &lt;jroedel@suse.de&gt;
</content>
</entry>
<entry>
<title>bus: Make remove callback return void</title>
<updated>2021-07-21T09:53:42+00:00</updated>
<author>
<name>Uwe Kleine-König</name>
<email>u.kleine-koenig@pengutronix.de</email>
</author>
<published>2021-07-13T19:35:22+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=fc7a6209d5710618eb4f72a77cd81b8d694ecf89'/>
<id>urn:sha1:fc7a6209d5710618eb4f72a77cd81b8d694ecf89</id>
<content type='text'>
The driver core ignores the return value of this callback because there
is only little it can do when a device disappears.

This is the final bit of a long lasting cleanup quest where several
buses were converted to also return void from their remove callback.
Additionally some resource leaks were fixed that were caused by drivers
returning an error code in the expectation that the driver won't go
away.

With struct bus_type::remove returning void it's prevented that newly
implemented buses return an ignored error code and so don't anticipate
wrong expectations for driver authors.

Reviewed-by: Tom Rix &lt;trix@redhat.com&gt; (For fpga)
Reviewed-by: Mathieu Poirier &lt;mathieu.poirier@linaro.org&gt;
Reviewed-by: Cornelia Huck &lt;cohuck@redhat.com&gt; (For drivers/s390 and drivers/vfio)
Acked-by: Russell King (Oracle) &lt;rmk+kernel@armlinux.org.uk&gt; (For ARM, Amba and related parts)
Acked-by: Mark Brown &lt;broonie@kernel.org&gt;
Acked-by: Chen-Yu Tsai &lt;wens@csie.org&gt; (for sunxi-rsb)
Acked-by: Pali Rohár &lt;pali@kernel.org&gt;
Acked-by: Mauro Carvalho Chehab &lt;mchehab@kernel.org&gt; (for media)
Acked-by: Hans de Goede &lt;hdegoede@redhat.com&gt; (For drivers/platform)
Acked-by: Alexandre Belloni &lt;alexandre.belloni@bootlin.com&gt;
Acked-By: Vinod Koul &lt;vkoul@kernel.org&gt;
Acked-by: Juergen Gross &lt;jgross@suse.com&gt; (For xen)
Acked-by: Lee Jones &lt;lee.jones@linaro.org&gt; (For mfd)
Acked-by: Johannes Thumshirn &lt;jth@kernel.org&gt; (For mcb)
Acked-by: Johan Hovold &lt;johan@kernel.org&gt;
Acked-by: Srinivas Kandagatla &lt;srinivas.kandagatla@linaro.org&gt; (For slimbus)
Acked-by: Kirti Wankhede &lt;kwankhede@nvidia.com&gt; (For vfio)
Acked-by: Maximilian Luz &lt;luzmaximilian@gmail.com&gt;
Acked-by: Heikki Krogerus &lt;heikki.krogerus@linux.intel.com&gt; (For ulpi and typec)
Acked-by: Samuel Iglesias Gonsálvez &lt;siglesias@igalia.com&gt; (For ipack)
Acked-by: Geoff Levand &lt;geoff@infradead.org&gt; (For ps3)
Acked-by: Yehezkel Bernat &lt;YehezkelShB@gmail.com&gt; (For thunderbolt)
Acked-by: Alexander Shishkin &lt;alexander.shishkin@linux.intel.com&gt; (For intel_th)
Acked-by: Dominik Brodowski &lt;linux@dominikbrodowski.net&gt; (For pcmcia)
Acked-by: Rafael J. Wysocki &lt;rafael@kernel.org&gt; (For ACPI)
Acked-by: Bjorn Andersson &lt;bjorn.andersson@linaro.org&gt; (rpmsg and apr)
Acked-by: Srinivas Pandruvada &lt;srinivas.pandruvada@linux.intel.com&gt; (For intel-ish-hid)
Acked-by: Dan Williams &lt;dan.j.williams@intel.com&gt; (For CXL, DAX, and NVDIMM)
Acked-by: William Breathitt Gray &lt;vilhelm.gray@gmail.com&gt; (For isa)
Acked-by: Stefan Richter &lt;stefanr@s5r6.in-berlin.de&gt; (For firewire)
Acked-by: Benjamin Tissoires &lt;benjamin.tissoires@redhat.com&gt; (For hid)
Acked-by: Thorsten Scherer &lt;t.scherer@eckelmann.de&gt; (For siox)
Acked-by: Sven Van Asbroeck &lt;TheSven73@gmail.com&gt; (For anybuss)
Acked-by: Ulf Hansson &lt;ulf.hansson@linaro.org&gt; (For MMC)
Acked-by: Wolfram Sang &lt;wsa@kernel.org&gt; # for I2C
Acked-by: Sudeep Holla &lt;sudeep.holla@arm.com&gt;
Acked-by: Geert Uytterhoeven &lt;geert@linux-m68k.org&gt;
Acked-by: Dmitry Torokhov &lt;dmitry.torokhov@gmail.com&gt;
Acked-by: Finn Thain &lt;fthain@linux-m68k.org&gt;
Signed-off-by: Uwe Kleine-König &lt;u.kleine-koenig@pengutronix.de&gt;
Link: https://lore.kernel.org/r/20210713193522.1770306-6-u.kleine-koenig@pengutronix.de
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>thunderbolt: Add support for ACPI _DSM to power on/off retimers</title>
<updated>2021-06-01T07:53:31+00:00</updated>
<author>
<name>Rajmohan Mani</name>
<email>rajmohan.mani@intel.com</email>
</author>
<published>2021-04-01T15:20:17+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=ccc5cb8ad5d18ec0e008d1652711fa1c18e9366c'/>
<id>urn:sha1:ccc5cb8ad5d18ec0e008d1652711fa1c18e9366c</id>
<content type='text'>
Typically retimers can be accessed only when the USB4 link is up (e.g
there is a cable connected). However, sometimes it is useful to be able
to access retimers even if there is nothing connected to the USB4 port.
For instance we may still want to be able to upgrade the retimer NVM
firmware even if the user does not have any USB4 devices. This is
something that USB4 spec leaves to implementers.

In case of ACPI based systems, we can support this by providing a
special _DSM method under each USB4 port. This _DSM can be used to turn
on power to on-board retimers (and cycle it through different modes so
that the sideband becomes usable).

This patch adds support for this _DSM and makes the functionality
available to the rest of the driver through tb_acpi_power_[on|off]_retimers().

Signed-off-by: Rajmohan Mani &lt;rajmohan.mani@intel.com&gt;
Co-developed-by: Mika Westerberg &lt;mika.westerberg@linux.intel.com&gt;
Signed-off-by: Mika Westerberg &lt;mika.westerberg@linux.intel.com&gt;
Reviewed-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>thunderbolt: Unlock on error path in tb_domain_add()</title>
<updated>2021-03-23T14:09:34+00:00</updated>
<author>
<name>Dan Carpenter</name>
<email>dan.carpenter@oracle.com</email>
</author>
<published>2021-03-23T13:19:06+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=2e7a5b3e22368b65583d1b717e267de0a5906c32'/>
<id>urn:sha1:2e7a5b3e22368b65583d1b717e267de0a5906c32</id>
<content type='text'>
We accidentally deleted this unlock on the error path.  Undelete it.

Fixes: 7f0a34d7900b ("thunderbolt: Decrease control channel timeout for software connection manager")
Signed-off-by: Dan Carpenter &lt;dan.carpenter@oracle.com&gt;
Signed-off-by: Mika Westerberg &lt;mika.westerberg@linux.intel.com&gt;
</content>
</entry>
<entry>
<title>thunderbolt: Allow multiple DMA tunnels over a single XDomain connection</title>
<updated>2021-03-18T15:25:31+00:00</updated>
<author>
<name>Mika Westerberg</name>
<email>mika.westerberg@linux.intel.com</email>
</author>
<published>2021-01-08T14:25:39+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=180b0689425c6fb2b35e69a3316ee38371a782df'/>
<id>urn:sha1:180b0689425c6fb2b35e69a3316ee38371a782df</id>
<content type='text'>
Currently we have had an artificial limitation of a single DMA tunnel
per XDomain connection. However, hardware wise there is no such limit
and software based connection manager can take advantage of all the DMA
rings available on the host to establish tunnels.

For this reason make the tb_xdomain_[enable|disable]_paths() to take the
DMA ring and HopID as parameter instead of storing them in the struct
tb_xdomain. We also add API functions to allocate input and output
HopIDs of the XDomain connection that the service drivers can use
instead of hard-coding.

Also convert the two existing service drivers over to this API.

Signed-off-by: Mika Westerberg &lt;mika.westerberg@linux.intel.com&gt;
</content>
</entry>
<entry>
<title>thunderbolt: Decrease control channel timeout for software connection manager</title>
<updated>2021-03-18T15:25:30+00:00</updated>
<author>
<name>Mika Westerberg</name>
<email>mika.westerberg@linux.intel.com</email>
</author>
<published>2020-12-29T11:44:57+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=7f0a34d7900b8403d3068755856b86bcc790c5a3'/>
<id>urn:sha1:7f0a34d7900b8403d3068755856b86bcc790c5a3</id>
<content type='text'>
When the firmware connection manager is not proxying between the
software and the hardware we can decrease the timeout for control
packets significantly. The USB4 spec recommends 10 ms +- 1 ms but we use
slightly larger value (100 ms) which is recommendation from Intel
Thunderbolt firmware folks. When firmware connection manager is running
then we keep using the existing 5000 ms.

To implement this we move the control channel allocation to
tb_domain_alloc(), and pass the timeout from that function to the
tb_ctl_alloc(). Then make both connection manager implementations pass
the timeout when they alloc the domain structure.

While there update kernel-doc of struct tb_ctl to match the reality.

Signed-off-by: Mika Westerberg &lt;mika.westerberg@linux.intel.com&gt;
</content>
</entry>
</feed>
