mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Lukas Wunner <lukas@wunner.de>
To: Rick Warner <rick@microway.com>
Cc: bhelgaas@google.com, ilpo.jarvinen@linux.intel.com,
	linux-pci@vger.kernel.org, linux-kernel@vger.kernel.org,
	rhoughton@microway.com, ssingh@microway.com
Subject: Re: [PATCH] PCI: Fix Intel Xeon 6 x2 quirk collateral damage on adjacent x4 endpoints
Date: Wed, 29 Jul 2026 20:43:29 +0200	[thread overview]
Message-ID: <ampJ0dIhz1J-a0sk@wunner.de> (raw)
In-Reply-To: <20260729144508.12337-1-rick@microway.com>

On Wed, Jul 29, 2026 at 10:45:08AM -0400, Rick Warner wrote:
> commit a22250fe933d ("PCI: Add Extended Tag + MRRS quirk for Xeon 6")
> introduced a traffic mitigation quirk for Intel Xeon 6 root ports that
> negotiate down to an x2 lane width. However, that patch manipulated host
> bridge properties globally via 'bridge->no_ext_tags = 1' and by hooking
> 'bridge->enable_device'.
> 
> Because multiple unrelated root ports can reside under the exact same
> global pci_host_bridge domain structure, this overly aggressive mitigation
> causes severe collateral damage. When a low-speed or bifurcated secondary
> device (such as an onboard ASMedia SATA controller or BMC graphics link)
> matches the x2 condition, the kernel strips away Extended Tags and forces
> a 128B MRRS restriction across that ENTIRE host bridge. This instantly
> breaks or starves adjacent high-performance, unrelated x4 endpoints
> (such as NVMe drives), resulting in controller timeouts, initialization
> failures, and missing drives at boot.
> 
> Fix this by refactoring the quirk logic to be completely per-device and
> downstream-isolated. Remove the broad host bridge structure assignments
> entirely. Instead, convert the hook to an explicit
> 'DECLARE_PCI_FIXUP_FINAL' sweep. When an x2 bifurcated root port is
> discovered, leverage 'pci_walk_bus()' to step down only that specific root
> port's subordinate tree, manually clearing 'PCI_EXP_DEVCTL_EXT_TAG' and
> 'PCI_EXP_DEVCTL_READRQ' directly in the endpoint Device Control
> configuration registers.

One problem I see with this approach is that it won't work for hotplugged
devices below a bifurcated Root Port:  You're only adjusting Extended Tags
and MRRS once on enumeration of the Root Ports, leaving devices that are
hotplugged later at incorrect settings.

But perhaps you could simply amend limit_mrrs_to_128() to walk up to the
Root Port, check whether it is bifurcated, and bail out if it's not?

Thanks,

Lukas

  reply	other threads:[~2026-07-29 18:43 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-07-29 14:45 Rick Warner
2026-07-29 18:43 ` Lukas Wunner [this message]
2026-08-04 13:55   ` Rick Warner
2026-08-04 17:10     ` Bjorn Helgaas

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=ampJ0dIhz1J-a0sk@wunner.de \
    --to=lukas@wunner.de \
    --cc=bhelgaas@google.com \
    --cc=ilpo.jarvinen@linux.intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=rhoughton@microway.com \
    --cc=rick@microway.com \
    --cc=ssingh@microway.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®