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

On Tue, 2026-08-04 at 12:39 -0500, Bjorn Helgaas wrote:
> On Tue, Aug 04, 2026 at 03:57:51PM +0000, Grumbach, Emmanuel wrote:
> > On Fri, 2026-07-31 at 10:24 -0500, Bjorn Helgaas wrote:
> > > On Thu, Jul 30, 2026 at 08:16:33PM +0000, Grumbach, Emmanuel
> > > wrote:
> > > > On Thu, 2026-07-30 at 15:08 -0500, Bjorn Helgaas wrote:
> > > > ...
> > > 
> > > > > 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...
> > > 
> > > Not being an ordering expert, I'm not sure I can make a
> > > convincing
> > > argument for whether RO should be enabled or disabled for Root
> > > Ports.
> > > 
> > > Maybe it's easier to argue that whatever the RO setting is, it
> > > should be the same across all platforms because drivers shouldn't
> > > have to adapt to platform differences.
> > 
> > That's playing safe, which is never a bad option if the performance
> > hit is not significant, but I can't tell I can claim that have any
> > expertise here.
> 
> I'm not a PCIe protocol expert, but it's hard for me to see how No
> Snoop would be useful for outbound transactions initiated by the Root
> Port.
> 
> For inbound DMA transactions without No Snoop, the RC can enforce
> cache coherency by snooping CPU caches before accessing main memory.
> If a driver knows that the main memory target is uncached or doesn't
> need coherency, it can set No Snoop on its device to bypass the CPU
> cache snoop.
> 
> But for outbound reads or writes from the RP, the completer is the
> PCIe device that claims the transaction address, and I don't think
> any
> other device or switch is able to snoop caches and affect the
> response.
> 
> I suspect there *is* potential benefit for Relaxed Ordering on
> outbound transactions, but I think drivers would need to be aware of
> this.  Maybe the Linux driver model already comprehends this, and we
> should enable RO on RPs.  Either way, I think we should configure RO
> explicitly so drivers know what to expect and the behavior doesn't
> depend on whatever firmware did.

I don't know what your decision will be in the end and I understand
that the decision about the quirk is related.
For now, I'll tell the people who want to use BE200 on Jetson to use it
but it'd be nice to allow them to use a vanilla kernel.

> 
> > > Root Port settings potentially affect several endpoints, and I
> > > think it would be impractical for drivers to request RO settings
> > > that might conflict with each other.
> > > 
> > > Do you have any visibility into whether and how other OSes
> > > actively configure Root Port RO and NoSnoop across the board,
> > > independent of individual drivers?
> > 
> > I asked internally and we don't really know what Windows does when
> > the PCI root port has those bits sets. We mostly test with Intel /
> > AMD systems and those systems have those bits clear.
> > 
> > BTW - can you please point to the relevant paragraph in the PCI
> > spec
> > that states RelaxedOrder and NoSnoop should be set by default on
> > the
> > RP?
> 
> This is in PCIe r7.0, sec 7.5.3.4:
> 
>   Enable Relaxed Ordering - If this bit is Set, the Function is
>   permitted to set the Relaxed Ordering bit in the Attributes field
> of
>   transactions it initiates that do not require strong write ordering
>   (see § Section 2.2.6.4 and § Section 2.4).
> 
>   A Function is permitted to hardwire this bit to 0b if it never sets
>   the Relaxed Ordering attribute in transactions it initiates as a
>   Requester.
> 
>   When not hardwired to 0b, the default value of this bit is 1b.
> 
> 
>   Enable No Snoop - If this bit is Set, the Function is permitted to
>   Set the No Snoop bit in the Requester Attributes of transactions it
>   initiates that do not require hardware enforced cache coherency
> (see
>   § Section 2.2.6.5). Note that setting this bit to 1b should not
>   cause a Function to Set the No Snoop attribute on all transactions
>   that it initiates. Even when this bit is Set, a Function is only
>   permitted to Set the No Snoop attribute on a transaction when it
> can
>   guarantee that the address of the transaction is not stored in any
>   cache in the system.
> 
>   This bit is permitted to be hardwired to 0b if a Function would
>   never Set the No Snoop attribute in transactions it initiates.
> 
>   Default value of this bit is 1b.

Thank you.