Re: [PCI/Thunderbolt] Intel Titan Ridge DD (8086:15ef): ACSViol on link-local LTR Msg (route 100b), possible ACS Source Validation false positive

[Mika Westerberg <westeri@kernel.org>]

Hi,

On Fri, Nov 13, 2026 at 08:45:43PM +0100, Lukas Wunner wrote:
> On Fri, Nov 13, 2026 at 03:18:46AM -0500, lionel margueritat wrote:
> > [1532.142389] AMD 00:03.1 pciehp Link Up
> > [1532.273384] Intel 06:00.0 bridge configuration invalid ([bus
> > 00-00]), reconfiguring
> > [1532.280...] Bus and BAR assignment completed for endpoints
> > [1532.282964] xhci_hcd 09:00.0: xHCI Host Controller
> > [1532.824413] Intel 07:01.0: Correctable Data Link Layer BadTLP [6]
> > (NVMe-side bridge)
> > [1533.779213] Intel 07:02.0: Uncorrectable (Non-Fatal), Transaction Layer
> > [1533.779233] Intel 07:02.0: [21] ACSViol (First)
> > [1533.779243] Intel 07:02.0: TLP Header 0x34000000 0x00000010
> > 0x00000000 0x00000000
> > [1533.790681] xhci_hcd 09:00.0: AER: can't recover (no error_detected callback)
> > [1533.790732] Intel 07:02.0: AER: device recovery failed
> [...]
> > The packet appears to be a link-local routing 100b Message TLP with
> > code 0x10 (LTR) and Requester ID 0000. PCI-SIG ECN of 15 April 2026,
> > 'Access Control Services (ACS) - Source Validation Clarification',
> > discusses false Source Validation errors for locally routed Msg TLPs
> > (100b, 110b, 111b):
> > https://pcisig.com/PCIExpress/ECN/Base/AccessControlServicesACSSourceValidationClarification
> [...]
> > 1. Is the LTR TLP with route 100b and Requester ID 0000 valid on this
> > downstream switch port, and should ACS Source Validation exempt it?
> 
> It's a valid TLP.  The ECN talks about *optionally* ignoring TLPs
> like this one when performing ACS Source Validation ("designers may
> disable Source Validation").
> 
> > 2. Is there a known Intel Titan Ridge DD JHL7540 NVM/silicon
> > limitation, or a device-specific signed firmware correction? ACASIS
> > support has been contacted.
> 
> I'm not aware of one, maybe Mika has more info.

I'm not aware either.

> > 3. Could an init-time software quirk or firmware correction handle
> > this without weakening device isolation?
> 
> CXL has a similar issue when performing a Secondary Bus Reset:
> The Endpoint sends a PM Init message upstream with a zero Requester ID
> and that triggers an ACS Source Validation.
> 
> Fabio used to work on this, he's no longer at Intel and the project
> is thus paused:
> 
> https://lore.kernel.org/all/20260825022628.3651434-1-fabio.m.de.francesco@linux.intel.com/
> 
> According to PCIe r7.1 sec 2.2.9.1:
> 
>    "Functions must capture the Bus and Device Numbers supplied with all
>     Type 0 Configuration Write Requests completed by the Function,
>     and supply these numbers in the Bus and Device Number fields of the
>     Completer ID for all Completions generated by the Device/Function.
>     If a Function must generate a Completion prior to the initial device
>     Configuration Write Request, 0's must be entered into the Bus Number
>     and Device Number fields."
> 
> So we need to perform one Config Space Write before the device sends any
> LTR message upstream.  The kernel sets PCI_EXP_DEVCTL2_LTR_EN in
> drivers/pci/pcie/aspm.c, but I would think that we perform a lot of
> Config Space Writes before that, so the device should know its bus and
> device/function number by the time PCI_EXP_DEVCTL2_LTR_EN is set.
> 
> Is PCI_EXP_DEVCTL2_LTR_EN set by default on this device?  That would indeed
> be a silicon bug because the default value is 0 for the bit per PCIe r7.1
> sec 7.5.3.16.  Or maybe the platform firmware sets the bit?

We had similar with PTM, namely Linux enabled PTM automatically for the
PCIe switch upstream port and that made the PTM messages of the
downstream ports (that were not yet even configured) starting to send
PTM messages. This triggered same ACS source violation. We fixed it
with:

  e1092d5e15e6 ("PCI/PTM: Do not enable PTM automatically for Root and Switch Upstream Ports")

Looking at pci_configre_ltr() we seem to enable it automatically for the
upstream ports.