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

From: Sanath S
Date: Wed Jan 10 2024 - 10:30:17 EST



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

Thanks Mika :)
Looking forward for results at your end.