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: <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

Powered by Openwall GNU/*/Linux Powered by OpenVZ