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

On Thu, 2026-07-30 at 15:08 -0500, Bjorn Helgaas wrote:
> On Thu, Jul 30, 2026 at 06:45:29PM +0000, Grumbach, Emmanuel wrote:
> > On Thu, 2026-07-30 at 12:28 -0500, Bjorn Helgaas wrote:
> > > On Thu, Jul 30, 2026 at 10:21:06AM +0530, Manikanta Maddireddy
> > > wrote:
> > > > On 29/07/26 12:19 pm, Grumbach, Emmanuel wrote:
> > > > > On Tue, 2026-07-28 at 15:18 -0500, Bjorn Helgaas wrote:
> > > > > > On Tue, Jul 28, 2026 at 07:47:04PM +0000, Grumbach,
> > > > > > Emmanuel
> > > > > > wrote:
> > > > > > > On Tue, 2026-07-28 at 14:24 -0500, Bjorn Helgaas wrote:
> > > > > > > > On Tue, Jul 28, 2026 at 06:21:23PM +0000, Grumbach,
> > > > > > > > Emmanuel
> > > > > > > > wrote:
> > > > > > > > > On Tue, 2026-07-28 at 13:03 -0500, Bjorn Helgaas
> > > > > > > > > wrote:
> > > > > > > > > ...
> > > > > > > > 
> > > > > > > > > > AFAICS we still don't know why Tegra264 would set
> > > > > > > > > > NoSnoop and/or RlxdOrd in the MMIO read.
> > > > > > > > > 
> > > > > > > > > Me neither but... I can't comment on that. And de-
> > > > > > > > > facto,
> > > > > > > > > once it does that, the BE200 replies with the NoSnoop
> > > > > > > > > and
> > > > > > > > > RlxOrd clear in the TLP which is then considered as a
> > > > > > > > > malformed TLP.
> > > > > > > > > 
> > > > > > > > > > Unless iwlwifi asked for NoSnoop and/or RlxdOrd to
> > > > > > > > > > be
> > > > > > > > > > set, I think it's a potential problem for drivers
> > > > > > > > > > if
> > > > > > > > > > Tegra264 sets them.
> > > > > > > > > 
> > > > > > > > > I ... don't think we would do that. The driver would
> > > > > > > > > certainly not do that... Regarding the hardware
> > > > > > > > > itself, I
> > > > > > > > > can't comment, but I can check internally.
> > > > > > > > 
> > > > > > > > Forgot to ask, can you collect the output of "sudo
> > > > > > > > lspci
> > > > > > > > -vv", at least for the RP and the BE200?
> > > > > > > > 
> > > > > > > > And maybe the dmesg log when booted with
> > > > > > > > "log_buf_len=16M
> > > > > > > > pci=earlydump" as well, so we can see if attributes
> > > > > > > > were
> > > > > > > > enabled by a bootloader?
> > > > > > > 
> > > > > > > I assume you want all this without the quirk, right?
> > > > > > 
> > > > > > Right.
> > > > > 
> > > > > Attached.
> > > > > Note that we used an out-of-tree driver in those attempts so
> > > > > the
> > > > > kernel is tainted, but this does not impact the issue we're
> > > > > discussing here.
> > > > 
> > > > PCI_EXP_DEVCTL_RELAX_EN and PCI_EXP_DEVCTL_NOSNOOP_EN are set
> > > > by HW
> > > > default value, this is inline with PCIe spec. It says "the
> > > > default
> > > > value of this bit is 1b" in both cases.
> > > 
> > > Huh, you're right.  I was assuming 0b was the default, but indeed
> > > 1b
> > > is the default unless they're hardwired to 0.  And they're both
> > > set
> > > to
> > > 1b on my x86 (AMD) Root Ports as well.  
> > 
> > Not on my Intel Root port:
> > 
> > 00:1d.0 PCI bridge: Intel Corporation Alder Lake PCI Express Root
> > Port 
> > 
> > <Snip>
> > 
> >         Capabilities: [40] Express (v2) Root Port (Slot+),
> > IntMsgNum 0
> >                 DevCap: MaxPayload 256 bytes, PhantFunc 0
> >                         ExtTag- RBE+ TEE-IO-
> >                 DevCtl: CorrErr- NonFatalErr- FatalErr- UnsupReq-
> >                         RlxdOrd- ExtTag- PhantFunc- AuxPwr-
> > NoSnoop-
> >                         MaxPayload 128 bytes, MaxReadReq 128 bytes
> 
> Super interesting.

Every one and his own areas of interest ;)

> 
> I guess Alder Lake isn't one of the RPs affected by
> quirk_relaxedordering_disable()?  I think 87e09cdec4da ("PCI: Disable
> Relaxed Ordering for some Intel processors") added all the existing
> uses of that quirk for Intel RPs, and the commit log only mentions
> Broadwell and Haswell.

Well... that commit is from 2017. Alder lake was shipped in 2021.

> 
> I wonder if the PCI core should disable RO and NoSnoop on Root Ports
> across the board?
> 
> I think this would mainly affect MMIO accesses performed by drivers,
> and I suspect drivers expect those writes to be performed in order,
> e.g., if the driver writes DMA descriptors to the device followed by
> a
> write to a doorbell, those should stay in order.  If the RP has RO
> enabled, those writes may be reordered.

As a device writer I'd say we'd be required to add a memory barrier in
that case, but we use writel usually.
Does that include a write vs write ordering? Hm...

> 
> > > So I would think we'd see this Malformed TLP error on pretty much
> > > every system with BE200 in it.
> > 
> > I guess that BE200 is almost only plugged into Intel systems which
> > is
> > why this bug went unnoticed until now..