<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux-stable.git/drivers/thunderbolt, branch linux-6.5.y</title>
<subtitle>Linux kernel stable tree</subtitle>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/'/>
<entry>
<title>thunderbolt: Apply USB 3.x bandwidth quirk only in software connection manager</title>
<updated>2023-11-28T17:14:49+00:00</updated>
<author>
<name>Mika Westerberg</name>
<email>mika.westerberg@linux.intel.com</email>
</author>
<published>2023-08-25T07:10:35+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=5440e83534ee5e8c14898a7b5dd1bc97ca0f6c3b'/>
<id>5440e83534ee5e8c14898a7b5dd1bc97ca0f6c3b</id>
<content type='text'>
[ Upstream commit 0c35ac18256942e66d8dab6ca049185812e60c69 ]

This is not needed when firmware connection manager is run so limit this
to software connection manager.

Signed-off-by: Mika Westerberg &lt;mika.westerberg@linux.intel.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
[ Upstream commit 0c35ac18256942e66d8dab6ca049185812e60c69 ]

This is not needed when firmware connection manager is run so limit this
to software connection manager.

Signed-off-by: Mika Westerberg &lt;mika.westerberg@linux.intel.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>thunderbolt: Call tb_switch_put() once DisplayPort bandwidth request is finished</title>
<updated>2023-10-25T10:16:27+00:00</updated>
<author>
<name>Gil Fine</name>
<email>gil.fine@linux.intel.com</email>
</author>
<published>2023-08-10T20:18:25+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=12614cd08c2c11d3f380832c09214d56b75208f7'/>
<id>12614cd08c2c11d3f380832c09214d56b75208f7</id>
<content type='text'>
commit ec4405ed92036f5bb487b5c2f9a28f9e36a3e3d5 upstream.

When handling DisplayPort bandwidth request tb_switch_find_by_route() is
called and it returns a router structure with reference count increased.
In order to avoid resource leak call tb_switch_put() when finished.

Fixes: 6ce3563520be ("thunderbolt: Add support for DisplayPort bandwidth allocation mode")
Cc: stable@vger.kernel.org
Signed-off-by: Gil Fine &lt;gil.fine@linux.intel.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>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit ec4405ed92036f5bb487b5c2f9a28f9e36a3e3d5 upstream.

When handling DisplayPort bandwidth request tb_switch_find_by_route() is
called and it returns a router structure with reference count increased.
In order to avoid resource leak call tb_switch_put() when finished.

Fixes: 6ce3563520be ("thunderbolt: Add support for DisplayPort bandwidth allocation mode")
Cc: stable@vger.kernel.org
Signed-off-by: Gil Fine &lt;gil.fine@linux.intel.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;
</pre>
</div>
</content>
</entry>
<entry>
<title>thunderbolt: Restart XDomain discovery handshake after failure</title>
<updated>2023-10-19T21:11:05+00:00</updated>
<author>
<name>Mika Westerberg</name>
<email>mika.westerberg@linux.intel.com</email>
</author>
<published>2023-09-07T13:02:30+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=b6ab7f19a44f8d1c41638de9dc1979bd37488bd7'/>
<id>b6ab7f19a44f8d1c41638de9dc1979bd37488bd7</id>
<content type='text'>
commit 308092d080852f8997126e5b3507536162416f4a upstream.

Alex reported that after rebooting the other host the peer-to-peer link
does not come up anymore. The reason for this is that the host that was
not rebooted tries to send the UUID request only 10 times according to
the USB4 Inter-Domain spec and gives up if it does not get reply. Then
when the other side is actually ready it cannot get the link established
anymore. The USB4 Inter-Domain spec requires that the discovery protocol
is restarted in that case so implement this now.

Reported-by: Alex Balcanquall &lt;alex@alexbal.com&gt;
Fixes: 8e1de7042596 ("thunderbolt: Add support for XDomain lane bonding")
Cc: stable@vger.kernel.org
Signed-off-by: Mika Westerberg &lt;mika.westerberg@linux.intel.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit 308092d080852f8997126e5b3507536162416f4a upstream.

Alex reported that after rebooting the other host the peer-to-peer link
does not come up anymore. The reason for this is that the host that was
not rebooted tries to send the UUID request only 10 times according to
the USB4 Inter-Domain spec and gives up if it does not get reply. Then
when the other side is actually ready it cannot get the link established
anymore. The USB4 Inter-Domain spec requires that the discovery protocol
is restarted in that case so implement this now.

