<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux.git/drivers/thunderbolt/switch.c, branch v5.6-rc2</title>
<subtitle>Linux kernel source tree</subtitle>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/'/>
<entry>
<title>thunderbolt: fix memory leak of object sw</title>
<updated>2020-01-14T14:37:41+00:00</updated>
<author>
<name>Colin Ian King</name>
<email>colin.king@canonical.com</email>
</author>
<published>2019-12-20T22:05:26+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=704a940d551c9946bce3fdd661e00a6370c40522'/>
<id>704a940d551c9946bce3fdd661e00a6370c40522</id>
<content type='text'>
In the case where the call tb_switch_exceeds_max_depth is true
the error reurn path leaks memory in sw.  Fix this by setting
the return error code to -EADDRNOTAVAIL and returning via the
error exit path err_free_sw_ports to free sw. sw has been kzalloc'd
so the free of the NULL sw-&gt;ports is fine.

Addresses-Coverity: ("Resource leak")
Fixes: b04079837b20 ("thunderbolt: Add initial support for USB4")
Signed-off-by: Colin Ian King &lt;colin.king@canonical.com&gt;
Acked-by: Mika Westerberg &lt;mika.westerberg@linux.intel.com&gt;
Link: https://lore.kernel.org/r/20191220220526.11307-1-colin.king@canonical.com
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
In the case where the call tb_switch_exceeds_max_depth is true
the error reurn path leaks memory in sw.  Fix this by setting
the return error code to -EADDRNOTAVAIL and returning via the
error exit path err_free_sw_ports to free sw. sw has been kzalloc'd
so the free of the NULL sw-&gt;ports is fine.

Addresses-Coverity: ("Resource leak")
Fixes: b04079837b20 ("thunderbolt: Add initial support for USB4")
Signed-off-by: Colin Ian King &lt;colin.king@canonical.com&gt;
Acked-by: Mika Westerberg &lt;mika.westerberg@linux.intel.com&gt;
Link: https://lore.kernel.org/r/20191220220526.11307-1-colin.king@canonical.com
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>thunderbolt: Add support for USB 3.x tunnels</title>
<updated>2019-12-18T14:41:40+00:00</updated>
<author>
<name>Rajmohan Mani</name>
<email>rajmohan.mani@intel.com</email>
</author>
<published>2019-12-17T12:33:44+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=e6f818585713efb29d54f732f41291f75046a2c7'/>
<id>e6f818585713efb29d54f732f41291f75046a2c7</id>
<content type='text'>
USB4 added a capability to tunnel USB 3.x protocol over the USB4
fabric. USB4 device routers may include integrated SuperSpeed HUB or a
function or both. USB tunneling follows PCIe so that the tunnel is
created between the parent and the child router from USB3 downstream
adapter port to USB3 upstream adapter port over a single USB4 link.

This adds support for USB 3.x tunneling and also capability to discover
existing USB 3.x tunnels (for example created by connection manager in
boot firmware).

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;
Link: https://lore.kernel.org/r/20191217123345.31850-9-mika.westerberg@linux.intel.com
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
USB4 added a capability to tunnel USB 3.x protocol over the USB4
fabric. USB4 device routers may include integrated SuperSpeed HUB or a
function or both. USB tunneling follows PCIe so that the tunnel is
created between the parent and the child router from USB3 downstream
adapter port to USB3 upstream adapter port over a single USB4 link.

