[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20260203093957.GD2275908@black.igk.intel.com>
Date: Tue, 3 Feb 2026 10:39:57 +0100
From: Mika Westerberg <mika.westerberg@...ux.intel.com>
To: Jayi Li <lijiayi@...inos.cn>
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,
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?
For TB3 there is no LTTSM state in that register so the value you read can
be anything.
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?
Powered by blists - more mailing lists