Reported-by: Alex Balcanquall &lt;alex@alexbal.com&gt;
Fixes: 8e1de7042596 ("thunderbolt: Add support for XDomain lane bonding")
Cc: stable@vger.kernel.org
Signed-off-by: Mika Westerberg &lt;mika.westerberg@linux.intel.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>thunderbolt: Correct TMU mode initialization from hardware</title>
<updated>2023-10-19T21:11:05+00:00</updated>
<author>
<name>Mika Westerberg</name>
<email>mika.westerberg@linux.intel.com</email>
</author>
<published>2023-08-31T11:10:46+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=9828a7fa65a6767128832c0b94780361d9446baf'/>
<id>9828a7fa65a6767128832c0b94780361d9446baf</id>
<content type='text'>
commit e19f714ea63f861d95d3d92d45d5fd5ca2e05c8c upstream.

David reported that cppcheck found following possible copy &amp; paste
error from tmu_mode_init():

  tmu.c:385:50: style: Expression is always false because 'else if' condition matches previous condition at line 383. [multiCondition]

And indeed this is a bug. Fix it to use correct index
(TB_SWITCH_TMU_MODE_HIFI_UNI).

Reported-by: David Binderman &lt;dcb314@hotmail.com&gt;
Fixes: d49b4f043d63 ("thunderbolt: Add support for enhanced uni-directional TMU mode")
Cc: stable@vger.kernel.org
Signed-off-by: Mika Westerberg &lt;mika.westerberg@linux.intel.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit e19f714ea63f861d95d3d92d45d5fd5ca2e05c8c upstream.

David reported that cppcheck found following possible copy &amp; paste
error from tmu_mode_init():

  tmu.c:385:50: style: Expression is always false because 'else if' condition matches previous condition at line 383. [multiCondition]

And indeed this is a bug. Fix it to use correct index
(TB_SWITCH_TMU_MODE_HIFI_UNI).

Reported-by: David Binderman &lt;dcb314@hotmail.com&gt;
Fixes: d49b4f043d63 ("thunderbolt: Add support for enhanced uni-directional TMU mode")
Cc: stable@vger.kernel.org
Signed-off-by: Mika Westerberg &lt;mika.westerberg@linux.intel.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>thunderbolt: Check that lane 1 is in CL0 before enabling lane bonding</title>
<updated>2023-10-19T21:11:05+00:00</updated>
<author>
<name>Mika Westerberg</name>
<email>mika.westerberg@linux.intel.com</email>
</author>
<published>2023-08-22T13:36:18+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=7525edf6aca5fd0ab7e1ccafc1c38017fb3ef4ae'/>
<id>7525edf6aca5fd0ab7e1ccafc1c38017fb3ef4ae</id>
<content type='text'>
commit a9fdf5f933a6f2b358fad0194b1287b67f6704b1 upstream.

Marek reported that when BlackMagic UltraStudio device is connected the
kernel repeatedly tries to enable lane bonding without success making
the device non-functional. It looks like the device does not have lane 1
connected at all so even though it is enabled we should not try to bond
the lanes. For this reason check that lane 1 is in fact CL0 (connected,
active) before attempting to bond the lanes.

Reported-by: Marek Šanta &lt;teslan223@gmail.com&gt;
Closes: https://bugzilla.kernel.org/show_bug.cgi?id=217737
Cc: stable@vger.kernel.org
Signed-off-by: Mika Westerberg &lt;mika.westerberg@linux.intel.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit a9fdf5f933a6f2b358fad0194b1287b67f6704b1 upstream.

Marek reported that when BlackMagic UltraStudio device is connected the
kernel repeatedly tries to enable lane bonding without success making
the device non-functional. It looks like the device does not have lane 1
connected at all so even though it is enabled we should not try to bond
the lanes. For this reason check that lane 1 is in fact CL0 (connected,
active) before attempting to bond the lanes.

Reported-by: Marek Šanta &lt;teslan223@gmail.com&gt;
Closes: https://bugzilla.kernel.org/show_bug.cgi?id=217737
Cc: stable@vger.kernel.org
Signed-off-by: Mika Westerberg &lt;mika.westerberg@linux.intel.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>thunderbolt: Workaround an IOMMU fault on certain systems with Intel Maple Ridge</title>
<updated>2023-10-19T21:11:05+00:00</updated>
<author>
<name>Mika Westerberg</name>
<email>mika.westerberg@linux.intel.com</email>
</author>
<published>2023-08-18T12:27:46+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=5e9e8b6448f4f925da4dfa748c8ca74fb984f768'/>
<id>5e9e8b6448f4f925da4dfa748c8ca74fb984f768</id>
<content type='text'>
commit 582620d9f6b352552bc9a3316fe2b1c3acd8742d upstream.

