From: Herve Codina <herve.codina@bootlin.com>
To: Alex Elder <elder@riscstar.com>
Cc: bhelgaas@google.com, robh@kernel.org, saravanak@kernel.org,
daniel@riscstar.com, mohd.anwar@oss.qualcomm.com,
lorenzo.bianconi@oss.qualcomm.com, linux-pci@vger.kernel.org,
devicetree@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v3 3/4] PCI: of: introduce of_pci_verify_node()
Date: Tue, 1 Sep 2026 08:11:45 +0200 [thread overview]
Message-ID: <20260901081145.25f0e993@bootlin.com> (raw)
In-Reply-To: <20260901011338.1323243-4-elder@riscstar.com>
Hi Alex,
On Mon, 31 Aug 2026 20:13:36 -0500
Alex Elder <elder@riscstar.com> wrote:
> Commit 407d1a51921e9 ("PCI: Create device tree node for bridge") linked
> the PCI enumeration process together with devicetree, creating a devicetree
> node for discovered PCI bridges. 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. These changes allowed devicetree overlays to
> describe components downstream of a PCI device, by providing a place to
> attach the overlay.
>
> Note that the dynamic devicetree node is only created if the device didn't
> already have an assigned node.
>
> Later, commit aa7b4bbcb3a1d ("arm64: dts: qcom: qcs6490-rb3gen2: Add
> TC9563 PCIe switch node") *pre-defined* devicetree nodes to represent the
> PCI device nodes that would (also) be discovered via the PCI enumeration
> process. The devicetree node in this case is created with the content
> from the DTS file. So when a (host) bridge is done being initialized
> during PCI enumeration, no node is dynamically created (the commits
> mentioned above do not apply).
>
> Ideally, any pre-defined PCI devicetree node would contain exactly the
> same information as whatever the dynamic creation process would produce
> (though it could include more).
>
> However that is not the case for the pre-defined Qualcomm RB3gen2 nodes.
> And in particular, the endpoint (function) nodes include this property:
>
> device_type = "pci";
>
> This is simply wrong; that property is meant only for bridge nodes.
>
> Rob Herring requested that a runtime check to be added to spot this
> specific error, only for non-bridge PCI devices. Herve Codina further
> suggested we ensure that bridge PCI devices *do* define the device_type
> property, with value "pci".
>
> Signed-off-by: Alex Elder <elder@riscstar.com>
> ---
> v3: - Switch a function header to use kernel-doc format
> - Add a warning if a PCI bridge node has no device_type property
>
> drivers/pci/bus.c | 1 +
> drivers/pci/of.c | 31 +++++++++++++++++++++++++++++++
> drivers/pci/pci.h | 3 +++
> 3 files changed, 35 insertions(+)
>
LGTM.
Reviewed-by: Herve Codina <herve.codina@bootlin.com>
Best regards,
Hervé
next prev parent reply other threads:[~2026-09-01 6:12 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-01 1:13 [PATCH v3 0/4] PCI: of: warn on bogus device_type property Alex Elder
2026-09-01 1:13 ` [PATCH v3 1/4] PCI: of: drop the reg_num argument to of_pci_set_address() Alex Elder
2026-09-01 1:16 ` sashiko-bot
2026-09-01 1:13 ` [PATCH v3 2/4] PCI: of: don't zero flags in of_pci_get_addr_flags() Alex Elder
2026-09-01 1:20 ` sashiko-bot
2026-09-01 2:42 ` Alex Elder
2026-09-01 1:13 ` [PATCH v3 3/4] PCI: of: introduce of_pci_verify_node() Alex Elder
2026-09-01 1:21 ` sashiko-bot
2026-09-01 2:42 ` Alex Elder
2026-09-01 17:32 ` Rob Herring
2026-09-02 12:54 ` Alex Elder
2026-09-04 13:45 ` Alex Elder
2026-09-01 6:11 ` Herve Codina [this message]
2026-09-01 1:13 ` [PATCH v3 4/4] of: address: kill of_node_is_pcie() Alex Elder
2026-09-01 1:18 ` sashiko-bot
2026-09-01 2:03 ` Alex Elder
2026-09-01 6:45 ` Herve Codina
2026-09-01 14:58 ` Alex Elder
2026-09-01 15:15 ` Herve Codina
2026-09-01 15:25 ` Alex Elder
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=20260901081145.25f0e993@bootlin.com \
--to=herve.codina@bootlin.com \
--cc=bhelgaas@google.com \
--cc=daniel@riscstar.com \
--cc=devicetree@vger.kernel.org \
--cc=elder@riscstar.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=lorenzo.bianconi@oss.qualcomm.com \
--cc=mohd.anwar@oss.qualcomm.com \
--cc=robh@kernel.org \
--cc=saravanak@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.