linux-kernel - Re: [PATCH] PCI: stm32: Fix LTSSM EP race with start link.

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] [day] [month] [year] [list]

Message-ID: <k72rxq2j5hbpotgmshwau6tvvem3jnldahxxgg54qoxjs7jaxb@bgh4cgs5j25h>
Date: Wed, 19 Nov 2025 21:17:18 +0530
From: Manivannan Sadhasivam <mani@...nel.org>
To: Christian Bruel <christian.bruel@...s.st.com>
Cc: Bjorn Helgaas <helgaas@...nel.org>, 
	Lorenzo Pieralisi <lpieralisi@...nel.org>, Krzysztof Wilczyński <kwilczynski@...nel.org>, 
	Rob Herring <robh@...nel.org>, Bjorn Helgaas <bhelgaas@...gle.com>, 
	Maxime Coquelin <mcoquelin.stm32@...il.com>, Alexandre Torgue <alexandre.torgue@...s.st.com>, 
	linux-pci@...r.kernel.org, linux-stm32@...md-mailman.stormreply.com, 
	linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org, Lukas Wunner <lukas@...ner.de>
Subject: Re: [PATCH] PCI: stm32: Fix LTSSM EP race with start link.

On Wed, Nov 19, 2025 at 04:13:47PM +0100, Christian Bruel wrote:
> 
> 
> On 11/18/25 22:28, Bjorn Helgaas wrote:
> > [+cc Lukas in case I got the pciehp part wrong]
> > 
> 
> > 
> > To back up here, I'm trying to understand the race.
> > 
> > IIUC the relevant events are link training and register init.  In the
> > current stm32 EP driver, link training can start when the EP userspace
> > writes to the 'start' configfs file.  And the register init happens
> > when stm32_pcie_ep_perst_irq_thread() calls
> > dw_pcie_ep_init_registers().
> > 
> > So I guess the problem is when the EP userspace enables the LTSSM
> > before the host deasserts PERST#?  And the link train may complete
> > before stm32_pcie_ep_perst_irq_thread() runs?
> 
> The sequence also violated the spec (4.0, Section 6.6.1 "Conventional
> Reset"), because it allowed the endpoint to enter the Detect state before
> PERST# is deasserted
> 
> > 
> > And the fix here is to delay enabling the EP LTSSM until after
> > stm32_pcie_perst_deassert() calls dw_pcie_ep_init_registers()?
> > 
> 
> > 
> > I think we would prefer if the host would enumerate the endpoint
> > whenever the endpoint becomes ready, even if that is after the host's
> > initial enumeration, but I guess that's only possible if the host is
> > notified when the link comes up.
> > 
> > The main mechanism for that is hotplug, i.e., pciehp handles presence
> > detect and link layer state changed events, both of which are managed
> > by the PCIe Slot register set.  Those registers are optional and may
> > not be implemented, e.g., if a Root Port is connected to a
> > system-integrated device.
> > 
> > But if they *are* implemented, I hope that pciehp makes it so no user
> > intervention on the host side is required.
> > 
> 
> 
> I suppose that hotplug cannot be implemented without some kind of presence
> detection signal from the EP (PRSNT#, ...) ? For now we have no
> implementation to support this (from gpio or other).
> 

Most of the non-PC/Server platforms do not have hot pluggable connectors. So the
lack of PRSNT# signal is very common.

> However, using a PC host, I observe that when I resume the host from PCIe
> autosuspend, for example, with 'lspci', PERST# is deasserted, and the stm32
> PCIe EP device is correctly enumerated without a manual rescan. So thanks to
> power management, a device can be enumerated asynchronously but when
> requested, not when ready.
> 

I would assume that any host will deassert PERST# during boot itself, and keep
the LTSSM in Link.Detect. But if the link is not detected, a host *may* assert
PERST#. And during resume, it will try the same sequence and if your device is
connected, it will get enumerated.

- Mani

-- 
மணிவண்ணன் சதாசிவம்