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

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

[Emmanuel Grumbach]

The Intel wireless BE200 device fails to copy the TLP Attributes from a
Request to the Completion.
Since there is no caching involved the device anyway, disable the
NoSnoop and Relaxed ordering on the root port.

Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
---
 drivers/pci/quirks.c | 7 +++++++
 1 file changed, 7 insertions(+)

diff --git a/drivers/pci/quirks.c b/drivers/pci/quirks.c
index c0242f3e9f06..e9f070d07b2c 100644
--- a/drivers/pci/quirks.c
+++ b/drivers/pci/quirks.c
@@ -4674,6 +4674,13 @@ static void quirk_chelsio_T5_disable_root_port_attributes(struct pci_dev *pdev)
 DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_CHELSIO, PCI_ANY_ID,
 			 quirk_chelsio_T5_disable_root_port_attributes);
 
+/*
+ * The Intel wireless BE200 fails to copy TLP Attributes from a Request to the
+ * Completion it generates.
+ */
+DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL, 0x272b,
+			 quirk_disable_root_port_attributes);
+
 /*
  * pci_acs_ctrl_enabled - compare desired ACS controls with those provided
  *			  by a device
-- 
2.54.0

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

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] Missing suspend/resume fixup hook for Intel BE200 PCIe erratum workaround
--

commit ebcdab6d68a92d23aa6cf1713e8e72d87f0e6279
Author: Emmanuel Grumbach <emmanuel.grumbach@intel.com>

PCI: Disable NoSnoop and Relaxed ordering for Intel wireless BE200

This commit disables NoSnoop and Relaxed ordering on the root port for the
Intel wireless BE200 device because it fails to copy TLP Attributes from a
Request to the Completion. 

> diff --git a/drivers/pci/quirks.c b/drivers/pci/quirks.c
> --- a/drivers/pci/quirks.c
> +++ b/drivers/pci/quirks.c
> @@ -4674,6 +4674,13 @@ static void quirk_chelsio_T5_disable_root_port_attributes(struct pci_dev *pdev)
>  DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_CHELSIO, PCI_ANY_ID,
>  			 quirk_chelsio_T5_disable_root_port_attributes);
>  
> +/*
> + * The Intel wireless BE200 fails to copy TLP Attributes from a Request to the
> + * Completion it generates.
> + */
> +DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL, 0x272b,
> +			 quirk_disable_root_port_attributes);

[Severity: High]
Will this workaround survive a system suspend and resume cycle?

When the Intel BE200 device is hotplugged, the upstream Root Port's
configuration state is saved at boot time by pcie_portdrv_probe(), which calls
pci_save_state(). The workaround modifies the Root Port's current
configuration to disable Relaxed Ordering and No Snoop, but it does not update
the Root Port's saved state array.

Upon system suspend, the PCI core skips saving the Root Port's state because
its state_saved flag is already true. During resume, pci_restore_state()
restores the Root Port to its original boot-time state, which would re-enable
the problematic attributes.

Should there also be a DECLARE_PCI_FIXUP_RESUME_EARLY hook registered here to
ensure the workaround is re-applied when the device resumes?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260621065451.21650-1-emmanuel.grumbach@intel.com?part=1

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

[Grumbach, Emmanuel]

On Sun, 2026-06-21 at 07:12 +0000, sashiko-bot@kernel.org wrote:
> Thank you for your contribution! Sashiko AI review found 1 potential
> issue(s) to consider:
> - [High] Missing suspend/resume fixup hook for Intel BE200 PCIe
> erratum workaround
> --
> 
> commit ebcdab6d68a92d23aa6cf1713e8e72d87f0e6279
> Author: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
> 
> PCI: Disable NoSnoop and Relaxed ordering for Intel wireless BE200
> 
> This commit disables NoSnoop and Relaxed ordering on the root port
> for the
> Intel wireless BE200 device because it fails to copy TLP Attributes
> from a
> Request to the Completion. 
> 
> > diff --git a/drivers/pci/quirks.c b/drivers/pci/quirks.c
> > --- a/drivers/pci/quirks.c
> > +++ b/drivers/pci/quirks.c
> > @@ -4674,6 +4674,13 @@ static void
> > quirk_chelsio_T5_disable_root_port_attributes(struct pci_dev *pdev)
> >  DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_CHELSIO, PCI_ANY_ID,
> >  			
> > quirk_chelsio_T5_disable_root_port_attributes);
> >  
> > +/*
> > + * The Intel wireless BE200 fails to copy TLP Attributes from a
> > Request to the
> > + * Completion it generates.
> > + */
> > +DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL, 0x272b,
> > +			 quirk_disable_root_port_attributes);
> 
> [Severity: High]
> Will this workaround survive a system suspend and resume cycle?
> 
> When the Intel BE200 device is hotplugged, the upstream Root Port's
> configuration state is saved at boot time by pcie_portdrv_probe(),
> which calls
> pci_save_state(). The workaround modifies the Root Port's current
> configuration to disable Relaxed Ordering and No Snoop, but it does
> not update
> the Root Port's saved state array.

