user/sven/linux.git/drivers/thunderbolt/path.c, branch v5.8.2

thunderbolt: Add bandwidth management for Display Port tunnels

2019-11-02T09:13:31Z

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

thunderbolt: Add support for lane bonding

2019-11-02T09:13:31Z

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

thunderbolt: Reword output of tb_dump_hop()

2019-04-18T08:18:54Z

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

thunderbolt: Make rest of the logging to happen at debug level

2019-04-18T08:18:53Z

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

thunderbolt: Add support for DMA tunnels

2019-04-18T08:18:53Z

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

thunderbolt: Do not tear down tunnels when driver is unloaded

2019-04-18T08:18:53Z

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

thunderbolt: Discover preboot PCIe paths the boot firmware established

2019-04-18T08:18:53Z

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

thunderbolt: Extend tunnel creation to more than 2 adjacent switches

2019-04-18T08:18:52Z

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

thunderbolt: Properly disable path

2019-04-18T08:18:52Z

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

thunderbolt: Make the driver less verbose

2018-10-02T22:52:08Z

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 Acked-by: Yehezkel Bernat Signed-off-by: Greg Kroah-Hartman