linux-kernel - Re: [Patch v2 2/2] thunderbolt: Teardown tunnels and reset downstream ports created by boot firmware

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date: Thu, 21 Dec 2023 15:01:50 +0530
From: Sanath S <sanaths2@....com>
To: Mika Westerberg <mika.westerberg@...ux.intel.com>
Cc: Sanath S <Sanath.S@....com>, mario.limonciello@....com,
 andreas.noever@...il.com, michael.jamet@...el.com, YehezkelShB@...il.com,
 linux-usb@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [Patch v2 2/2] thunderbolt: Teardown tunnels and reset downstream
 ports created by boot firmware


On 12/20/2023 10:31 PM, Sanath S wrote:
>
> On 12/20/2023 6:28 PM, Mika Westerberg wrote:
>> On Tue, Dec 19, 2023 at 08:04:24PM +0200, Mika Westerberg wrote:
>>>>> One additional question though, say we have PCIe tunnel 
>>>>> established by
>>>>> the BIOS CM and we do the "reset", that means there will be 
>>>>> hot-remove
>>>>> on the PCIe side and then hotplug again, does this slow down the boot
>>>>> considerably? We have some delays there in the PCIe code that 
>>>>> might hit
>>>>> us here although I agree that we definitely prefer working system 
>>>>> rather
>>>>> than fast-booting non-working system but perhaps the delays are not
>>>>> noticeable by the end-user?
>>>> I've not observed any delay which is noticeable. As soon as I get 
>>>> the login
>>>> screen
>>>> and check dmesg, it would already be enumerated.
>>> Okay, I need to try it on my side too.
>> One additional thing that came to mind. Please check with some device
>> with a real PCIe endpoint. For instance there is the integrated xHCI
>> controller on Intel Titan Ridge and Goshen Ridge based docks. With TR it
>> is easy because it does not support USB4 so xHCI is brought up
>> immediately once there is PCIe tunnel. For GR (the OWC dock you have) it
>> is disabled when the link is USB4 (because USB 3.x is tunneled as well)
>> but you can get it enabled too if you connect it with an active TBT3
>> cable.
> Sure. I'll check with these combinations.
Can you name any docks that meets these requirements ? I'll try to get hold
of it here and check.