That's a good point, but I'm not sure we really test well hotplug...

> 
> Upon system suspend, the PCI core skips saving the Root Port's state
> because
> its state_saved flag is already true. During resume,
> pci_restore_state()
> restores the Root Port to its original boot-time state, which would
> re-enable
> the problematic attributes.
> 
> Should there also be a DECLARE_PCI_FIXUP_RESUME_EARLY hook registered
> here to
> ensure the workaround is re-applied when the device resumes?

I'll have to check if suspend / resume cycles were part of the tests
being conducted.

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

[Lukas Wunner]

On Sun, Jun 21, 2026 at 09:54:51AM +0300, Emmanuel Grumbach wrote:
> The Intel wireless BE200 device fails to copy the TLP Attributes from a
> Request to the Completion.
> Since there is no caching involved the device anyway, disable the
> NoSnoop and Relaxed ordering on the root port.

Is there a public Specification Update which could be linked in the
commit message and/or code comment?

Thanks,

Lukas

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

[Grumbach, Emmanuel]

On Sun, 2026-06-21 at 10:10 +0200, Lukas Wunner wrote:
> On Sun, Jun 21, 2026 at 09:54:51AM +0300, Emmanuel Grumbach wrote:
> > The Intel wireless BE200 device fails to copy the TLP Attributes
> > from a
> > Request to the Completion.
> > Since there is no caching involved the device anyway, disable the
> > NoSnoop and Relaxed ordering on the root port.
> 
> Is there a public Specification Update which could be linked in the
> commit message and/or code comment?
> 
> 

Not really.
We just have tested our device with Jetson Thor and saw that it doesn't
work. Happens that the PCI controller on Jetson Thor is doing things
that very few PCI controllers do and this undercovered this bad
behavior on the BE200 side.

We don't have a more formal publication about this issue.


> Thanks,
> 
> Lukas

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

[Grumbach, Emmanuel]

On Sun, 2026-06-21 at 10:10 +0200, Lukas Wunner wrote:
> On Sun, Jun 21, 2026 at 09:54:51AM +0300, Emmanuel Grumbach wrote:
> > The Intel wireless BE200 device fails to copy the TLP Attributes
> > from a
> > Request to the Completion.
> > Since there is no caching involved the device anyway, disable the
> > NoSnoop and Relaxed ordering on the root port.
> 
> Is there a public Specification Update which could be linked in the
> commit message and/or code comment?
> 

I replied to this already. Anything needed from my side?
We'd like to allow those users to work with BE200.

Not pushing or anything, just making sure you're not waiting for me.

Thanks you!

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

[Lukas Wunner]

On Wed, Jul 22, 2026 at 11:01:40AM +0000, Grumbach, Emmanuel wrote:
> On Sun, 2026-06-21 at 10:10 +0200, Lukas Wunner wrote:
> > On Sun, Jun 21, 2026 at 09:54:51AM +0300, Emmanuel Grumbach wrote:
> > > The Intel wireless BE200 device fails to copy the TLP Attributes
> > > from a
> > > Request to the Completion.
> > > Since there is no caching involved the device anyway, disable the
> > > NoSnoop and Relaxed ordering on the root port.
> > 
> > Is there a public Specification Update which could be linked in the
> > commit message and/or code comment?
> 
> I replied to this already. Anything needed from my side?
> We'd like to allow those users to work with BE200.
> 
> Not pushing or anything, just making sure you're not waiting for me.

I guess you need an Acked-by from Bjorn, or have the patch applied
to pci.git.  I can't do either I'm afraid, but if it helps:

Reviewed-by: Lukas Wunner <lukas@wunner.de>

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

[Bjorn Helgaas]

