Hi, On Mon, Jan 30, 2023 at 11:52:59AM +0100, Christian Schaubschläger wrote: > Hi, > > Am 27.01.23 um 13:27 schrieb Mika Westerberg: > > Yeah, I just got report from the folks and unfortunately we were not > > able to reproduce the issue in the lab. The PCIe tunnel stays up (or > > gets re-created) after reboot from Linux and is visible in the UEFI > > shell (so in the BIOS). > > > > So at the moment I'm out of ideas why this happens since Windows flows > > should be the same. And we have no means to repro it locally to > > investigate further :/ > > Ok. I try to get access to some more TB4 devices. Currently I have two > (HP, Lenovo) that show the issue when the software connection manager > is used. We should be getting one HP EliteBook 630 G9 soon (I guess this is one of the systems you see the issue). Once we get it we will try to repro and investigate further. > >> Another thought of mine was, if it wouldn't it be useful to have a kernel commandline switch (or thunderbolt module option) that allows the user to select whether the software connection manager should be used, or the firmware connection manager (if avialable)? I understand that in general using the sw connection manager is favorable because the OS then has control over the connection, but maybe there are use cases where letting the firmware doing the job is just fine (like in my case ;-) > > Right, we may add one but I think it should be part of the USB4 _OSC > > negotiation like the below patch (acpi.native_usb4_disable=1 in the > > command line should switch to FW CM). We could also make it "automatic" > > by adding a DMI quirks table that then sets this. > > > > diff --git a/drivers/acpi/bus.c b/drivers/acpi/bus.c > > index 0c05ccde1f7a..7da4d56fb936 100644 > > --- a/drivers/acpi/bus.c > > +++ b/drivers/acpi/bus.c > > @@ -296,6 +296,9 @@ EXPORT_SYMBOL_GPL(osc_cpc_flexible_adr_space_confirmed); > > /* > > * ACPI 6.4 Operating System Capabilities for USB. > > */ > > +bool native_usb4_disable; > > +module_param(native_usb4_disable, bool, 0644); > > + > > bool osc_sb_native_usb4_support_confirmed; > > EXPORT_SYMBOL_GPL(osc_sb_native_usb4_support_confirmed); > > > > @@ -344,7 +347,7 @@ static void acpi_bus_osc_negotiate_platform_control(void) > > if (IS_ENABLED(CONFIG_SCHED_MC_PRIO)) > > capbuf[OSC_SUPPORT_DWORD] |= OSC_SB_CPC_DIVERSE_HIGH_SUPPORT; > > > > - if (IS_ENABLED(CONFIG_USB4)) > > + if (IS_ENABLED(CONFIG_USB4) && !native_usb4_disable) > > capbuf[OSC_SUPPORT_DWORD] |= OSC_SB_NATIVE_USB4_SUPPORT; > > > > if (!ghes_disable) > That works fine on the HP, with that active the firmware connection manger is used! To make it 'automatic' would mean that on machines listed in this new DMI quirks table the software connection manager would be disabled, correct? Yes, correct. However, since the software CM works as well except for this case, I'm having some second thougths on adding a DMI quirk because it makes certain things not be available, such as lane bonding for the networking, and de-authorization of the PCIe tunnels among other things. I think the command line option can be added regardless.