This adds support for USB 3.x tunneling and also capability to discover
existing USB 3.x tunnels (for example created by connection manager in
boot firmware).

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;
Link: https://lore.kernel.org/r/20191217123345.31850-9-mika.westerberg@linux.intel.com
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>thunderbolt: Add support for Time Management Unit</title>
<updated>2019-12-18T14:41:15+00:00</updated>
<author>
<name>Rajmohan Mani</name>
<email>rajmohan.mani@intel.com</email>
</author>
<published>2019-12-17T12:33:43+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=cf29b9afb121494a7aa12dae6eebf81347e0313b'/>
<id>cf29b9afb121494a7aa12dae6eebf81347e0313b</id>
<content type='text'>
Time Management Unit (TMU) is included in each USB4 router. It is used
to synchronize time across the USB4 fabric. By default when USB4 router
is plugged to the domain, its TMU is turned off. This differs from
Thunderbolt (1, 2 and 3) devices whose TMU is by default configured to
bi-directional HiFi mode. Since time synchronization is needed for
proper Display Port tunneling this means we need to configure the TMU on
USB4 compliant devices.

The USB4 spec allows some flexibility on how the TMU can be configured.
This makes it possible to enable link power management states (CLx) in
certain topologies, where for example DP tunneling is not used. TMU can
also be re-configured dynamicaly depending on types of tunnels created
over the USB4 fabric.

In this patch we simply configure the TMU to be in bi-directional HiFi
mode. This way we can tunnel any kind of traffic without need to perform
complex steps to re-configure the domain dynamically. We can add more
fine-grained TMU configuration later on when we start enabling CLx
states.

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;
Link: https://lore.kernel.org/r/20191217123345.31850-8-mika.westerberg@linux.intel.com
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Time Management Unit (TMU) is included in each USB4 router. It is used
to synchronize time across the USB4 fabric. By default when USB4 router
is plugged to the domain, its TMU is turned off. This differs from
Thunderbolt (1, 2 and 3) devices whose TMU is by default configured to
bi-directional HiFi mode. Since time synchronization is needed for
proper Display Port tunneling this means we need to configure the TMU on
USB4 compliant devices.

The USB4 spec allows some flexibility on how the TMU can be configured.
This makes it possible to enable link power management states (CLx) in
certain topologies, where for example DP tunneling is not used. TMU can
also be re-configured dynamicaly depending on types of tunnels created
over the USB4 fabric.

In this patch we simply configure the TMU to be in bi-directional HiFi
mode. This way we can tunnel any kind of traffic without need to perform
complex steps to re-configure the domain dynamically. We can add more
fine-grained TMU configuration later on when we start enabling CLx
states.

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;
Link: https://lore.kernel.org/r/20191217123345.31850-8-mika.westerberg@linux.intel.com
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>thunderbolt: Add initial support for USB4</title>
<updated>2019-12-18T14:38:55+00:00</updated>
<author>
<name>Mika Westerberg</name>
<email>mika.westerberg@linux.intel.com</email>
</author>
<published>2019-12-17T12:33:40+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=b04079837b2094f09e145676eec4b9a56ae8a6aa'/>
<id>b04079837b2094f09e145676eec4b9a56ae8a6aa</id>
<content type='text'>
USB4 is the public specification based on Thunderbolt 3 protocol. There
are some differences in register layouts and flows. In addition to PCIe
and DP tunneling, USB4 supports tunneling of USB 3.x. USB4 is also
backward compatible with Thunderbolt 3 (and older generations but the
spec only talks about 3rd generation). USB4 compliant devices can be
identified by checking USB4 version field in router configuration space.

This patch adds initial support for USB4 compliant hosts and devices
which enables following features provided by the existing functionality
in the driver:

  - PCIe tunneling
  - Display Port tunneling
  - Host and device NVM firmware upgrade
  - P2P networking

This brings the USB4 support to the same level that we already have for
Thunderbolt 1, 2 and 3 devices.

Note the spec talks about host and device "routers" but in the driver we
still use term "switch" in most places. Both can be used interchangeably.