On Sun, Jun 21, 2026 at 07:30:25AM +0000, Grumbach, Emmanuel wrote:
> On Sun, 2026-06-21 at 07:12 +0000, sashiko-bot@kernel.org wrote:
> > Thank you for your contribution! Sashiko AI review found 1 potential
> > issue(s) to consider:
> > - [High] Missing suspend/resume fixup hook for Intel BE200 PCIe
> > erratum workaround
> > --
> > 
> > commit ebcdab6d68a92d23aa6cf1713e8e72d87f0e6279
> > Author: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
> > 
> > PCI: Disable NoSnoop and Relaxed ordering for Intel wireless BE200
> > 
> > This commit disables NoSnoop and Relaxed ordering on the root port
> > for the
> > Intel wireless BE200 device because it fails to copy TLP Attributes
> > from a
> > Request to the Completion. 
> > 
> > > diff --git a/drivers/pci/quirks.c b/drivers/pci/quirks.c
> > > --- a/drivers/pci/quirks.c
> > > +++ b/drivers/pci/quirks.c
> > > @@ -4674,6 +4674,13 @@ static void
> > > quirk_chelsio_T5_disable_root_port_attributes(struct pci_dev *pdev)
> > >  DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_CHELSIO, PCI_ANY_ID,
> > >  			
> > > quirk_chelsio_T5_disable_root_port_attributes);
> > >  
> > > +/*
> > > + * The Intel wireless BE200 fails to copy TLP Attributes from a
> > > Request to the
> > > + * Completion it generates.
> > > + */
> > > +DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL, 0x272b,
> > > +			 quirk_disable_root_port_attributes);
> > 
> > [Severity: High]
> > Will this workaround survive a system suspend and resume cycle?
> > 
> > When the Intel BE200 device is hotplugged, the upstream Root Port's
> > configuration state is saved at boot time by pcie_portdrv_probe(),
> > which calls pci_save_state(). The workaround modifies the Root Port's
> > current configuration to disable Relaxed Ordering and No Snoop, but it
> > does not update the Root Port's saved state array.
> 
> That's a good point, but I'm not sure we really test well hotplug...

It looks like BE200 is normally an M.2 form factor, and I don't think
M.2 is designed to support hotplug.  I guess it could be done with an
M.2-to-PCIe adapter, but that seems a bit esoteric.

> > Upon system suspend, the PCI core skips saving the Root Port's state
> > because its state_saved flag is already true. During resume,
> > pci_restore_state() restores the Root Port to its original boot-time
> > state, which would re-enable the problematic attributes.
> > 
> > Should there also be a DECLARE_PCI_FIXUP_RESUME_EARLY hook registered
> > here to ensure the workaround is re-applied when the device resumes?

I'm pretty sure the header quirks would be run before portdrv probes, so I
guess this is part of the same theoretical scenario, where portdrv probes
before a BE200 is hot-added.

Can we include any relevant dmesg output, e.g., AER errors or whatever
motivated this quirk in the first place?

c56d4450eb68 ("PCI: Turn off Request Attributes to avoid Chelsio T5
Completion erratum") mentions Malformed TLP or Unexpected Completion
errors, so I suppose this is similar?

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

[Grumbach, Emmanuel]

Hi Bjorn,

long time :)

