linux/drivers/thunderbolt, branch v5.5

thunderbolt: Power cycle the router if NVM authentication fails

2019-11-19T16:35:57Z

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 Cc: stable Signed-off-by: Mika Westerberg Signed-off-by: Greg Kroah-Hartman

thunderbolt: Do not start firmware unless asked by the user

2019-11-02T09:13:31Z

Since now we can do pretty much the same thing in the software connection manager than the firmware would do, there is no point starting it by default. Instead we can just continue using the software connection manager. Make it possible for user to switch between the two by adding a module pararameter (start_icm) which is by default false. Having this ability to enable the firmware may be useful at least when debugging possible issues with the software connection manager implementation. Signed-off-by: Mika Westerberg

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 Display Port adapter pairing and resource management

2019-11-02T09:13:31Z

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 <-> 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

thunderbolt: Add Display Port CM handshake for Titan Ridge devices

2019-11-02T09:13:31Z

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

thunderbolt: Add downstream PCIe port mappings for Alpine and Titan Ridge

2019-11-02T09:13:31Z

In order to keep PCIe hierarchies consistent across hotplugs, add hard-coded PCIe downstream port to Thunderbolt port for Alpine Ridge and Titan Ridge as well. Signed-off-by: Mika Westerberg

thunderbolt: Expand controller name in tb_switch_is_xy()

2019-11-02T09:13:31Z

For a casual reader tb_switch_is_cr() does not tell much so instead spell out the full controller name in the function name. For example tb_switch_is_cr() becomes tb_switch_is_cactus_ridge() which is easier to understand. Signed-off-by: Mika Westerberg

thunderbolt: Add default linking between lane adapters if not provided by DROM

2019-11-02T09:13:31Z

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

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: Refactor add_switch() into two functions

2019-11-01T11:32:00Z

Currently add_switch() takes a huge amount of parameters that makes it hard to maintain. Instead of passing all those parameters we can split the function into two parts (alloc and add) and fill the additional switch fields directly in the functions calling those. While there remove redundant error logging in case kmemdup() fails. No functional changes. Signed-off-by: Mika Westerberg