From: Andrea della Porta <andrea.porta@suse.com>
To: Alex Elder <elder@riscstar.com>
Cc: bhelgaas@google.com, 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: Re: [PATCH v3 0/3] PCI: of: update endpoint ranges dynamically
Date: Thu, 8 Oct 2026 17:45:58 +0200 [thread overview]
Message-ID: <ase6toUhGn0XD0v9@apocalypse> (raw)
In-Reply-To: <20260924222444.1351466-1-elder@riscstar.com>
Hi Alex,
On 17:24 Thu 24 Sep , Alex Elder wrote:
> A PCI endpoint bus is a devicetree construct that allows a PCI
> endpoint (function) to have sub-devices defined that are accessible
> in an SoC via the PCI endpoint's BARs. Such a bus is represented as
> a devicetree sub-node for a PCI function having the name "pci-ep-bus".
> There can be one or more pci-ep-bus nodes.
>
> A PCI function with a pci-ep-bus devicetree node must also define
> "#address-cells", "#size-cells", and "ranges" properties, to specify
> how endpoint bus addresses are translated to the PCI parent bus.
>
> An endpoint bus address has three cells; the first indicates which of
> the function's BARs the address is associated with, and the other two
> specify a 64-bit (2 cell) offset within the BAR's region.
>
> BAR base addresses are determined dynamically by the PCI enumeration
> process, so generally it's not possible to include them in a static
> devicetree file. When this addressing scheme was introduced, this
> was not a problem because the devicetree content was generated
> dynamically--after booting--based on the information (including BAR
> addresses) available following PCI enumeration.
>
> It is possible (and in some cases, necessary) to define the devicetree
> nodes that represent PCI devices ahead of time, in a statically-defined
> devicetree file. In order to support the PCI endpoint bus model in this
> case it is necessary to dynamically update the static devicetree so that
> the BAR base addresses assigned during enumeration are reflected in the
> endpoint's "ranges" property.
>
> This series implements that dynamic update, leveraging the same code
> used to create the "ranges" property when PCI_DYNAMIC_OF_NODES is
> enabled. The first patch makes an argument to of_pci_get_addr_flags()
> optional. The second patch separates the code that dynamically builds
> the property value into a helper function, and the last arranges for a
> statically-defined devicetree node for a PCI endpoint to have its
> "ranges" property updated (if it includes a "pci-ep-bus" sub-node)..
>
> -Alex
>
> Note: this series is built upon these patches:
> https://lore.kernel.org/lkml/20260924150222.1179235-5-elder@riscstar.com/
>
> The entire series (based on v7.3-rc4 and including those prerequisites)
> is available here:
> https://github.com/riscstar/linux/tree/outgoing/dynamic_ranges-v3
>
> Between version 2 and version 3:
> - The ranges property for a PCI endpoint with an existing devicetree node
> is only updated if its ranges property has an empty value (i.e., it is
> "ranges;", or is not defined)
>
> Version 2 is available here:
> https://lore.kernel.org/lkml/20260910021919.3421449-1-elder@riscstar.com/
>
> Between version 1 and version 2:
> - Included the first patch (which was previously posted in a different
> series)
> - Modified the last patch so the ranges property is updated only for
> PCI endpoints having at least one "pci-ep-bus" node
> - Rebased on v7.3-rc2 (and the prerequisite series)
>
> Version 1 is available here:
> https://lore.kernel.org/lkml/20260813220717.1394644-1-elder@riscstar.com/
>
>
> Alex Elder (3):
> PCI: of: make a flags argument optional
> PCI: of: introduce of_pci_build_prop_ranges()
> PCI: of: introduce of_pci_update_endpoint_node_ranges()
>
> drivers/pci/of.c | 94 +++++++++++++++++++++++---
> drivers/pci/of_property.c | 137 +++++++++++++++++++++++++-------------
> drivers/pci/pci.h | 1 +
> 3 files changed, 178 insertions(+), 54 deletions(-)
>
>
> base-commit: 6ba8359b84d69a07d508693551ed3f661d838e9f
> --
> 2.53.0
>
After a quick test, it seems that it's not working out of the
box on my RPi5. Let me investigate a bit to see what's wrong.
Many thanks,
Andrea
next prev parent reply other threads:[~2026-10-08 15:42 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-24 22:24 [PATCH v3 0/3] PCI: of: update endpoint ranges dynamically Alex Elder
2026-09-24 22:24 ` [PATCH v3 1/3] PCI: of: make a flags argument optional Alex Elder
2026-09-24 22:24 ` [PATCH v3 2/3] PCI: of: introduce of_pci_build_prop_ranges() Alex Elder
2026-10-09 10:43 ` Ilpo Järvinen
2026-10-13 22:06 ` Alex Elder
2026-09-24 22:24 ` [PATCH v3 3/3] PCI: of: introduce of_pci_update_endpoint_node_ranges() Alex Elder
2026-10-09 10:44 ` Ilpo Järvinen
2026-10-02 16:24 ` [PATCH v3 0/3] PCI: of: update endpoint ranges dynamically Alex Elder
2026-10-08 15:45 ` Andrea della Porta [this message]
2026-10-08 15:55 ` Alex Elder
2026-10-09 13:41 ` Andrea della Porta
2026-10-13 22:30 ` Alex Elder
2026-10-14 8:49 ` Andrea della Porta
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=ase6toUhGn0XD0v9@apocalypse \
--to=andrea.porta@suse.com \
--cc=bhelgaas@google.com \
--cc=daniel@riscstar.com \
--cc=elder@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.