linux-kernel - Re: [PATCH] thunderbolt: Fix PCIe device enumeration with delayed rescan

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]

Message-ID: <087dcbe3-ad68-4f45-877b-8f78721efa4b@kylinos.cn>
Date: Tue, 3 Feb 2026 18:00:06 +0800
From: Jayi Li <lijiayi@...inos.cn>
To: Mika Westerberg <mika.westerberg@...ux.intel.com>
Cc: "Chia-Lin Kao (AceLan)" <acelan.kao@...onical.com>,
 Andreas Noever <andreas.noever@...il.com>,
 Mika Westerberg <westeri@...nel.org>, Yehezkel Bernat
 <YehezkelShB@...il.com>, linux-usb@...r.kernel.org,
 linux-kernel@...r.kernel.org, Gil Fine <gil.fine@...ux.intel.com>
Subject: Re: [PATCH] thunderbolt: Fix PCIe device enumeration with delayed
 rescan

Hi,

在 2026/2/3 17:39, Mika Westerberg 写道:
> Hi,
>
> On Tue, Feb 03, 2026 at 05:04:53PM +0800, Jayi Li wrote:
>>> If you do this on Intel host do you see the same?
>> I also encountered a similar issue where the PCIe hotplug IRQ is not
>> received
>> after path setup completion. This was observed specifically during
>> Thunderbolt 3
>> device hotplug testing.
>>
>> To investigate, I applied a debug patch (attached below) to dump
>> ADP_PCIE_CS_0.
>> I observed that when the issue occurs, the PCIe upstream port's LTSSM is not
>> in the DETECT state,
>> yet the PE (Port Enable) bit remains set to 1.
> The PCIe Upstream Port is TB3 device?
Yes.
>
> For TB3 there is no LTTSM state in that register so the value you read can
> be anything.
Apologies for the confusion. I wasn't aware that ADP_PCIE_CS_0 does not 
reflect the LTSSM state on Thunderbolt 3.
> We can do it for USB4, like with this patch:
>
> https://lore.kernel.org/linux-usb/20260127094953.GF2275908@black.igk.intel.com/
>
> It should be modified so that it just checks for the USB4 side.
>
>> My workaround is to check the LTSSM state before the path setup.
>> If this specific anomaly is detected, I explicitly set PE to 0 to reset the
>> link state.
>> With this change, the link returns to the correct state. After the path
>> setup completes,
>> the PCIe hotplug IRQ is received correctly.
>>
>> I'm not sure if this is relevant to this issue, but sharing just in case.
> Thanks for sharing!
>
> It could be. What device this is?
The device is Targus DOCK221.