On 12/18/2023 5:53 PM, Mika Westerberg wrote:
On Mon, Dec 18, 2023 at 01:31:51PM +0200, Mika Westerberg wrote:
On Mon, Dec 18, 2023 at 04:49:13PM +0530, Sanath S wrote:
The discover part should not do anything (like write the hardware) so
perhaps it is just some timing thing (but that's weird too).
I think we should do something like this:
1. Disable all enabled protocol adapters (reset them to defaults).
2. Clear all protocol adapter paths.
3. Issue DPR over all enabled USB4 ports.
BTW, what you mean "didn't work"?
Path activation would go fine after DPR like below:
[ 15.090905] thunderbolt 0000:c4:00.5: 0:5 <-> 2:9 (PCI): activating
[ 15.090932] thunderbolt 0000:c4:00.5: activating PCIe Down path from 0:5
to 2:9
[ 15.091602] thunderbolt 0000:c4:00.5: activating PCIe Up path from 2:9 to
0:5
But, PCIE enumeration doesn't happen (pcie link up will not happen, will not
see below logs)
[ 15.134223] pcieport 0000:00:03.1: pciehp: Slot(0-1): Card present
[ 15.134243] pcieport 0000:00:03.1: pciehp: Slot(0-1): Link Up
Okay, what if you like reset the PCIe adapter config spaces back to the
defaults? Just as an experiment.
If this turns out to be really complex then I guess it is better to do
it like you did originally using discovery but at least it would be nice
to see what the end result of this experiment looks like :)
Yes, I'll give a try.
As an experiment, I tried to compare the path deactivation that occurs
at two place.
1. In tb_switch_reset where we are calling tb_path_deactivate_hop(port, i).
2. While we get a unplug event after doing DPR.
I observed both have different hop_index and port numbers.
So, are we calling tb_path_deactivate_hop with wrong hop ids ?
From deactivate tunnel (called while unplug) :
[ 3.408268] thunderbolt 0000:c4:00.5: deactivating PCIe Down path
from 2:9 to 0:5
[ 3.408282] deactivate hop port = 9 hop_index=8
[ 3.408328] deactivate hop port = 2 hop_index=10
Deactivate from tb_switch_reset() :
deactivate hop port = 5 hop_index=8
