Re: [PATCH] PCI: Disable NoSnoop and Relaxed ordering for Intel wireless BE200

[Bjorn Helgaas <helgaas@kernel.org>]

On Thu, Jul 23, 2026 at 11:35:41AM +0000, Grumbach, Emmanuel wrote:
> On Thu, 2026-07-23 at 15:19 +0530, Manikanta Maddireddy wrote:
> > On 22/07/26 10:34 pm, Bjorn Helgaas wrote:
> > > > The problem was that we didn't show up at all in the enumeration.
> > > > We
> > > > send a malformed TLP. I'm not quite an expert at this, but our
> > > > PCIe
> > > > experts run a PCI analyzer on the enumeration on that specific
> > > > platform and they saw that platform's PCI controller sets the
> > > > NoSnoop and Relaxed ordering bit in the TLP. According to the
> > > > spec
> > > > (which I ignore), the BE200 is supposed to return the TLP as
> > > > received, but we reply with 0 Attributes and the enumeration
> > > > doesn't
> > > > complete successfully.
> > > I'm curious about the details of this enumeration failure.  Do you
> > > know which TLPs had No Snoop and Relaxed Ordering set?  Per the
> > > PCIe
> > > spec, they shouldn't be set for the config requests used for PCI
> > > core
> > > enumeration.
> > > 
> > > At least*some* config reads to the BE200 must work; otherwise, we
> > > wouldn't know the Vendor or Device ID, which we need to apply the
> > > quirk.  So I think you should see something like this in dmesg, and
> > > BE200 would probably appear in lspci output:
> > > 
> > >    pci 0000:04:00.0: [8086:272b] type 00 class ...
> > > 
> > > Is the failure that iwl_pci_probe() itself fails somehow?
> > > 
> > > You mentioned that this happens on Jetson Thor, but I'm not sure
> > > what PCIe controller that is.  My guess is it might be Tegra264
> > > [1], which doesn't look like it's merged yet.
> > > 
> > > Thierry, Manikanta, do you have any insight into this?  Does
> > > this PCIe controller set No Snoop and Relaxed Ordering for some
> > > reason?  I don't think endpoint drivers are expecting that.
> > > 
> > > [1]https://lore.kernel.org/linux-pci/20260716-tegra264-pcie- 
> > > v8-0-23e51589229b@nvidia.com/
> > 
> > Hi,
> > 
> > Jetson Thor(Tegra264) is not setting NoSnoop and RlxdOrd bits in
> > config 
> > read TLP.
> > 
> > I made sure that both these bits are set in RP's DevCtl
> > 
> >                  DevCtl: CorrErr+ NonFatalErr+ FatalErr+ UnsupReq+
> >                          RlxdOrd+ ExtTag+ PhantFunc- AuxPwr- NoSnoop+
> > 
> > and dumped TLP header for a config read towards BDF 0x100 with offset
> > 0x24.
> >     0x04000001      0x0000000f      0x01000024      0x00000000
> > 
> > I think dmesg and AER log with header information might help with
> > this 
> > particular issue.
> 
> Ok, so I checked again the logs and I was wrong.
> We do see the device in the enumeration, it does show up in lspci.
> Problems start when we want to access our registers.
> I attached the full dmesg output. In that log we try to load iwlwifi
> twice.
> 
> I'm adding here the snippet of the first load:
> 
> [   15.275887] iwlwifi 0001:01:00.0: Adding to iommu group 53
> [   15.279737] iwlwifi 0001:01:00.0: enabling device (0100 -> 0102)
> [   15.280047] iwlwifi 0001:01:00.0: HW_REV=0xFFFFFFFF, PCI issues?  \\ **

The "enabling device" message is from pci_enable_resources(), called
in the pci_enable_device() path.  The 0100 is from a config read of
PCI_COMMAND, and the 0102 is from adding PCI_COMMAND_MEMORY to enable
memory BARs.

The "HW_REV=" is from iwl_pci_probe(), which looks like the very first
MMIO read to a BE200 BAR.

So I guess the theory is that Tegra264 set NoSnoop and/or RlxdOrd in
the MMIO read, BE200 didn't copy the attributes from the Request to
the Completion as required by PCIe r7.0, sec 2.2.9.1, and Tegra264
logged a Malformed TLP?

AFAICS we still don't know why Tegra264 would set NoSnoop and/or
RlxdOrd in the MMIO read.

Unless iwlwifi asked for NoSnoop and/or RlxdOrd to be set, I think
it's a potential problem for drivers if Tegra264 sets them.

> [   15.280070] iwlwifi: probe of 0001:01:00.0 failed with error -5  \\ **
> [   15.280087] pcieport 0001:00:00.0: AER: Correctable error message received from 0001:00:00.0
> [   15.280104] pcieport 0001:00:00.0: DPC: containment event, status:0x3f01 source:0x0000
> [   15.280110] pcieport 0001:00:00.0: DPC: unmasked uncorrectable error detected
> [   15.280127] pcieport 0001:00:00.0: AER: found no error details for 0001:00:00.0
> [   15.280154] pcieport 0001:00:00.0: PCIe Bus Error: severity=Uncorrectable (Fatal), type=Transaction Layer, (Receiver ID)
> [   15.280157] pcieport 0001:00:00.0:   device [10de:22d8] error status/mask=00040000/04400000
> [   15.280160] pcieport 0001:00:00.0:    [18] MalfTLP                (First)
> [   15.280163] pcieport 0001:00:00.0: AER:   TLP Header: 4a008001 01000004 00000028 72040000
> [   15.280274] pci 0001:01:00.0: AER: can't recover (no error_detected callback)
> 
> Does that help?
> 
> > 
> > Thanks,
> > Manikanta