Co-developed-by: Rajmohan Mani &lt;rajmohan.mani@intel.com&gt;
Signed-off-by: Rajmohan Mani &lt;rajmohan.mani@intel.com&gt;
Signed-off-by: Mika Westerberg &lt;mika.westerberg@linux.intel.com&gt;
Link: https://lore.kernel.org/r/20191217123345.31850-5-mika.westerberg@linux.intel.com
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
USB4 is the public specification based on Thunderbolt 3 protocol. There
are some differences in register layouts and flows. In addition to PCIe
and DP tunneling, USB4 supports tunneling of USB 3.x. USB4 is also
backward compatible with Thunderbolt 3 (and older generations but the
spec only talks about 3rd generation). USB4 compliant devices can be
identified by checking USB4 version field in router configuration space.

This patch adds initial support for USB4 compliant hosts and devices
which enables following features provided by the existing functionality
in the driver:

  - PCIe tunneling
  - Display Port tunneling
  - Host and device NVM firmware upgrade
  - P2P networking

This brings the USB4 support to the same level that we already have for
Thunderbolt 1, 2 and 3 devices.

Note the spec talks about host and device "routers" but in the driver we
still use term "switch" in most places. Both can be used interchangeably.

Co-developed-by: Rajmohan Mani &lt;rajmohan.mani@intel.com&gt;
Signed-off-by: Rajmohan Mani &lt;rajmohan.mani@intel.com&gt;
Signed-off-by: Mika Westerberg &lt;mika.westerberg@linux.intel.com&gt;
Link: https://lore.kernel.org/r/20191217123345.31850-5-mika.westerberg@linux.intel.com
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>thunderbolt: Make tb_find_port() available to other files</title>
<updated>2019-12-18T14:34:23+00:00</updated>
<author>
<name>Mika Westerberg</name>
<email>mika.westerberg@linux.intel.com</email>
</author>
<published>2019-12-17T12:33:37+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=386e5e29d81cd088a1111277a18f13d571a6cea5'/>
<id>386e5e29d81cd088a1111277a18f13d571a6cea5</id>
<content type='text'>
We will be needing this when adding initial USB4 support so make it
available to other files in the driver as well. We also rename it to
tb_switch_find_port() to follow conventions used in switch.c.

No functional changes.

Signed-off-by: Mika Westerberg &lt;mika.westerberg@linux.intel.com&gt;
Link: https://lore.kernel.org/r/20191217123345.31850-2-mika.westerberg@linux.intel.com
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
We will be needing this when adding initial USB4 support so make it
available to other files in the driver as well. We also rename it to
tb_switch_find_port() to follow conventions used in switch.c.

No functional changes.

Signed-off-by: Mika Westerberg &lt;mika.westerberg@linux.intel.com&gt;
Link: https://lore.kernel.org/r/20191217123345.31850-2-mika.westerberg@linux.intel.com
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>thunderbolt: Power cycle the router if NVM authentication fails</title>
<updated>2019-11-19T16:35:57+00:00</updated>
<author>
<name>Mika Westerberg</name>
<email>mika.westerberg@linux.intel.com</email>
</author>
<published>2019-11-11T10:25:44+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=7a7ebfa85f4fac349f3ab219538c44efe18b0cf6'/>
<id>7a7ebfa85f4fac349f3ab219538c44efe18b0cf6</id>
<content type='text'>
On zang's Dell XPS 13 9370 after Thunderbolt NVM firmware upgrade the
Thunderbolt controller did not come back as expected. Only after the
system was rebooted it became available again. It is not entirely clear
what happened but I suspect the new NVM firmware image authentication
failed for some reason. Regardless of this the router needs to be power
cycled if NVM authentication fails in order to get it fully functional
again.

This modifies the driver to issue a power cycle in case the NVM
authentication fails immediately when dma_port_flash_update_auth()
returns. We also need to call tb_switch_set_uuid() earlier to be able to
fetch possible NVM authentication failure when DMA port is added.

