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 firmware All applied to thunderbolt.git/next, thanks! I did some tweaking to the code and the changelogs. Please check and make sure your test cases still pass. These have been in our internal validation for a while and no issues have been reported so far.
