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

[Lukas Wunner <lukas@wunner.de>]

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.

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

Thanks,

Lukas