On Wed, 2026-07-22 at 09:56 -0500, Bjorn Helgaas wrote:
> On Sun, Jun 21, 2026 at 07:30:25AM +0000, Grumbach, Emmanuel wrote:
> > On Sun, 2026-06-21 at 07:12 +0000, sashiko-bot@kernel.org wrote:
> > > Thank you for your contribution! Sashiko AI review found 1
> > > potential
> > > issue(s) to consider:
> > > - [High] Missing suspend/resume fixup hook for Intel BE200 PCIe
> > > erratum workaround
> > > --
> > > 
> > > commit ebcdab6d68a92d23aa6cf1713e8e72d87f0e6279
> > > Author: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
> > > 
> > > PCI: Disable NoSnoop and Relaxed ordering for Intel wireless
> > > BE200
> > > 
> > > This commit disables NoSnoop and Relaxed ordering on the root
> > > port
> > > for the
> > > Intel wireless BE200 device because it fails to copy TLP
> > > Attributes
> > > from a
> > > Request to the Completion. 
> > > 
> > > > diff --git a/drivers/pci/quirks.c b/drivers/pci/quirks.c
> > > > --- a/drivers/pci/quirks.c
> > > > +++ b/drivers/pci/quirks.c
> > > > @@ -4674,6 +4674,13 @@ static void
> > > > quirk_chelsio_T5_disable_root_port_attributes(struct pci_dev
> > > > *pdev)
> > > >  DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_CHELSIO, PCI_ANY_ID,
> > > >  			
> > > > quirk_chelsio_T5_disable_root_port_attributes);
> > > >  
> > > > +/*
> > > > + * The Intel wireless BE200 fails to copy TLP Attributes from
> > > > a
> > > > Request to the
> > > > + * Completion it generates.
> > > > + */
> > > > +DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL, 0x272b,
> > > > +			 quirk_disable_root_port_attributes);
> > > 
> > > [Severity: High]
> > > Will this workaround survive a system suspend and resume cycle?
> > > 
> > > When the Intel BE200 device is hotplugged, the upstream Root
> > > Port's
> > > configuration state is saved at boot time by
> > > pcie_portdrv_probe(),
> > > which calls pci_save_state(). The workaround modifies the Root
> > > Port's
> > > current configuration to disable Relaxed Ordering and No Snoop,
> > > but it
> > > does not update the Root Port's saved state array.
> > 
> > That's a good point, but I'm not sure we really test well
> > hotplug...
> 
> It looks like BE200 is normally an M.2 form factor, and I don't think
> M.2 is designed to support hotplug.  I guess it could be done with an
> M.2-to-PCIe adapter, but that seems a bit esoteric.

Indeed. BE200 is an M.2 form factor.

> 
> > > Upon system suspend, the PCI core skips saving the Root Port's
> > > state
> > > because its state_saved flag is already true. During resume,
> > > pci_restore_state() restores the Root Port to its original boot-
> > > time
> > > state, which would re-enable the problematic attributes.
> > > 
> > > Should there also be a DECLARE_PCI_FIXUP_RESUME_EARLY hook
> > > registered
> > > here to ensure the workaround is re-applied when the device
> > > resumes?
> 
> I'm pretty sure the header quirks would be run before portdrv probes,
> so I
> guess this is part of the same theoretical scenario, where portdrv
> probes
> before a BE200 is hot-added.
> 
> Can we include any relevant dmesg output, e.g., AER errors or
> whatever
> motivated this quirk in the first place?

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.

> 
> c56d4450eb68 ("PCI: Turn off Request Attributes to avoid Chelsio T5
> Completion erratum") mentions Malformed TLP or Unexpected Completion
> errors, so I suppose this is similar?

Precisely.

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

[Bjorn Helgaas]

[+to Thierry, Manikanta for Tegra264 questions; beginning of thread:
https://lore.kernel.org/all/20260621065451.21650-1-emmanuel.grumbach@intel.com,
+cc Miri, Lukas]

On Wed, Jul 22, 2026 at 03:14:47PM +0000, Grumbach, Emmanuel wrote:
> On Wed, 2026-07-22 at 09:56 -0500, Bjorn Helgaas wrote:
> > On Sun, Jun 21, 2026 at 07:30:25AM +0000, Grumbach, Emmanuel wrote:
> > > On Sun, 2026-06-21 at 07:12 +0000, sashiko-bot@kernel.org wrote:
> > > > Thank you for your contribution! Sashiko AI review found 1
> > > > potential
> > > > issue(s) to consider:
> > > > - [High] Missing suspend/resume fixup hook for Intel BE200 PCIe
> > > > erratum workaround
> > > > --
> > > > 
> > > > commit ebcdab6d68a92d23aa6cf1713e8e72d87f0e6279
> > > > Author: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
> > > > 
> > > > PCI: Disable NoSnoop and Relaxed ordering for Intel wireless
> > > > BE200
> > > > 
> > > > This commit disables NoSnoop and Relaxed ordering on the root
> > > > port for the Intel wireless BE200 device because it fails to
> > > > copy TLP Attributes from a Request to the Completion. 
> > > > 
> > > > > diff --git a/drivers/pci/quirks.c b/drivers/pci/quirks.c
> > > > > --- a/drivers/pci/quirks.c
> > > > > +++ b/drivers/pci/quirks.c
> > > > > @@ -4674,6 +4674,13 @@ static void
> > > > > quirk_chelsio_T5_disable_root_port_attributes(struct pci_dev
> > > > > *pdev)
> > > > >  DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_CHELSIO, PCI_ANY_ID,
> > > > >  			
> > > > > quirk_chelsio_T5_disable_root_port_attributes);
> > > > >  
> > > > > +/*
> > > > > + * The Intel wireless BE200 fails to copy TLP Attributes from
> > > > > a
> > > > > Request to the
> > > > > + * Completion it generates.
> > > > > + */
> > > > > +DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL, 0x272b,
> > > > > +			 quirk_disable_root_port_attributes);
> > > > 
> > > > [Severity: High]
> > > > Will this workaround survive a system suspend and resume cycle?
> > > > 
> > > > When the Intel BE200 device is hotplugged, the upstream Root
> > > > Port's configuration state is saved at boot time by
> > > > pcie_portdrv_probe(), which calls pci_save_state(). The
> > > > workaround modifies the Root Port's current configuration to
> > > > disable Relaxed Ordering and No Snoop, but it does not update
> > > > the Root Port's saved state array.
> > > 
> > > That's a good point, but I'm not sure we really test well
> > > hotplug...
> > 
> > It looks like BE200 is normally an M.2 form factor, and I don't
> > think M.2 is designed to support hotplug.  I guess it could be
> > done with an M.2-to-PCIe adapter, but that seems a bit esoteric.
> 
> Indeed. BE200 is an M.2 form factor.
> 
> > > > Upon system suspend, the PCI core skips saving the Root Port's
> > > > state because its state_saved flag is already true. During
> > > > resume, pci_restore_state() restores the Root Port to its
> > > > original boot- time state, which would re-enable the
> > > > problematic attributes.
> > > > 
> > > > Should there also be a DECLARE_PCI_FIXUP_RESUME_EARLY hook
> > > > registered here to ensure the workaround is re-applied when
> > > > the device resumes?
> > 
> > I'm pretty sure the header quirks would be run before portdrv
> > probes, so I guess this is part of the same theoretical scenario,
> > where portdrv probes before a BE200 is hot-added.
> > 
> > Can we include any relevant dmesg output, e.g., AER errors or
> > whatever motivated this quirk in the first place?
> 
> 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/

