Commit Graph

33 Commits

Author SHA1 Message Date
Mika Westerberg
43bddb26e2 thunderbolt: Tear down existing tunnels when resuming from hibernate
If the boot firmware implements connection manager of its own it may not
create the paths in the same way or order we do. For example it may
create first PCIe tunnel and then USB3 tunnel. When we restore our
tunnels (first de-activating them) we may be doing that over completely
different tunnels and that leaves them possibly non-functional. For this
reason we re-use the tunnel discovery functionality and find out all the
existing tunnels, and tear them down. Once that is done we can restore
our tunnels.

Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2021-12-07 15:18:33 +03:00
Mika Westerberg
6ed541c53e thunderbolt: Allocate credits according to router preferences
The USB4 Connection Manager guide provides detailed information how the
USB4 router buffer (credit) allocation information should be used by the
connection manager when it allocates buffers for different paths. This
patch implements it for Linux. For USB 3.x and DisplayPort we use
directly the router preferences. The rest of the buffer space is then
used for PCIe and DMA (peer-to-peer, XDomain) traffic. DMA tunnels
require at least one buffer and PCIe six, so if there is not enough
buffers we fail the tunnel creation.

For the legacy Thunderbolt 1-3 devices we use the existing hard-coded
scheme except for DMA where we use the values suggested by the USB4 spec
chapter 13.

Co-developed-by: Gil Fine <gil.fine@intel.com>
Signed-off-by: Gil Fine <gil.fine@intel.com>
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2021-06-01 10:48:59 +03:00
Mika Westerberg
02c5e7c2db thunderbolt: Move nfc_credits field to struct tb_path_hop
With the USB4 buffer allocation the number of credits (and non-flow
credits) may be different depending on the router buffer allocation
preferences. To allow this move the nfc_credits field to struct
tb_path_hop.

Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2021-06-01 10:48:59 +03:00
Mika Westerberg
180b068942 thunderbolt: Allow multiple DMA tunnels over a single XDomain connection
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 <mika.westerberg@linux.intel.com>
2021-03-18 18:25:31 +03:00
Mika Westerberg
e5876559b5 thunderbolt: Use dedicated flow control for DMA tunnels
The USB4 inter-domain service spec recommends using dedicated flow
control scheme so update the driver accordingly.

Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2021-03-18 18:25:31 +03:00
Mika Westerberg
c6da62a219 thunderbolt: Add support for native USB4 _OSC
ACPI 6.4 introduced a new _OSC capability used to negotiate whether the
OS is supposed to use Software (native) or Firmware based Connection
Manager. If the native support is granted then there are set of bits
that enable/disable different tunnel types that the Software Connection
Manager is allowed to tunnel.

This adds support for this new USB4 _OSC accordingly. When PCIe
tunneling is disabled then the driver switches security level to be
"nopcie" following the security level 5 used in Firmware based
Connection Manager.

Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Acked-by: Yehezkel Bernat <YehezkelShB@gmail.com>
2021-02-04 10:45:25 +03:00
Lee Jones
a27ea0dfc1 thunderbolt: tunnel: Fix misspelling of 'receive_path'
Fixes the following W=1 kernel build warning(s):

 drivers/thunderbolt/tunnel.c:841: warning: Function parameter or member 'receive_path' not described in 'tb_tunnel_alloc_dma'
 drivers/thunderbolt/tunnel.c:841: warning: Excess function parameter 'reveive_path' description in 'tb_tunnel_alloc_dma'

