summaryrefslogtreecommitdiff
path: root/drivers/thunderbolt/path.c
AgeCommit message (Collapse)AuthorFilesLines
2021-02-04thunderbolt: path: Fix kernel-doc descriptions of non-static functionsMika Westerberg1-0/+2
Fix kernel-doc descriptions of the two non-static functions. This also gets rid of the warnings on W=1 build. Reported-by: Lee Jones <lee.jones@linaro.org> Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com> Reviewed-by: Lee Jones <lee.jones@linaro.org>
2020-11-30thunderbolt: Log adapter numbers in decimal in path activation/deactivationMika Westerberg1-2/+2
This makes it consistent with other debug logs that already are using decimal number for adapters (ports). Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2020-11-11thunderbolt: Do not clear USB4 router protocol adapter IFC and ISE bitsMika Westerberg1-3/+10
These fields are marked as vendor defined in the USB4 spec and should not be modified by the software, so only clear them when we are dealing with pre-USB4 hardware. 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-06-22thunderbolt: Add USB3 bandwidth managementMika Westerberg1-7/+6
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-22thunderbolt: Check that both ports are reachable when allocating pathMika Westerberg1-2/+13
Add sanity check that given src and dst ports are reachable through path walk before allocating a path. If they are not then bail out early. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2020-06-22thunderbolt: Make tb_path_alloc() work with tree topologiesMika Westerberg1-6/+6
With USB4, topologies are not limited to daisy-chains anymore so when calculating how many hops are between two ports we need to walk the whole path instead. Add helper function tb_for_each_port_on_path() that can be used to walk over each port on a path and make tb_path_alloc() to use it. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2019-11-02thunderbolt: Add bandwidth management for Display Port tunnelsMika Westerberg1-0/+22
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-02thunderbolt: Add support for lane bondingMika Westerberg1-4/+26
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-04-18thunderbolt: Reword output of tb_dump_hop()Mika Westerberg1-13/+13
While tb_dump_hop() prints out necessary information it is in format that is quite hard to read from the logs especially when one needs to follow the path to see that the setup is correct. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2019-04-18thunderbolt: Make rest of the logging to happen at debug levelMika Westerberg1-3/+3
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-18thunderbolt: Add support for DMA tunnelsMika Westerberg1-4/+18
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-18thunderbolt: Do not tear down tunnels when driver is unloadedMika Westerberg1-6/+4
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-18thunderbolt: Discover preboot PCIe paths the boot firmware establishedMika Westerberg1-22/+182
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-18thunderbolt: Extend tunnel creation to more than 2 adjacent switchesMika Westerberg1-15/+106
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-18thunderbolt: Properly disable pathMika Westerberg1-4/+43
We need to wait until all buffers have been drained before the path can be considered disabled. Do this for every hop in a path. This adds another bit field to struct tb_regs_hop even if we are trying to get rid of them but we can clean them up another day. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2018-10-03thunderbolt: Make the driver less verboseMika Westerberg1-13/+13
Currently the driver logs quite a lot to the system message buffer even when doing normal operations. This information is not useful for ordinary users and might even annoy some. For this reason convert most of the logs at info level to happen at debug level instead. The nice output formatting is untouched. Logging can be easily re-enabled by passing "thunderbolt.dyndbg" in the kernel command line (or using the corresponding control file runtime). Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com> Acked-by: Yehezkel Bernat <yehezkelshb@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2017-11-02License cleanup: add SPDX GPL-2.0 license identifier to files with no licenseGreg Kroah-Hartman1-0/+1
Many source files in the tree are missing licensing information, which makes it harder for compliance tools to determine the correct license. By default all files without license information are under the default license of the kernel, which is GPL version 2. Update the files which contain no license information with the 'GPL-2.0' SPDX license identifier. The SPDX identifier is a legally binding shorthand, which can be used instead of the full boiler plate text. This patch is based on work done by Thomas Gleixner and Kate Stewart and Philippe Ombredanne. How this work was done: Patches were generated and checked against linux-4.14-rc6 for a subset of the use cases: - file had no licensing information it it. - file was a */uapi/* one with no licensing information in it, - file was a */uapi/* one with existing licensing information, Further patches will be generated in subsequent months to fix up cases where non-standard license headers were used, and references to license had to be inferred by heuristics based on keywords. The analysis to determine which SPDX License Identifier to be applied to a file was done in a spreadsheet of side by side results from of the output of two independent scanners (ScanCode & Windriver) producing SPDX tag:value files created by Philippe Ombredanne. Philippe prepared the base worksheet, and did an initial spot review of a few 1000 files. The 4.13 kernel was the starting point of the analysis with 60,537 files assessed. Kate Stewart did a file by file comparison of the scanner results in the spreadsheet to determine which SPDX license identifier(s) to be applied to the file. She confirmed any determination that was not immediately clear with lawyers working with the Linux Foundation. Criteria used to select files for SPDX license identifier tagging was: - Files considered eligible had to be source code files. - Make and config files were included as candidates if they contained >5 lines of source - File already had some variant of a license header in it (even if <5 lines). All documentation files were explicitly excluded. The following heuristics were used to determine which SPDX license identifiers to apply. - when both scanners couldn't find any license traces, file was considered to have no license information in it, and the top level COPYING file license applied. For non */uapi/* files that summary was: SPDX license identifier # files ---------------------------------------------------|------- GPL-2.0 11139 and resulted in the first patch in this series. If that file was a */uapi/* path one, it was "GPL-2.0 WITH Linux-syscall-note" otherwise it was "GPL-2.0". Results of that was: SPDX license identifier # files ---------------------------------------------------|------- GPL-2.0 WITH Linux-syscall-note 930 and resulted in the second patch in this series. - if a file had some form of licensing information in it, and was one of the */uapi/* ones, it was denoted with the Linux-syscall-note if any GPL family license was found in the file or had no licensing in it (per prior point). Results summary: SPDX license identifier # files ---------------------------------------------------|------ GPL-2.0 WITH Linux-syscall-note 270 GPL-2.0+ WITH Linux-syscall-note 169 ((GPL-2.0 WITH Linux-syscall-note) OR BSD-2-Clause) 21 ((GPL-2.0 WITH Linux-syscall-note) OR BSD-3-Clause) 17 LGPL-2.1+ WITH Linux-syscall-note 15 GPL-1.0+ WITH Linux-syscall-note 14 ((GPL-2.0+ WITH Linux-syscall-note) OR BSD-3-Clause) 5 LGPL-2.0+ WITH Linux-syscall-note 4 LGPL-2.1 WITH Linux-syscall-note 3 ((GPL-2.0 WITH Linux-syscall-note) OR MIT) 3 ((GPL-2.0 WITH Linux-syscall-note) AND MIT) 1 and that resulted in the third patch in this series. - when the two scanners agreed on the detected license(s), that became the concluded license(s). - when there was disagreement between the two scanners (one detected a license but the other didn't, or they both detected different licenses) a manual inspection of the file occurred. - In most cases a manual inspection of the information in the file resulted in a clear resolution of the license that should apply (and which scanner probably needed to revisit its heuristics). - When it was not immediately clear, the license identifier was confirmed with lawyers working with the Linux Foundation. - If there was any question as to the appropriate license identifier, the file was flagged for further research and to be revisited later in time. In total, over 70 hours of logged manual review was done on the spreadsheet to determine the SPDX license identifiers to apply to the source files by Kate, Philippe, Thomas and, in some cases, confirmation by lawyers working with the Linux Foundation. Kate also obtained a third independent scan of the 4.13 code base from FOSSology, and compared selected files where the other two scanners disagreed against that SPDX file, to see if there was new insights. The Windriver scanner is based on an older version of FOSSology in part, so they are related. Thomas did random spot checks in about 500 files from the spreadsheets for the uapi headers and agreed with SPDX license identifier in the files he inspected. For the non-uapi files Thomas did random spot checks in about 15000 files. In initial set of patches against 4.14-rc6, 3 files were found to have copy/paste license identifier errors, and have been fixed to reflect the correct identifier. Additionally Philippe spent 10 hours this week doing a detailed manual inspection and review of the 12,461 patched files from the initial patch version early this week with: - a full scancode scan run, collecting the matched texts, detected license ids and scores - reviewing anything where there was a license detected (about 500+ files) to ensure that the applied SPDX license was correct - reviewing anything where there was no detection but the patch license was not GPL-2.0 WITH Linux-syscall-note to ensure that the applied SPDX license was correct This produced a worksheet with 20 files needing minor correction. This worksheet was then exported into 3 different .csv files for the different types of files to be modified. These .csv files were then reviewed by Greg. Thomas wrote a script to parse the csv files and add the proper SPDX tag to the file, in the format that the file expected. This script was further refined by Greg based on the output to detect more types of files automatically and to distinguish between header and source .c files (which need different comment types.) Finally Greg ran the script using the .csv files to generate the patches. Reviewed-by: Kate Stewart <kstewart@linuxfoundation.org> Reviewed-by: Philippe Ombredanne <pombredanne@nexb.com> Reviewed-by: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-08-27thunderbolt: Clear hops before overwritingAndreas Noever1-1/+20
Zero hops in tb_path_activate before writing a new path. This fixes the following scenario: - Boot with a coldplugged device - Unplug device - Plug device back in - PCI hotplug fails The hotplug operation fails because our new path matches the (now defunct) path which was setup by the firmware for the coldplugged device. By writing zeros before writing our path configuration we can force thunderbolt to retrain the path. Signed-off-by: Andreas Noever <andreas.noever@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-06-20thunderbolt: Add path setup code.Andreas Noever1-0/+215
A thunderbolt path is a unidirectional channel between two thunderbolt ports. Two such paths are needed to establish a pci tunnel. This patch introduces struct tb_path as well as a set of tb_path_* methods which are used to activate & deactivate paths. Signed-off-by: Andreas Noever <andreas.noever@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>