From: Alex Elder <elder@riscstar.com>
To: bhelgaas@google.com
Cc: lizhi.hou@amd.com, herve.codina@bootlin.com,
andrea.porta@suse.com, daniel@riscstar.com,
mohdayaa@qti.qualcomm.com, lbiancon@qti.qualcomm.com,
mani@kernel.org, robh@kernel.org, linux-pci@vger.kernel.org,
linux-kernel@vger.kernel.org
Subject: [PATCH 2/2] PCI: of: introduce of_pci_update_endpoint_node_ranges()
Date: Thu, 13 Aug 2026 17:07:16 -0500 [thread overview]
Message-ID: <20260813220717.1394644-3-elder@riscstar.com> (raw)
In-Reply-To: <20260813220717.1394644-1-elder@riscstar.com>
Commit 407d1a51921e9 ("PCI: Create device tree node for bridge")
introduced the PCI_DYNAMIC_OF_NODES Kconfig option, which creates
a devicetree node for a PCI bridge as part of pci_bus_add_device().
Its successor commit ae9813db1dc5a ("PCI: Add quirks to generate
device tree node for Xilinx Alveo U50") shows how to use a PCI final
fixup quirk to also create a devicetree node for a non-bridge PCI
device. In both cases, of_pci_make_dev_node() uses an OF changeset
to dynamically create a node populated with appropriate properties
and apply it to the live devicetree.
The dynamic devicetree node for a PCI device will include a "ranges"
property, and a new type of 3-cell address is introduced for use
within an endpoint. The endpoint's ranges property will contain a
range entry for each of the endpoint's BARs. The "child address"
portion of each range will use the BAR number in the "flags" (first)
cell in the address. This allows addresses within the endpoint to
be expressed relative to whatever address gets assigned to each BAR.
Unfortunately, if a PCI endpoint device had a devicetree node set
up statically, its "ranges" property (if present) will be static,
and it cannot contain the addresses assigned to the endpoint's BARs
during enumeration.
This means that the "BAR number" based addressing scheme doesn't
work for PCI endpoints whose devicetree nodes are created statically.
To remedy this, modify of_pci_make_dev_node() to dynamically create
a "ranges" property just as is done when the endpoint has a null
devicetree node pointer. The device node will be updated to add
the new "ranges" property (or replace it if one exists).
This allows "BAR number" addresses to work correctly even when the
endpoint's devicetree node is created statically.
Signed-off-by: Alex Elder <elder@riscstar.com>
---
drivers/pci/of.c | 59 ++++++++++++++++++++++++++++++++++-----
drivers/pci/of_property.c | 2 +-
drivers/pci/pci.h | 1 +
3 files changed, 54 insertions(+), 8 deletions(-)
diff --git a/drivers/pci/of.c b/drivers/pci/of.c
index 0bbf1a915b7d2..ce14ae01d1f4b 100644
--- a/drivers/pci/of.c
+++ b/drivers/pci/of.c
@@ -663,20 +663,65 @@ void of_pci_remove_node(struct pci_dev *pdev)
of_node_put(np);
}
+/* Returns true if the ranges property was added or updated successfully */
+static bool of_pci_update_endpoint_node_ranges(struct pci_dev *pdev)
+{
+ struct device_node *np = pci_device_to_OF_node(pdev);
+ struct property *prop;
+ u32 *value;
+ u32 size;
+
+ prop = kzalloc_obj(*prop);
+ if (!prop)
+ return false;
+
+ value = of_pci_build_prop_ranges(pdev, &size);
+ if (!value) {
+ kfree(prop);
+ return false;
+ }
+
+ prop->name = "ranges";
+ prop->length = size * sizeof(u32);
+ prop->value = value;
+
+ /* The property value needs to be in big-endian byte order */
+ while (size--)
+ cpu_to_be32s(value++);
+
+ /* of_update_property() consumes the allocated property */
+ of_update_property(np, prop);
+
+ return true;
+}
+
void of_pci_make_dev_node(struct pci_dev *pdev)
{
struct device_node *ppnode, *np = NULL;
+ struct device *dev = &pdev->dev;
+ struct of_changeset *cset;
const char *pci_type;
- struct of_changeset *cset;
const char *name;
int ret;
- /*
- * If there is already a device tree node linked to this device,
- * return immediately.
- */
- if (pci_device_to_OF_node(pdev))
+ /* No need to create a new devicetree node if one already exists */
+ if (pci_device_to_OF_node(pdev)) {
+ if (pci_is_bridge(pdev))
+ return;
+
+ /*
+ * For an endpoint device, we need to add or update its
+ * devicetree "ranges" property. The new property will
+ * include an entry for every BAR, mapping BAR offsets
+ * to the actual assigned PCI bus address space for the
+ * endpoint. The child space in each range uses the flags
+ * cell of the child bus address to encode the BAR number.
+ */
+ if (!of_pci_update_endpoint_node_ranges(pdev))
+ dev_err(dev, "failed updating ranges property\n");
+
return;
+ }
/* Check if there is device tree node for parent device */
if (!pdev->bus->self)
@@ -715,7 +760,7 @@ void of_pci_make_dev_node(struct pci_dev *pdev)
np->data = cset;
- ret = device_add_of_node(&pdev->dev, np);
+ ret = device_add_of_node(dev, np);
if (ret)
goto out_revert_cset;
diff --git a/drivers/pci/of_property.c b/drivers/pci/of_property.c
index 48ce467e7e966..744dee0dd9625 100644
--- a/drivers/pci/of_property.c
+++ b/drivers/pci/of_property.c
@@ -116,7 +116,7 @@ static int of_pci_prop_bus_range(struct pci_dev *pdev,
*
* Caller is responsible for ensuring the returned pointer gets freed.
*/
-static u32 *of_pci_build_prop_ranges(struct pci_dev *pdev, u32 *count)
+u32 *of_pci_build_prop_ranges(struct pci_dev *pdev, u32 *count)
{
bool bridge_device = pci_is_bridge(pdev);
struct of_pci_range_entry *entries;
diff --git a/drivers/pci/pci.h b/drivers/pci/pci.h
index 2e1ccdd6f6418..6ae8adb30fdd0 100644
--- a/drivers/pci/pci.h
+++ b/drivers/pci/pci.h
@@ -1316,6 +1316,7 @@ struct of_changeset;
#ifdef CONFIG_PCI_DYNAMIC_OF_NODES
void of_pci_make_dev_node(struct pci_dev *pdev);
void of_pci_remove_node(struct pci_dev *pdev);
+u32 *of_pci_build_prop_ranges(struct pci_dev *pdev, u32 *count);
int of_pci_add_properties(struct pci_dev *pdev, struct of_changeset *ocs,
struct device_node *np);
void of_pci_make_host_bridge_node(struct pci_host_bridge *bridge);
--
2.53.0
prev parent reply other threads:[~2026-08-13 22:07 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-13 22:07 [PATCH 0/2] PCI: of: update endpoint ranges dynamically Alex Elder
2026-08-13 22:07 ` [PATCH 1/2] PCI: of: introduce of_pci_build_prop_ranges() Alex Elder
2026-08-13 22:07 ` Alex Elder [this message]
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=20260813220717.1394644-3-elder@riscstar.com \
--to=elder@riscstar.com \
--cc=andrea.porta@suse.com \
--cc=bhelgaas@google.com \
--cc=daniel@riscstar.com \
--cc=herve.codina@bootlin.com \
--cc=lbiancon@qti.qualcomm.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=lizhi.hou@amd.com \
--cc=mani@kernel.org \
--cc=mohdayaa@qti.qualcomm.com \
--cc=robh@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.