Re: Possible problem with thunderbolt 4

[Mika Westerberg <mika.westerberg@linux.intel.com>]

Hi,

On Tue, Jan 03, 2023 at 10:08:16AM +0100, Christian Schaubschläger wrote:
> Good morning,
> 
> > Can you try the below hack? It should tear down all tunnels during
> > reboot so the firmware should see pristine path configuration spaces
> > (assuming it is looking at them and failing because if already configure
> > paths).
> >
> > diff --git a/drivers/thunderbolt/tb.c b/drivers/thunderbolt/tb.c
> > index 1711dc19b1e2..e0544843e242 100644
> > --- a/drivers/thunderbolt/tb.c
> > +++ b/drivers/thunderbolt/tb.c
> > @@ -1982,13 +1982,7 @@ static void tb_stop(struct tb *tb)
> >  	cancel_delayed_work(&tcm->remove_work);
> >  	/* tunnels are only present after everything has been initialized */
> >  	list_for_each_entry_safe(tunnel, n, &tcm->tunnel_list, list) {
> > -		/*
> > -		 * DMA tunnels require the driver to be functional so we
> > -		 * tear them down. Other protocol tunnels can be left
> > -		 * intact.
> > -		 */
> > -		if (tb_tunnel_is_dma(tunnel))
> > -			tb_tunnel_deactivate(tunnel);
> > +		tb_tunnel_deactivate(tunnel);
> >  		tb_tunnel_free(tunnel);
> >  	}
> >  	tb_switch_remove(tb->root_switch);
> That doesn't change the behaviour unfortunately.

Okay then it is not about the paths.

> I did find out two (confusing) things, though. The network interface
> on the dock is an Intel I255-LMvP, in linux it's eth1. When I do this
> before the reboot:
> 
> echo 1 > /sys/class/net/eth1/device/remove
> 
> the device is removed and then added again immedidately:
> 
> [   31.930950] IPv6: ADDRCONF(NETDEV_CHANGE): eth1: link becomes ready
> [   77.496059] igc 0000:2c:00.0 eth1: PHC removed
> [   77.670531] pci 0000:2c:00.0: Removing from iommu group 21
> [   78.551553] pci 0000:2c:00.0: [8086:5502] type 00 class 0x020000
> [   78.552412] pci 0000:2c:00.0: reg 0x10: [mem 0x00000000-0x000fffff]
> [   78.553194] pci 0000:2c:00.0: reg 0x1c: [mem 0x00000000-0x00003fff]
> [   78.554128] pci 0000:2c:00.0: PME# supported from D0 D3hot D3cold
> [   78.555110] pci 0000:2c:00.0: Adding to iommu group 21
> [   78.555913] pcieport 0000:04:04.0: ASPM: current common clock configuration is inconsistent, reconfiguring
> [   78.566265] pci_bus 0000:05: Allocating resources
> [   78.566285] pci_bus 0000:2c: Allocating resources
> [   78.566296] pci 0000:2c:00.0: BAR 0: assigned [mem 0x82000000-0x820fffff]
> [   78.567075] pci 0000:2c:00.0: BAR 3: assigned [mem 0x82100000-0x82103fff]
> [   78.567862] igc 0000:2c:00.0: enabling device (0000 -> 0002)
> [   78.568671] igc 0000:2c:00.0: PTM enabled, 4ns granularity
> [   78.626297] pps pps0: new PPS source ptp1
> [   78.627161] igc 0000:2c:00.0 (unnamed net_device) (uninitialized): PHC added
> [   78.653444] igc 0000:2c:00.0: 4.000 Gb/s available PCIe bandwidth (5.0 GT/s PCIe x1 link)
> [   78.654448] igc 0000:2c:00.0 eth1: MAC: 5c:60:ba:71:ea:be
> [   78.655307] pci_bus 0000:05: Allocating resources
> [   78.655327] pci_bus 0000:2c: Allocating resources
> [   81.598703] igc 0000:2c:00.0 eth1: NIC Link is Up 1000 Mbps Full Duplex, Flow Control: RX/TX
> [   81.599729] IPv6: ADDRCONF(NETDEV_CHANGE): eth1: link becomes ready
> 
> 
> If I reboot now, I can see the network interface in the firmware!

Does this happens 100% or it happened just once?

> And now for the confusing part: I do exactly the same steps as above,
> but whith an external display connected to the dock. Even if I don't
> touch this display in Linux (the i915 driver isn't loaded, just efi
> framebuffer), then the net interface is gone in the firmware after the
> reboot...

It is enough if there is monitor plugged the DP tunnel is then up even
if there is no i915.

> Also, after the
> 
> echo 1 > /sys/class/net/eth1/device/remove
> 
> 
> the device doesn't show up in linux again:
> 
> [   10.158596] IPv6: ADDRCONF(NETDEV_CHANGE): eth1: link becomes ready
> [   42.773958] igc 0000:2c:00.0 eth1: PHC removed
> [   42.962208] pci 0000:2c:00.0: Removing from iommu group 21

You mean with display connected it does not show up again?

I think what is expected is that when you do

 # echo 1 > /sys/class/net/eth1/device/remove

the network interface is removed and it is not expected to come back but
I realized that when you have the DP connected the TCSS (Type-C
SubsSystem) does not enter D3.

So I wonder if you can run another test still?

0. Remove the hack patch if not already.

Steps 1-3 same as before.

4. Disable runtime PM from the PCIe root ports:

  # echo on > /sys/bus/pci/devices/0000:00:07.0/power/control
  # echo on > /sys/bus/pci/devices/0000:00:07.1/power/control
  # echo on > /sys/bus/pci/devices/0000:00:07.2/power/control
  # echo on > /sys/bus/pci/devices/0000:00:07.3/power/control

(or how many Thunderbolt PCIE root ports you have, disable it from all of them).

5. De-authorize the PCIe tunnel

  # echo 0 > /sys/bus/thunderbolt/devices/.../authorized

6. Soft reboot

Does this change anything or the behavior is the same?