From: Alex Elder <elder@riscstar.com>
To: andersson@kernel.org, konradybcio@kernel.org, robh@kernel.org,
krzk+dt@kernel.org, conor+dt@kernel.org
Cc: daniel@riscstar.com, mohd.anwar@oss.qualcomm.com,
lorenzo.bianconi@oss.qualcomm.com, devicetree@vger.kernel.org,
linux-arm-msm@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: [PATCH 2/5] arm64: dts: qcom: qcs6490-rb3gen2-industrial-mezzanine: use pci for device nodes
Date: Tue, 1 Sep 2026 12:20:54 -0500 [thread overview]
Message-ID: <20260901172058.1512508-3-elder@riscstar.com> (raw)
In-Reply-To: <20260901172058.1512508-1-elder@riscstar.com>
A recent change caused the embedded PCIe endpoints on TC9564 SoCs to
be treated by the code devicetree as PCI buses, which is incorrect.
There are three TC9564 SoCs on the RB3gen2 system with an industrial
mezzanine. All implement a PCIe switch that includes an upstream
port and two downstream (external) ports, plus a third downstream
port. The third port has an embedded PCIe endpoint with two functions,
each providing access to a 10 Gbps capable Ethernet interface.
The first TC9564 is found on the "interposer board." Its upstream
switch port connects to the QCS6490 host PCIe root port 1, and is
described in "qcs6490-rb3gen2.dts".
The other two TC9564 SoCs are found on the industrial mezzanine board
and are described in "qcs6490-rb3gen2-industrial-mezzanine.dtso". The
upstream switch port for one of these connects to the QCS6490 host PCIe
root port 0. The upstream port for the other is connected to the second
downstream PCIe switch port of the TC9564 on root port 1.
---------------
| QCS6490 |
| Host |
| PCIe0 PCIe1 | +
----+-----+---- ------------------ |
| | | TC9564 1 | | ------------------
| | | DSP1 +--- | TC9564 2 |
| -------+ USP | | DSP1 +-----+
| | DSP3 DSP2 +-----+ USP |
| | / \ | | DSP3 DSP2 +-----+
| | EPF0 EPF1 | | / \ |
| ----+------+------ | EPF0 EPF1 |
| ------------------ ----+------+------
| | TC9564 3 |
| | DSP1 +-----+
-------------+ USP |
| DSP3 DSP2 +-----+
| / \ |
| EPF0 EPF1 |
----+------+------
The third downstream port (DSP3) on all three of these has an
embedded PCIe endpoint with two functions, each of which implements
a 10 Gbps-capable Ethernet interface. These devicetree nodes
representing these functions were previously named "pci@" but were
renamed in the interest of consistency in commit e806c63ba51a7
("arm64: dts: qcom: Rename pci@ nodes to pcie@").
Unfortunately, when these nodes are named "pcie@" (as they are now),
of_node_is_pcie() causes them to be treated as PCI bridges, which they
are not. The previous name "pci" matched such nodes as "default-flags"
bus type, defined in the of_busses[] array.
Rename the PCIe endpoint nodes "pci@" so they are not mistaken for
bridge nodes by the devicetree parsing code. This restores the
previous behavior, and allows them to be used for PCI endpoint bus.
Fixes: e806c63ba51a7 ("arm64: dts: qcom: Rename pci@ nodes to pcie@")
Signed-off-by: Alex Elder <elder@riscstar.com>
---
.../dts/qcom/qcs6490-rb3gen2-industrial-mezzanine.dtso | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/arch/arm64/boot/dts/qcom/qcs6490-rb3gen2-industrial-mezzanine.dtso b/arch/arm64/boot/dts/qcom/qcs6490-rb3gen2-industrial-mezzanine.dtso
index 46bb52c667a4d..14c64439ae1e6 100644
--- a/arch/arm64/boot/dts/qcom/qcs6490-rb3gen2-industrial-mezzanine.dtso
+++ b/arch/arm64/boot/dts/qcom/qcs6490-rb3gen2-industrial-mezzanine.dtso
@@ -130,7 +130,7 @@ pcie@3,0 {
ranges;
bus-range = <0x5 0xff>;
- pcie@0,0 {
+ pci@0,0 {
reg = <0x50000 0x0 0x0 0x0 0x0>;
#address-cells = <3>;
#size-cells = <2>;
@@ -138,7 +138,7 @@ pcie@0,0 {
ranges;
};
- pcie@0,1 {
+ pci@0,1 {
reg = <0x50100 0x0 0x0 0x0 0x0>;
#address-cells = <3>;
#size-cells = <2>;
@@ -225,7 +225,7 @@ pcie@3,0 {
ranges;
bus-range = <0x5 0xff>;
- pcie@0,0 {
+ pci@0,0 {
reg = <0x50000 0x0 0x0 0x0 0x0>;
#address-cells = <3>;
#size-cells = <2>;
@@ -233,7 +233,7 @@ pcie@0,0 {
ranges;
};
- pcie@0,1 {
+ pci@0,1 {
reg = <0x50100 0x0 0x0 0x0 0x0>;
#address-cells = <3>;
#size-cells = <2>;
--
2.53.0
next prev parent reply other threads:[~2026-09-01 17:21 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-01 17:20 [PATCH 0/5] arm64: dts: qcom: use pci for device nodes Alex Elder
2026-09-01 17:20 ` [PATCH 1/5] arm64: dts: qcom: qcs6490-rb3gen2: " Alex Elder
2026-09-01 17:39 ` sashiko-bot
2026-09-01 17:45 ` Alex Elder
2026-09-01 20:05 ` Rob Herring
2026-09-02 12:51 ` Alex Elder
2026-09-02 16:53 ` Rob Herring
2026-09-02 18:40 ` Alex Elder
2026-09-01 17:20 ` Alex Elder [this message]
2026-09-01 17:34 ` [PATCH 2/5] arm64: dts: qcom: qcs6490-rb3gen2-industrial-mezzanine: " sashiko-bot
2026-09-01 17:20 ` [PATCH 3/5] arm64: dts: qcom: lemans-evk-ifp-mezzanine: " Alex Elder
2026-09-01 17:49 ` sashiko-bot
2026-09-01 17:20 ` [PATCH 4/5] arm64: dts: qcom: monaco-evk-ifp-mezzanine: use dev " Alex Elder
2026-09-01 17:54 ` sashiko-bot
2026-09-01 18:18 ` Alex Elder
2026-09-01 17:20 ` [PATCH 5/5] arm64: dts: qcom: qcs6490-thundercomm-minipc-g1iot: " Alex Elder
2026-09-01 18:03 ` sashiko-bot
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=20260901172058.1512508-3-elder@riscstar.com \
--to=elder@riscstar.com \
--cc=andersson@kernel.org \
--cc=conor+dt@kernel.org \
--cc=daniel@riscstar.com \
--cc=devicetree@vger.kernel.org \
--cc=konradybcio@kernel.org \
--cc=krzk+dt@kernel.org \
--cc=linux-arm-msm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=lorenzo.bianconi@oss.qualcomm.com \
--cc=mohd.anwar@oss.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox