Re: [Patch v3 0/4] Add support for downstream port reset(DPR)

[Mika Westerberg]

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 firmware

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