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

[Manikanta Maddireddy <mmaddireddy@nvidia.com>]

On 23/07/26 5:05 pm, 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?  \\ **
> [   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?
> 

Yes, this is completion with data TLP. It matches with the 
quirk_disable_root_port_attributes().
>>
>> Thanks,
>> Manikanta

-- 
nvpublic