Cc: Andreas Noever <andreas.noever@gmail.com>
Cc: Michael Jamet <michael.jamet@intel.com>
Cc: Yehezkel Bernat <YehezkelShB@gmail.com>
Cc: linux-usb@vger.kernel.org
Signed-off-by: Lee Jones <lee.jones@linaro.org>
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2021-01-28 13:57:06 +03:00
Mika Westerberg
5bf722df5d thunderbolt: Make it possible to allocate one directional DMA tunnel
With DMA tunnels it is possible that the service using it does not
require bi-directional paths so make RX and TX optional (but of course
one of them needs to be set).

Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Acked-by: Yehezkel Bernat <YehezkelShB@gmail.com>
Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-11-11 10:20:16 +03:00
Greg Kroah-Hartman
6b6c71e897 thunderbolt: Fixes for v5.9-rc4
This includes two fixes, one that fixes a regression around reboot and
 other that uses a correct link rate when USB3 bandwidth is reclaimed
 when the link is not up.
 
 Both have been in linux-next with no reported issues.
 -----BEGIN PGP SIGNATURE-----
 
 iQJUBAABCgA+FiEEVTdhRGBbNzLrSUBaAP2fSd+ZWKAFAl9N9lMgHG1pa2Eud2Vz
 dGVyYmVyZ0BsaW51eC5pbnRlbC5jb20ACgkQAP2fSd+ZWKDqFg//Rm8xBbFp+DFF
 LysW8K6ZCEbwUVZa0CvrDv2fSG/E//yYKstMOIuIZBs49LENNEGtQeyPwRkZmeyk
 LA1n6lxOefyLDHw/7Q4pd6mrxFTUBQoLYrTofuTck5b7HVABv1CpyhWjBmEijTy0
 wKcSEE2LWDJ4e6ROMrk6X6hYSYAIgfjWyjiiswqETuPB7s62Nnpv14cLc6//2thc
 OzRaa5qKJ3ldwswJZzjFDWriDIyIBQiEHHP8YM+QfiMNs+Fb/pP1Uxyg0OJSk6g3
 1qMV8b2VmSXdnT0APF0oyxkkB3zELvJo33RhRKgW9OTAhFkPSeqdxbydAe//MdVo
 AWjJ8hvRcFCxnXF9cKzA3HagUX4CVP/IXSH3L8kWR9PprRJvsGXKNA4Xna9Cx4FI
 qfPatQ73ATIBM2iwsFiYweawuO0Ti5JcPpRBfm1D4rG0yv/r7rN+3fBatHsrdYi4
 FMT+kRZI/GUi5LQFXLcG6UE8BesGipJJvGJTIkuKu7GQJ3RlLrZRLMkmM/wTx6be
 aahVT25OXUeZJ77y+RhgVQuikSWDTLS4TjXBa7/t0y+JuEkBjtoPlDbWn3IFGaRr
 oPnCkNnpFvTA8pnv7KWt9X8J5pZW3WNd35OmPlTilXBz1gbrH6+U0sSE5KsC6ii1
 EYewgZI+e8qZXGcwDw0qBBXJ8RqFWPI=
 =vxwa
 -----END PGP SIGNATURE-----

Merge tag 'thunderbolt-for-v5.9-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/westeri/thunderbolt into usb-linus

Mika writes:

thunderbolt: Fixes for v5.9-rc4

This includes two fixes, one that fixes a regression around reboot and
other that uses a correct link rate when USB3 bandwidth is reclaimed
when the link is not up.

Both have been in linux-next with no reported issues.

* tag 'thunderbolt-for-v5.9-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/westeri/thunderbolt:
  thunderbolt: Use maximum USB3 link rate when reclaiming if link is not up
  thunderbolt: Disable ports that are not implemented
2020-09-01 09:48:28 +02:00
Mika Westerberg
813050e0a9 thunderbolt: Use maximum USB3 link rate when reclaiming if link is not up
If the USB3 link is not up the actual link rate is 0 so when reclaiming
bandwidth we should look at maximum supported link rate instead.

Cc: stable@vger.kernel.org
Fixes: 0bd680cd90 ("thunderbolt: Add USB3 bandwidth management")
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2020-08-25 11:29:01 +03:00
Gustavo A. R. Silva
df561f6688 treewide: Use fallthrough pseudo-keyword
Replace the existing /* fall through */ comments and its variants with
the new pseudo-keyword macro fallthrough[1]. Also, remove unnecessary
fall-through markings when it is the case.

[1] https://www.kernel.org/doc/html/v5.7/process/deprecated.html?highlight=fallthrough#implicit-switch-case-fall-through

Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org>
2020-08-23 17:36:59 -05:00
Mika Westerberg
0bd680cd90 thunderbolt: Add USB3 bandwidth management
USB3 supports both isochronous and non-isochronous traffic. The former
requires guaranteed bandwidth and can take up to 90% of the total
bandwidth. With USB4 USB3 is tunneled over USB4 fabric which means that
we need to make sure there is enough bandwidth allocated for the USB3
tunnels in addition to DisplayPort tunnels.

Whereas DisplayPort bandwidth management is static and done before the
DP tunnel is established, the USB3 bandwidth management is dynamic and
allows increasing and decreasing the allocated bandwidth according to
what is currently consumed. This is done through host router USB3
downstream adapter registers.

