On 1/10/2024 8:01 PM, Mika Westerberg wrote:
Hi, On Sat, Jan 06, 2024 at 10:27:19PM +0530, Sanath S wrote:Tunnels created by boot firmware results in incorrect PCI resource allocation, which results in failure of extending daisy chain. This series aims to resolve inconsistent tunnels or paths created by boot firmware. Before: +-03.1-[04-62]----00.0-[05-07]--+-02.0-[06]----00.0 | \-04.0-[07]-- After: +-03.1-[04-62]----00.0-[05-62]--+-02.0-[06]----00.0 | \-04.0-[07-62]-- This series also aligns with windows behaviour of performing a teardown of tunnels and resetting the downstream ports using DPR during the init sequence. Changes since V3: - Remove discover_tunnel() api before resetting DPR. - Add lane and protocol adapters reset in tb_switch_reset() - Addition of tb_lc_reset_port() for TBT1, TBT2 and TBT3 routers. - Addition of tb_path_deactivate_hop() api to help suppport path reset of given hop index. - Addition on new patch to store and indicate host router reset status of USB4 v2 Changes since V2: - Perform DPR only for USB4 routers. - Update kernel-doc and return value to -EOPNOTSUPP. - Limit delay range to 10-15ms. Sanath S (4): thunderbolt: Introduce usb4_port_reset() and tb_lc_reset_port() thunderbolt: Extend tb_switch_reset() to support lane and protocol adapter reset thunderbolt: Store host router reset status in nhi_probe() thunderbolt: Teardown tunnels and reset downstream ports created by boot firmwareThanks for the series! I will give this a try on our end too to make sure there are no issues. If things look good I will queue these for v6.9 after v6.8-rc1 is released.
Thanks Mika :) Looking forward for results at your end.
