From: Ard Biesheuvel <ardb+git@google.com>
To: linux-pci@vger.kernel.org
Cc: linux-kernel@vger.kernel.org, "Ard Biesheuvel" <ardb@kernel.org>,
"Bjorn Helgaas" <bhelgaas@google.com>,
"Ilpo Järvinen" <ilpo.jarvinen@linux.intel.com>
Subject: [RFC PATCH] PCI: Tolerate non-prefetchable 64-bit BARs in prefetchable windows
Date: Thu, 10 Sep 2026 16:34:39 +0200 [thread overview]
Message-ID: <20260910143440.3865663-2-ardb+git@google.com> (raw)
From: Ard Biesheuvel <ardb@kernel.org>
The prefetchable vs. non-prefetchable distinction is a relic of
conventional PCI, to denote from which regions PCI-PCI bridges were
permitted to perform speculative readahead.
For software compatibility reasons, PCI Express inherited the Type 1
header and models PCIe root ports as PCI-PCI bridges. However, this
readahead behavior does not exist in PCIe, and so this distinction has
mostly become meaningless on the bridge level.
As per the PCIe r6.3 ECN "Removing Prefetchable Terminology", the
'prefetchable' designation has been removed from the specification
entirely, on the basis that it is obsolete, and is being abused to
inform memory mapping attributes and other device/BAR level properties
that it was never intended for.
Given the limited range for non-prefetchable windows in the Type 1
header, and the fact that the distinction no longer exists for PCIe,
resource allocation performed by firmware may result in non-prefetchable
64-bit BARs being allocated inside prefetchable bridge windows.
Linux rejects such allocations ("can't claim; no compatible bridge
window") when it encounters them, but will usually fail to produce an
alternative allocation, given that firmware wouldn't have placed them
there in the first place if there was sufficient space in the
non-prefetchable window.
So at the very least, let's not reject such allocations when they were
made by the firmware.
Cc: Bjorn Helgaas <bhelgaas@google.com>
Cc: "Ilpo Järvinen" <ilpo.jarvinen@linux.intel.com>
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
---
Link: https://github.com/tianocore/edk2/issues/13104
drivers/pci/pci.c | 3 ++-
include/linux/pci.h | 4 ++--
2 files changed, 4 insertions(+), 3 deletions(-)
diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
index b2879a6be5f8..e33eb9f3a139 100644
--- a/drivers/pci/pci.c
+++ b/drivers/pci/pci.c
@@ -761,7 +761,8 @@ struct resource *pci_find_parent_resource(const struct pci_dev *dev,
* not, the allocator made a mistake.
*/
if (r->flags & IORESOURCE_PREFETCH &&
- !(res->flags & IORESOURCE_PREFETCH))
+ !(res->flags & IORESOURCE_PREFETCH) &&
+ !pci_is_pcie(dev))
return NULL;
/*
diff --git a/include/linux/pci.h b/include/linux/pci.h
index d31a8d107b1e..1cbb4b6c02c3 100644
--- a/include/linux/pci.h
+++ b/include/linux/pci.h
@@ -2684,7 +2684,7 @@ static inline void pci_vf_drivers_autoprobe(struct pci_dev *dev, bool probe) { }
* need to calculate PCIe capability offset from raw device for some
* reasons, please use pci_find_capability() instead.
*/
-static inline int pci_pcie_cap(struct pci_dev *dev)
+static inline int pci_pcie_cap(const struct pci_dev *dev)
{
return dev->pcie_cap;
}
@@ -2695,7 +2695,7 @@ static inline int pci_pcie_cap(struct pci_dev *dev)
*
* Returns: true if the PCI device is PCI Express capable, false otherwise.
*/
-static inline bool pci_is_pcie(struct pci_dev *dev)
+static inline bool pci_is_pcie(const struct pci_dev *dev)
{
return pci_pcie_cap(dev);
}
--
2.55.0.1003.g10538fe699-goog
next reply other threads:[~2026-09-10 14:34 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-10 14:34 Ard Biesheuvel [this message]
2026-09-10 17:31 ` Ilpo Järvinen
2026-09-10 21:04 ` Ard Biesheuvel
2026-09-11 9:27 ` Ilpo Järvinen
2026-09-11 10:01 ` Ard Biesheuvel
2026-09-11 10:14 ` Lorenzo Pieralisi
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=20260910143440.3865663-2-ardb+git@google.com \
--to=ardb+git@google.com \
--cc=ardb@kernel.org \
--cc=bhelgaas@google.com \
--cc=ilpo.jarvinen@linux.intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
/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®