Link: https://bugzilla.kernel.org/show_bug.cgi?id=205457
Reported-by: zang &lt;dump@tzib.net&gt;
Cc: stable &lt;stable@vger.kernel.org&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>
On zang's Dell XPS 13 9370 after Thunderbolt NVM firmware upgrade the
Thunderbolt controller did not come back as expected. Only after the
system was rebooted it became available again. It is not entirely clear
what happened but I suspect the new NVM firmware image authentication
failed for some reason. Regardless of this the router needs to be power
cycled if NVM authentication fails in order to get it fully functional
again.

This modifies the driver to issue a power cycle in case the NVM
authentication fails immediately when dma_port_flash_update_auth()
returns. We also need to call tb_switch_set_uuid() earlier to be able to
fetch possible NVM authentication failure when DMA port is added.

Link: https://bugzilla.kernel.org/show_bug.cgi?id=205457
Reported-by: zang &lt;dump@tzib.net&gt;
Cc: stable &lt;stable@vger.kernel.org&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: Add Display Port adapter pairing and resource management</title>
<updated>2019-11-02T09:13:31+00:00</updated>
<author>
<name>Mika Westerberg</name>
<email>mika.westerberg@linux.intel.com</email>
</author>
<published>2019-03-26T12:52:30+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=8afe909b78e16ee4baecf78fd4e404aabf425f8c'/>
<id>8afe909b78e16ee4baecf78fd4e404aabf425f8c</id>
<content type='text'>
To perform proper Display Port tunneling for Thunderbolt 3 devices we
need to allocate DP resources for DP IN port before they can be used.
The reason for this is that the user can also connect a monitor directly
to the Type-C ports in which case the Thunderbolt controller acts as
re-driver for Display Port (no tunneling takes place) taking the DP
sinks away from the connection manager. This allocation is done using
special sink allocation registers available through the link controller.

We can pair DP IN to DP OUT only if

 * DP IN has sink allocated via link controller
 * DP OUT port receives hotplug event

For DP IN adapters (only for the host router) we first query whether
there is DP resource available (it may be the previous instance of the
driver for example already allocated it) and if it is we add it to the
list. We then update the list when after each plug/unplug event to a DP
IN/OUT adapter. Each time the list is updated we try to find additional
DP IN &lt;-&gt; DP OUT pairs for tunnel establishment. This strategy also
makes it possible to establish another tunnel in case there are 3
monitors connected and one gets unplugged releasing the DP IN adapter
for the new tunnel.

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>
To perform proper Display Port tunneling for Thunderbolt 3 devices we
need to allocate DP resources for DP IN port before they can be used.
The reason for this is that the user can also connect a monitor directly
to the Type-C ports in which case the Thunderbolt controller acts as
re-driver for Display Port (no tunneling takes place) taking the DP
sinks away from the connection manager. This allocation is done using
special sink allocation registers available through the link controller.

We can pair DP IN to DP OUT only if

 * DP IN has sink allocated via link controller
 * DP OUT port receives hotplug event

For DP IN adapters (only for the host router) we first query whether
there is DP resource available (it may be the previous instance of the
driver for example already allocated it) and if it is we add it to the
list. We then update the list when after each plug/unplug event to a DP
IN/OUT adapter. Each time the list is updated we try to find additional
DP IN &lt;-&gt; DP OUT pairs for tunnel establishment. This strategy also
makes it possible to establish another tunnel in case there are 3
monitors connected and one gets unplugged releasing the DP IN adapter
for the new tunnel.

Signed-off-by: Mika Westerberg &lt;mika.westerberg@linux.intel.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>thunderbolt: Add default linking between lane adapters if not provided by DROM</title>
<updated>2019-11-02T09:13:31+00:00</updated>
<author>
<name>Mika Westerberg</name>
<email>mika.westerberg@linux.intel.com</email>
</author>
<published>2019-08-26T15:19:33+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=0d46c08d1ed4f7bb283c7315824f2bfe2c5e0fa9'/>
<id>0d46c08d1ed4f7bb283c7315824f2bfe2c5e0fa9</id>
<content type='text'>
We currently read how sibling lane adapter ports relate each other from
DROM (Device ROM). If the two lane adapter ports go through the same
physical connector these lanes can then be bonded together. However,
some cases DROM does not provide this information or it is missing
completely (host routers typically do not have DROM). In this case we
have hard-coded the relationship.