This adds USB3 bandwidth management to the software connection manager
so that we always try to allocate maximum bandwidth for DP tunnels and
what is left is allocated for USB3.

Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2020-06-22 19:58:20 +03:00
Mika Westerberg
acf815b867 thunderbolt: Increase DP DPRX wait timeout
Sometimes it takes longer for DPRX to be set so increase the timeout to
cope with this.

Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2020-06-22 19:58:20 +03:00
Mika Westerberg
7c0ee8fd3b thunderbolt: Report consumed bandwidth in both directions
Whereas DisplayPort bandwidth is consumed only in one direction (from DP
IN adapter to DP OUT adapter), USB3 adds separate bandwidth for both
upstream and downstream directions.

For this reason extend the tunnel consumed bandwidth routines to support
both directions and implement this for DP.

Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2020-06-22 19:58:20 +03:00
Mika Westerberg
75ab3f06a1 thunderbolt: Handle incomplete PCIe/USB3 paths correctly in discovery
If the path is not complete when we do discovery the number of hops may
be less than with the full path. As an example when this can happen is
that user unloads the driver, disconnects the topology, and loads the
driver back. If there is PCIe or USB3 tunnel involved this may happen.

Take this into account in tb_pcie_init_path() and tb_usb3_init_path()
and prevent potential access over array limits.

Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2020-06-22 19:58:20 +03:00
Mika Westerberg
783735f84f thunderbolt: Fix path indices used in USB3 tunnel discovery
The USB3 discovery used wrong indices when tunnel is discovered. It
should use TB_USB3_PATH_DOWN for path that flows downstream and
TB_USB3_PATH_UP when it flows upstream. This should not affect the
functionality but better to fix it.

Fixes: e6f8185857 ("thunderbolt: Add support for USB 3.x tunnels")
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Cc: stable@vger.kernel.org # v5.6+
2020-06-22 19:58:19 +03:00
Rajmohan Mani
e6f8185857 thunderbolt: Add support for USB 3.x tunnels
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 <rajmohan.mani@intel.com>
Co-developed-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Link: https://lore.kernel.org/r/20191217123345.31850-9-mika.westerberg@linux.intel.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-12-18 15:41:40 +01:00
Mika Westerberg
b04079837b thunderbolt: Add initial support for USB4
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 <rajmohan.mani@intel.com>
Signed-off-by: Rajmohan Mani <rajmohan.mani@intel.com>
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Link: https://lore.kernel.org/r/20191217123345.31850-5-mika.westerberg@linux.intel.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-12-18 15:38:55 +01:00
Mika Westerberg
a11b88add4 thunderbolt: Add bandwidth management for Display Port tunnels
Titan Ridge supports Display Port 1.4 which adds HBR3 (High Bit Rate)
rates that may be up to 8.1 Gb/s over 4 lanes. This translates to
effective data bandwidth of 25.92 Gb/s (as 8/10 encoding is removed by
the DP adapters when going over Thunderbolt fabric). If another high
rate monitor is connected we may need to reduce the bandwidth it
consumes so that it fits into the total 40 Gb/s available on the
Thunderbolt fabric.

Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2019-11-02 12:13:31 +03:00
Mika Westerberg
de718ac7b6 thunderbolt: Add Display Port CM handshake for Titan Ridge devices
Titan Ridge needs an additional connection manager handshake in order to
do proper Display Port tunneling so implement it here.

Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2019-11-02 12:13:31 +03:00
Mika Westerberg
91c0c12080 thunderbolt: Add support for lane bonding
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 <mika.westerberg@linux.intel.com>
2019-11-02 12:13:31 +03:00
Mika Westerberg
98176380cb thunderbolt: Convert DP adapter register names to follow the USB4 spec
Now that USB4 spec has names for these DP adapter registers we can use
them instead. This makes it easier to match certain register to the spec.

No functional changes.

Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2019-11-01 14:32:00 +03:00
Mika Westerberg
8f57d47806 thunderbolt: Convert basic adapter register names to follow the USB4 spec
Now that USB4 spec has names for these basic registers we can use them
instead. This makes it easier to match certain register to the spec.

No functional changes.

Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2019-11-01 14:31:59 +03:00
Mika Westerberg
ce19f91eae thunderbolt: Correct path indices for PCIe tunnel
PCIe tunnel path indices got mixed up when we added support for tunnels
between switches that are not adjacent. This did not affect the
functionality as it is just an index but fix it now nevertheless to make
the code easier to understand.