> > c56d4450eb68 ("PCI: Turn off Request Attributes to avoid Chelsio
> > T5 Completion erratum") mentions Malformed TLP or Unexpected
> > Completion errors, so I suppose this is similar?
> 
> Precisely.

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

[Lukas Wunner]

On Sun, Jun 21, 2026 at 07:12:42AM +0000, sashiko-bot@kernel.org wrote:
> > +++ b/drivers/pci/quirks.c
> > @@ -4674,6 +4674,13 @@ static void quirk_chelsio_T5_disable_root_port_attributes(struct pci_dev *pdev)
> >  DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_CHELSIO, PCI_ANY_ID,
> >  			 quirk_chelsio_T5_disable_root_port_attributes);
> >  
> > +/*
> > + * The Intel wireless BE200 fails to copy TLP Attributes from a Request to the
> > + * Completion it generates.
> > + */
> > +DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL, 0x272b,
> > +			 quirk_disable_root_port_attributes);
> 
> [Severity: High]
> Will this workaround survive a system suspend and resume cycle?
> 
> When the Intel BE200 device is hotplugged, the upstream Root Port's
> configuration state is saved at boot time by pcie_portdrv_probe(), which calls
> pci_save_state(). The workaround modifies the Root Port's current
> configuration to disable Relaxed Ordering and No Snoop, but it does not update
> the Root Port's saved state array.
> 
> Upon system suspend, the PCI core skips saving the Root Port's state because
> its state_saved flag is already true. During resume, pci_restore_state()
> restores the Root Port to its original boot-time state, which would re-enable
> the problematic attributes.

Hallucination.  pci_pm_suspend() resets the state_saved flag to false.

Usage of the state_saved flag was recently changed by 894f475f88e0 and
a2f1e22390ac.  Perhaps the LLM used by sashiko was trained with an older
version of the kernel source tree and is thus oblivious to those changes.

> Should there also be a DECLARE_PCI_FIXUP_RESUME_EARLY hook registered here to
> ensure the workaround is re-applied when the device resumes?

No.

Thanks,

Lukas

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

[Manikanta Maddireddy]

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.

Thanks,
Manikanta
-- 
nvpublic

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

[Grumbach, Emmanuel]

[-- Attachment #1: Type: text/plain, Size: 3968 bytes --]

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?

> 
> Thanks,
> Manikanta

[-- Attachment #2: thor_dmsg.txt.gz --]
[-- Type: application/gzip, Size: 24172 bytes --]