Expand this to work with both legacy devices where lane adapter ports 1
and 2, and 3 and 4 are always linked together, and with USB4 devices
where lane adapter 1 is always following lane adapter 0 or is disabled
completely (see USB4 section 5.2.1 for more information).

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>
We currently read how sibling lane adapter ports relate each other from
DROM (Device ROM). If the two lane adapter ports go through the same
physical connector these lanes can then be bonded together. However,
some cases DROM does not provide this information or it is missing
completely (host routers typically do not have DROM). In this case we
have hard-coded the relationship.

Expand this to work with both legacy devices where lane adapter ports 1
and 2, and 3 and 4 are always linked together, and with USB4 devices
where lane adapter 1 is always following lane adapter 0 or is disabled
completely (see USB4 section 5.2.1 for more information).

Signed-off-by: Mika Westerberg &lt;mika.westerberg@linux.intel.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>thunderbolt: Add support for lane bonding</title>
<updated>2019-11-02T09:13:31+00:00</updated>
<author>
<name>Mika Westerberg</name>
<email>mika.westerberg@linux.intel.com</email>
</author>
<published>2019-03-21T17:03:00+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=91c0c12080d0f40ee7275485221b06b4e1e289e1'/>
<id>91c0c12080d0f40ee7275485221b06b4e1e289e1</id>
<content type='text'>
Lane bonding allows aggregating two 10/20 Gb/s (depending on the
generation) lanes into a single 20/40 Gb/s bonded link. This allows
sharing the full bandwidth more efficiently. In order to establish lane
bonding we need to check that lane bonding is possible through link
controller and that both ends of the link actually supports 2x widths.
This also means that all the paths should be established through the
primary port so update tb_path_alloc() to handle this as well.

Lane bonding is supported starting from Falcon Ridge (2nd generation)
controllers.

We also expose the current speed and number of lanes under each device
except the host router following similar attribute naming than USB bus.
Expose speed and number of lanes for both directions to allow possibility
of asymmetric link in the future.

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>
Lane bonding allows aggregating two 10/20 Gb/s (depending on the
generation) lanes into a single 20/40 Gb/s bonded link. This allows
sharing the full bandwidth more efficiently. In order to establish lane
bonding we need to check that lane bonding is possible through link
controller and that both ends of the link actually supports 2x widths.
This also means that all the paths should be established through the
primary port so update tb_path_alloc() to handle this as well.

Lane bonding is supported starting from Falcon Ridge (2nd generation)
controllers.

We also expose the current speed and number of lanes under each device
except the host router following similar attribute naming than USB bus.
Expose speed and number of lanes for both directions to allow possibility
of asymmetric link in the future.

Signed-off-by: Mika Westerberg &lt;mika.westerberg@linux.intel.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>thunderbolt: Add helper macro to iterate over switch ports</title>
<updated>2019-11-01T11:32:00+00:00</updated>
<author>
<name>Mika Westerberg</name>
<email>mika.westerberg@linux.intel.com</email>
</author>
<published>2019-09-30T11:07:22+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=b433d0100562233b21beb13c0139feeff350bc68'/>
<id>b433d0100562233b21beb13c0139feeff350bc68</id>
<content type='text'>
There are quite many places in the driver where we iterate over each
port in the switch. To make it bit more convenient, add a macro that can
be used to iterate over each port and convert existing call sites to use it.

This is based on code by Lukas Wunner.

No functional changes.

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>
There are quite many places in the driver where we iterate over each
port in the switch. To make it bit more convenient, add a macro that can
be used to iterate over each port and convert existing call sites to use it.

This is based on code by Lukas Wunner.

No functional changes.

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