On some systems the IOMMU blocks the first couple of driver ready
messages to the connection manager firmware as can be seen in below
excerpts:

  thunderbolt 0000:06:00.0: AMD-Vi: Event logged [IO_PAGE_FAULT domain=0x0010 address=0xbb0e3400 flags=0x0020]

or

  DMAR: DRHD: handling fault status reg 2
  DMAR: [DMA Write] Request device [04:00.0] PASID ffffffff fault addr 69974000 [fault reason 05] PTE Write access is not set

The reason is unknown and hard to debug because we were not able to
reproduce this locally. This only happens on certain systems with Intel
Maple Ridge Thunderbolt controller. If there is a device connected when
the driver is loaded the issue does not happen either. Only when there
is nothing connected (so typically when the system is booted up).

We can work this around by sending the driver ready several times. After
a couple of retries the message goes through and the controller works
just fine. For this reason make the number of retries a parameter for
icm_request() and then for Maple Ridge (and Titan Ridge as they us the
same function but this should not matter) increase number of retries
while shortening the timeout accordingly.

Reported-by: Werner Sembach &lt;wse@tuxedocomputers.com&gt;
Reported-by: Konrad J Hambrick &lt;kjhambrick@gmail.com&gt;
Reported-by: Calvin Walton &lt;calvin.walton@kepstin.ca&gt;
Closes: https://bugzilla.kernel.org/show_bug.cgi?id=214259
Cc: stable@vger.kernel.org
Signed-off-by: Mika Westerberg &lt;mika.westerberg@linux.intel.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit 582620d9f6b352552bc9a3316fe2b1c3acd8742d upstream.

On some systems the IOMMU blocks the first couple of driver ready
messages to the connection manager firmware as can be seen in below
excerpts:

  thunderbolt 0000:06:00.0: AMD-Vi: Event logged [IO_PAGE_FAULT domain=0x0010 address=0xbb0e3400 flags=0x0020]

or

  DMAR: DRHD: handling fault status reg 2
  DMAR: [DMA Write] Request device [04:00.0] PASID ffffffff fault addr 69974000 [fault reason 05] PTE Write access is not set

The reason is unknown and hard to debug because we were not able to
reproduce this locally. This only happens on certain systems with Intel
Maple Ridge Thunderbolt controller. If there is a device connected when
the driver is loaded the issue does not happen either. Only when there
is nothing connected (so typically when the system is booted up).

We can work this around by sending the driver ready several times. After
a couple of retries the message goes through and the controller works
just fine. For this reason make the number of retries a parameter for
icm_request() and then for Maple Ridge (and Titan Ridge as they us the
same function but this should not matter) increase number of retries
while shortening the timeout accordingly.

Reported-by: Werner Sembach &lt;wse@tuxedocomputers.com&gt;
Reported-by: Konrad J Hambrick &lt;kjhambrick@gmail.com&gt;
Reported-by: Calvin Walton &lt;calvin.walton@kepstin.ca&gt;
Closes: https://bugzilla.kernel.org/show_bug.cgi?id=214259
Cc: stable@vger.kernel.org
Signed-off-by: Mika Westerberg &lt;mika.westerberg@linux.intel.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>thunderbolt: Fix memory leak in tb_handle_dp_bandwidth_request()</title>
<updated>2023-08-04T13:17:47+00:00</updated>
<author>
<name>Mika Westerberg</name>
<email>mika.westerberg@linux.intel.com</email>
</author>
<published>2023-06-22T11:59:12+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=596a5123cc782d458b057eb3837e66535cd0befa'/>
<id>596a5123cc782d458b057eb3837e66535cd0befa</id>
<content type='text'>
The memory allocated in tb_queue_dp_bandwidth_request() needs to be
released once the request is handled to avoid leaking it.

Fixes: 6ce3563520be ("thunderbolt: Add support for DisplayPort bandwidth allocation mode")
Cc: stable@vger.kernel.org
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>
The memory allocated in tb_queue_dp_bandwidth_request() needs to be
released once the request is handled to avoid leaking it.