Reported-by: Rajmohan Mani <rajmohan.mani@intel.com>
Fixes: 8c7acaaf02 ("thunderbolt: Extend tunnel creation to more than 2 adjacent switches")
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Reviewed-by: Yehezkel Bernat <YehezkelShB@gmail.com>
2019-08-26 12:08:57 +03:00
Mika Westerberg
62efe699a7 thunderbolt: Make rest of the logging to happen at debug level
Now that the driver can handle every possible tunnel types there is no
point to log everything as info level so turn these to happen at debug
level instead.

While at it remove duplicated tunnel activation log message
(tb_tunnel_activate() calls tb_tunnel_restart() which print the same
message) and add one missing '\n' termination.

Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2019-04-18 11:18:53 +03:00
Mika Westerberg
44242d6c97 thunderbolt: Add support for DMA tunnels
In addition to PCIe and Display Port tunnels it is also possible to
create tunnels that forward DMA traffic from the host interface adapter
(NHI) to a NULL port that is connected to another domain through a
Thunderbolt cable. These tunnels can be used to carry software messages
such as networking packets.

To support this we introduce another tunnel type (TB_TUNNEL_DMA) that
supports paths from NHI to NULL port and back.

Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2019-04-18 11:18:53 +03:00
Mika Westerberg
ab9f31cfa8 thunderbolt: Do not tear down tunnels when driver is unloaded
Now that we have capability to discover existing tunnels during driver
load there is no point tearing down tunnels when the driver gets
unloaded. Instead we can just leave them running. If user disconnects
devices while there is no Thunderbolt driver loaded, tunneled protocol
hotplug happens and is handled by the corresponding driver (pciehp in
case of PCIe tunnel, GFX driver in case of DP tunnel).

Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2019-04-18 11:18:53 +03:00
Mika Westerberg
4f807e47ee thunderbolt: Add support for Display Port tunnels
Display Port tunnels are somewhat more complex than PCIe tunnels as it
requires 3 tunnels (AUX Rx/Tx and Video). In addition we are not
supposed to create the tunnels immediately when a DP OUT is enumerated.
Instead we need to wait until we get hotplug event to that adapter port
or check if the port has HPD set before tunnels can be established. This
adds Display Port tunneling support to the software connection manager.

Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2019-04-18 11:18:53 +03:00
Mika Westerberg
0414bec5f3 thunderbolt: Discover preboot PCIe paths the boot firmware established
In Apple Macs the boot firmware (EFI) connects all devices automatically
when the system is started, before it hands over to the OS. Instead of
ignoring we discover all those PCIe tunnels and record them using our
internal structures, just like we do when a device is connected after
the OS is already up.

By doing this we can properly tear down tunnels when devices are
disconnected. Also this allows us to resume the existing tunnels after
system suspend/resume cycle.

Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2019-04-18 11:18:53 +03:00
Mika Westerberg
aae9e27f3b thunderbolt: Deactivate all paths before restarting them
State of the connected devices and tunnel configuration is not known
during resume. For example some paths may not be complete anymore if the
user has unplugged the related devices. So instead of marking all paths
as inactive we go ahead and deactivate them explicitly before we restart
them.

Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2019-04-18 11:18:52 +03:00
Mika Westerberg
8c7acaaf02 thunderbolt: Extend tunnel creation to more than 2 adjacent switches
Now that we can allocate hop IDs per port on a path, we can take
advantage of this and create tunnels covering longer paths than just
between two adjacent switches. PCIe actually does not need this as it
is typically a daisy chain between two adjacent switches but this way we
do not need to hard-code creation of the tunnel.

While there add name to struct tb_path to make debugging easier, and
update kernel-doc comments.

Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2019-04-18 11:18:52 +03:00
Mika Westerberg
93f36ade5b thunderbolt: Generalize tunnel creation functionality
To be able to tunnel non-PCIe traffic, separate tunnel functionality
into generic and PCIe specific parts. Rename struct tb_pci_tunnel to
tb_tunnel, and make it hold an array of paths instead of just two.
Update all the tunneling functions to take this structure as parameter.

We also move tb_pci_port_active() to switch.c (and rename it) where we
will be keeping all port and switch related functions.

Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2019-04-18 11:18:52 +03:00
Mika Westerberg
1752b9f787 thunderbolt: Rename tunnel_pci to tunnel
In order to tunnel non-PCIe traffic as well rename tunnel_pci.[ch] to
tunnel.[ch] to reflect this fact. No functional changes.

Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2019-04-18 11:18:52 +03:00