Fixes: 6ce3563520be ("thunderbolt: Add support for DisplayPort bandwidth allocation mode")
Cc: stable@vger.kernel.org
Signed-off-by: Mika Westerberg &lt;mika.westerberg@linux.intel.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>thunderbolt: Fix Thunderbolt 3 display flickering issue on 2nd hot plug onwards</title>
<updated>2023-08-03T09:57:55+00:00</updated>
<author>
<name>Sanjay R Mehta</name>
<email>sanju.mehta@amd.com</email>
</author>
<published>2023-08-02T11:11:49+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=583893a66d731f5da010a3fa38a0460e05f0149b'/>
<id>583893a66d731f5da010a3fa38a0460e05f0149b</id>
<content type='text'>
Previously, on unplug events, the TMU mode was disabled first
followed by the Time Synchronization Handshake, irrespective of
whether the tb_switch_tmu_rate_write() API was successful or not.

However, this caused a problem with Thunderbolt 3 (TBT3)
devices, as the TSPacketInterval bits were always enabled by default,
leading the host router to assume that the device router's TMU was
already enabled and preventing it from initiating the Time
Synchronization Handshake. As a result, TBT3 monitors experienced
display flickering from the second hot plug onwards.

To address this issue, we have modified the code to only disable the
Time Synchronization Handshake during TMU disable if the
tb_switch_tmu_rate_write() function is successful. This ensures that
the TBT3 devices function correctly and eliminates the display
flickering issue.

Co-developed-by: Sanath S &lt;Sanath.S@amd.com&gt;
Signed-off-by: Sanath S &lt;Sanath.S@amd.com&gt;
Signed-off-by: Sanjay R Mehta &lt;sanju.mehta@amd.com&gt;
Cc: stable@vger.kernel.org
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>
Previously, on unplug events, the TMU mode was disabled first
followed by the Time Synchronization Handshake, irrespective of
whether the tb_switch_tmu_rate_write() API was successful or not.

However, this caused a problem with Thunderbolt 3 (TBT3)
devices, as the TSPacketInterval bits were always enabled by default,
leading the host router to assume that the device router's TMU was
already enabled and preventing it from initiating the Time
Synchronization Handshake. As a result, TBT3 monitors experienced
display flickering from the second hot plug onwards.

To address this issue, we have modified the code to only disable the
Time Synchronization Handshake during TMU disable if the
tb_switch_tmu_rate_write() function is successful. This ensures that
the TBT3 devices function correctly and eliminates the display
flickering issue.

Co-developed-by: Sanath S &lt;Sanath.S@amd.com&gt;
Signed-off-by: Sanath S &lt;Sanath.S@amd.com&gt;
Signed-off-by: Sanjay R Mehta &lt;sanju.mehta@amd.com&gt;
Cc: stable@vger.kernel.org
Signed-off-by: Mika Westerberg &lt;mika.westerberg@linux.intel.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>thunderbolt: Add test case for 3 DisplayPort tunnels</title>
<updated>2023-06-16T06:53:29+00:00</updated>
<author>
<name>Mika Westerberg</name>
<email>mika.westerberg@linux.intel.com</email>
</author>
<published>2022-02-14T12:09:50+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=481012b479fe6d8dd4e01d739c359a8d99d074a9'/>
<id>481012b479fe6d8dd4e01d739c359a8d99d074a9</id>
<content type='text'>
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 &lt;mika.westerberg@linux.intel.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
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 &lt;mika.westerberg@linux.intel.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>thunderbolt: Add DisplayPort 2.x tunneling support</title>
<updated>2023-06-16T06:53:29+00:00</updated>
<author>
<name>Mika Westerberg</name>
<email>mika.westerberg@linux.intel.com</email>
</author>
<published>2023-01-23T08:42:58+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=2d7e047297983dd29c29c41b8b7034d64f861aa2'/>
<id>2d7e047297983dd29c29c41b8b7034d64f861aa2</id>
<content type='text'>
This adds support for the UHBR (Ultra High Bit Rate) bandwidths
introduced with DisplayPort 2.0 (and refined in 2.1). These can go up to
80 Gbit/s and their support is represent in additional bits in the DP IN
capability.

This updates the DisplayPort tunneling to support these new rates too.

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 support for the UHBR (Ultra High Bit Rate) bandwidths
introduced with DisplayPort 2.0 (and refined in 2.1). These can go up to
80 Gbit/s and their support is represent in additional bits in the DP IN
capability.

This updates the DisplayPort tunneling to support these new rates too.

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