[PATCH 0/5] arm64: dts: qcom: use pci for device nodes

[PATCH 0/5] arm64: dts: qcom: use pci for device nodes

[Alex Elder]

A recent change caused the embedded PCIe endpoints on TC9564 SoCs to
be treated by the devicetree code as PCI buses, which is incorrect.

The TC9564 includes a PCIe switch with one 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 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@").

This unfortunately changed the way the devicetree code treats the
nodes, because of_bus_pci_match() considers any node named pcie@
that has no device_type property to be a PCI bus.

The previous name "pci" matched such nodes as "default-flags" bus type
(defined in the of_busses[] array).  This series restores the previous
behavior for these endpoint nodes.

					-Alex

Alex Elder (5):
  arm64: dts: qcom: qcs6490-rb3gen2: use pci for device nodes
  arm64: dts: qcom: qcs6490-rb3gen2-industrial-mezzanine: use pci for
    device nodes
  arm64: dts: qcom: lemans-evk-ifp-mezzanine: use pci for device nodes
  arm64: dts: qcom: monaco-evk-ifp-mezzanine: use dev for device nodes
  arm64: dts: qcom: qcs6490-thundercomm-minipc-g1iot: use dev for device
    nodes

 arch/arm64/boot/dts/qcom/lemans-evk-ifp-mezzanine.dtso    | 4 ++--
 arch/arm64/boot/dts/qcom/monaco-evk-ifp-mezzanine.dtso    | 4 ++--
 .../dts/qcom/qcs6490-rb3gen2-industrial-mezzanine.dtso    | 8 ++++----
 arch/arm64/boot/dts/qcom/qcs6490-rb3gen2.dts              | 4 ++--
 .../boot/dts/qcom/qcs6490-thundercomm-minipc-g1iot.dts    | 4 ++--
 5 files changed, 12 insertions(+), 12 deletions(-)


base-commit: cee9395acd8043be0644b25c34bfa86623f2b935
-- 
2.53.0

[PATCH 1/5] arm64: dts: qcom: qcs6490-rb3gen2: use pci for device nodes

[Alex Elder]

A recent change caused the embedded PCIe endpoints on TC9564 SoCs to
be treated by the devicetree code as PCI buses, which is incorrect.

An RB3gen2 system has an "interposer board" that contains a TC9564
SoC.  The TC9564 includes a PCIe switch with one 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 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, of_node_is_pcie() causes nodes named "pcie@" to be
treated as PCI bridges, which PCI endpoints 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>
---
 arch/arm64/boot/dts/qcom/qcs6490-rb3gen2.dts | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arm64/boot/dts/qcom/qcs6490-rb3gen2.dts b/arch/arm64/boot/dts/qcom/qcs6490-rb3gen2.dts
index a13315bf0fb07..99a985a177a61 100644
--- a/arch/arm64/boot/dts/qcom/qcs6490-rb3gen2.dts
+++ b/arch/arm64/boot/dts/qcom/qcs6490-rb3gen2.dts
@@ -954,7 +954,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>;
@@ -962,7 +962,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

[PATCH 2/5] arm64: dts: qcom: qcs6490-rb3gen2-industrial-mezzanine: use pci for device nodes

[Alex Elder]

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

[PATCH 3/5] arm64: dts: qcom: lemans-evk-ifp-mezzanine: use pci for device nodes

[Alex Elder]

A recent change caused the embedded PCIe endpoints on TC9564 SoCs to
be treated by the devicetree code as PCI buses, which is incorrect.

The Lemans EVK IFP mezzanine has a TC9564 SoC, which includes a
PCIe switch with one 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 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, of_node_is_pcie() causes nodes named "pcie@" to be
treated as PCI bridges, which PCI endpoints 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>
---
 arch/arm64/boot/dts/qcom/lemans-evk-ifp-mezzanine.dtso | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arm64/boot/dts/qcom/lemans-evk-ifp-mezzanine.dtso b/arch/arm64/boot/dts/qcom/lemans-evk-ifp-mezzanine.dtso
index 6cfa0bc1440e9..22c975628ed79 100644
--- a/arch/arm64/boot/dts/qcom/lemans-evk-ifp-mezzanine.dtso
+++ b/arch/arm64/boot/dts/qcom/lemans-evk-ifp-mezzanine.dtso
@@ -271,7 +271,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>;
@@ -279,7 +279,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

[PATCH 4/5] arm64: dts: qcom: monaco-evk-ifp-mezzanine: use dev for device nodes

[Alex Elder]

A recent change caused the embedded PCIe endpoints on TC9564 SoCs to
be treated by the devicetree code as PCI buses, which is incorrect.

The Monaco EVK IFP mezzanine has a TC9564 SoC, which includes a
PCIe switch with one 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 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, of_node_is_pcie() causes nodes named "pcie@" to be
treated as PCI bridges, which PCI endpoints 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>
---
 arch/arm64/boot/dts/qcom/monaco-evk-ifp-mezzanine.dtso | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arm64/boot/dts/qcom/monaco-evk-ifp-mezzanine.dtso b/arch/arm64/boot/dts/qcom/monaco-evk-ifp-mezzanine.dtso
index ca5bf0fe5ec6e..a6e57ec8a1e14 100644
--- a/arch/arm64/boot/dts/qcom/monaco-evk-ifp-mezzanine.dtso
+++ b/arch/arm64/boot/dts/qcom/monaco-evk-ifp-mezzanine.dtso
@@ -117,7 +117,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>;
@@ -125,7 +125,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

[PATCH 5/5] arm64: dts: qcom: qcs6490-thundercomm-minipc-g1iot: use dev for device nodes

[Alex Elder]

A recent change caused the embedded PCIe endpoints on TC9564 SoCs to
be treated by the devicetree code as PCI buses, which is incorrect.

The Thundercomm AI Mini PC G1 IoT defines a TC956x SoC, which includes
a PCIe switch with one 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 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, of_node_is_pcie() causes nodes named "pcie@" to be
treated as PCI bridges, which PCI endpoints 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>
---
 arch/arm64/boot/dts/qcom/qcs6490-thundercomm-minipc-g1iot.dts | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arm64/boot/dts/qcom/qcs6490-thundercomm-minipc-g1iot.dts b/arch/arm64/boot/dts/qcom/qcs6490-thundercomm-minipc-g1iot.dts
index 31bafa2cf51db..183ac59ca7d49 100644
--- a/arch/arm64/boot/dts/qcom/qcs6490-thundercomm-minipc-g1iot.dts
+++ b/arch/arm64/boot/dts/qcom/qcs6490-thundercomm-minipc-g1iot.dts
@@ -790,7 +790,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>;
@@ -798,7 +798,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

Re: [PATCH 1/5] arm64: dts: qcom: qcs6490-rb3gen2: use pci for device nodes

[Rob Herring]

On Tue, Sep 1, 2026 at 12:21 PM Alex Elder <elder@riscstar.com> wrote:
>
> A recent change caused the embedded PCIe endpoints on TC9564 SoCs to
> be treated by the devicetree code as PCI buses, which is incorrect.
>
> An RB3gen2 system has an "interposer board" that contains a TC9564
> SoC.  The TC9564 includes a PCIe switch with one 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 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, of_node_is_pcie() causes nodes named "pcie@" to be
> treated as PCI bridges, which PCI endpoints 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>
> ---
>  arch/arm64/boot/dts/qcom/qcs6490-rb3gen2.dts | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm64/boot/dts/qcom/qcs6490-rb3gen2.dts b/arch/arm64/boot/dts/qcom/qcs6490-rb3gen2.dts
> index a13315bf0fb07..99a985a177a61 100644
> --- a/arch/arm64/boot/dts/qcom/qcs6490-rb3gen2.dts
> +++ b/arch/arm64/boot/dts/qcom/qcs6490-rb3gen2.dts
> @@ -954,7 +954,7 @@ pcie@3,0 {
>                         ranges;
>                         bus-range = <0x5 0xff>;
>
> -                       pcie@0,0 {
> +                       pci@0,0 {

The kernel should treat either name the same. There may have been some
reason 'pci' was not included in checks. It could have been that only
old things are (parallel, plain) 'pci' and anything new is 'pcie'.

These are ethernet devices, right? Then the right name is
'ethernet@0,0'. If not, then pick something that matches what the node
is. Both pci and pcie mean the node implements a PCI bus.

Rob

Re: [PATCH 1/5] arm64: dts: qcom: qcs6490-rb3gen2: use pci for device nodes

[Alex Elder]

On 9/1/26 3:05 PM, Rob Herring wrote:
> On Tue, Sep 1, 2026 at 12:21 PM Alex Elder <elder@riscstar.com> wrote:
>>
>> A recent change caused the embedded PCIe endpoints on TC9564 SoCs to
>> be treated by the devicetree code as PCI buses, which is incorrect.
>>
>> An RB3gen2 system has an "interposer board" that contains a TC9564
>> SoC.  The TC9564 includes a PCIe switch with one 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 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, of_node_is_pcie() causes nodes named "pcie@" to be
>> treated as PCI bridges, which PCI endpoints 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>
>> ---
>>   arch/arm64/boot/dts/qcom/qcs6490-rb3gen2.dts | 4 ++--
>>   1 file changed, 2 insertions(+), 2 deletions(-)
>>
>> diff --git a/arch/arm64/boot/dts/qcom/qcs6490-rb3gen2.dts b/arch/arm64/boot/dts/qcom/qcs6490-rb3gen2.dts
>> index a13315bf0fb07..99a985a177a61 100644
>> --- a/arch/arm64/boot/dts/qcom/qcs6490-rb3gen2.dts
>> +++ b/arch/arm64/boot/dts/qcom/qcs6490-rb3gen2.dts
>> @@ -954,7 +954,7 @@ pcie@3,0 {
>>                          ranges;
>>                          bus-range = <0x5 0xff>;
>>
>> -                       pcie@0,0 {
>> +                       pci@0,0 {
> 
> The kernel should treat either name the same. There may have been some
> reason 'pci' was not included in checks. It could have been that only
> old things are (parallel, plain) 'pci' and anything new is 'pcie'.

OK.  Does this mean "pci@" and "pcie@" should only represent bridge
devices?  (These devices are all endpoints and erroneously had
device_type = "pci" properties, among other things, so I'm already
fixing that.)

Do you want me to make a (separate) change to treat "pci" the
same as "pcie"?

> These are ethernet devices, right? Then the right name is
> 'ethernet@0,0'. If not, then pick something that matches what the node
> is. Both pci and pcie mean the node implements a PCI bus.

They implement Ethernet devices, yes.  But they are used for
pci-ep-bus (and the Ethernet devices bind to a sub-node), and
that's what's important about these nodes.  What's the right
name?  The dynamically-generated node uses "dev@".

Is "ethernet@" still right, if it's also used to access a
clock and a reset and ... via pci-ep-bus?

I want to use the right name, I'm just unsure about what that
is, given its use for access via pci-ep-bus.

Thanks.

					-Alex



> Rob

Re: [PATCH 1/5] arm64: dts: qcom: qcs6490-rb3gen2: use pci for device nodes

[Rob Herring]

On Wed, Sep 02, 2026 at 07:51:54AM -0500, Alex Elder wrote:
> On 9/1/26 3:05 PM, Rob Herring wrote:
> > On Tue, Sep 1, 2026 at 12:21 PM Alex Elder <elder@riscstar.com> wrote:
> > > 
> > > A recent change caused the embedded PCIe endpoints on TC9564 SoCs to
> > > be treated by the devicetree code as PCI buses, which is incorrect.
> > > 
> > > An RB3gen2 system has an "interposer board" that contains a TC9564
> > > SoC.  The TC9564 includes a PCIe switch with one 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 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, of_node_is_pcie() causes nodes named "pcie@" to be
> > > treated as PCI bridges, which PCI endpoints 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>
> > > ---
> > >   arch/arm64/boot/dts/qcom/qcs6490-rb3gen2.dts | 4 ++--
> > >   1 file changed, 2 insertions(+), 2 deletions(-)
> > > 
> > > diff --git a/arch/arm64/boot/dts/qcom/qcs6490-rb3gen2.dts b/arch/arm64/boot/dts/qcom/qcs6490-rb3gen2.dts
> > > index a13315bf0fb07..99a985a177a61 100644
> > > --- a/arch/arm64/boot/dts/qcom/qcs6490-rb3gen2.dts
> > > +++ b/arch/arm64/boot/dts/qcom/qcs6490-rb3gen2.dts
> > > @@ -954,7 +954,7 @@ pcie@3,0 {
> > >                          ranges;
> > >                          bus-range = <0x5 0xff>;
> > > 
> > > -                       pcie@0,0 {
> > > +                       pci@0,0 {
> > 
> > The kernel should treat either name the same. There may have been some
> > reason 'pci' was not included in checks. It could have been that only
> > old things are (parallel, plain) 'pci' and anything new is 'pcie'.
> 
> OK.  Does this mean "pci@" and "pcie@" should only represent bridge
> devices?  (These devices are all endpoints and erroneously had
> device_type = "pci" properties, among other things, so I'm already
> fixing that.)

Yes.

> Do you want me to make a (separate) change to treat "pci" the
> same as "pcie"?

Only if it fixes something besides consistency.

> > These are ethernet devices, right? Then the right name is
> > 'ethernet@0,0'. If not, then pick something that matches what the node
> > is. Both pci and pcie mean the node implements a PCI bus.
> 
> They implement Ethernet devices, yes.  But they are used for
> pci-ep-bus (and the Ethernet devices bind to a sub-node), and
> that's what's important about these nodes.  What's the right
> name?  The dynamically-generated node uses "dev@".

I don't love 'dev', but don't have a better suggestion for it.

> 
> Is "ethernet@" still right, if it's also used to access a
> clock and a reset and ... via pci-ep-bus?

"ethernet@" belongs on the node that has ethernet-controller.yaml schema 
applied.

> 
> I want to use the right name, I'm just unsure about what that
> is, given its use for access via pci-ep-bus.

I don't know if there's a right name here. You just can't use a standard 
name if the node doesn't implement what the standard name defines. 
Granted we just have a list in the spec and some names (e.g. pci) imply 
more that other names.

Rob

Re: [PATCH 1/5] arm64: dts: qcom: qcs6490-rb3gen2: use pci for device nodes

[Alex Elder]

On 9/2/26 11:53 AM, Rob Herring wrote:
> On Wed, Sep 02, 2026 at 07:51:54AM -0500, Alex Elder wrote:
>> On 9/1/26 3:05 PM, Rob Herring wrote:
>>> On Tue, Sep 1, 2026 at 12:21 PM Alex Elder <elder@riscstar.com> wrote:
>>>>
>>>> A recent change caused the embedded PCIe endpoints on TC9564 SoCs to
>>>> be treated by the devicetree code as PCI buses, which is incorrect.

I respond below, and have a plan for moving forward.
>>>> An RB3gen2 system has an "interposer board" that contains a TC9564
>>>> SoC.  The TC9564 includes a PCIe switch with one 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 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, of_node_is_pcie() causes nodes named "pcie@" to be
>>>> treated as PCI bridges, which PCI endpoints 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>
>>>> ---
>>>>    arch/arm64/boot/dts/qcom/qcs6490-rb3gen2.dts | 4 ++--
>>>>    1 file changed, 2 insertions(+), 2 deletions(-)
>>>>
>>>> diff --git a/arch/arm64/boot/dts/qcom/qcs6490-rb3gen2.dts b/arch/arm64/boot/dts/qcom/qcs6490-rb3gen2.dts
>>>> index a13315bf0fb07..99a985a177a61 100644
>>>> --- a/arch/arm64/boot/dts/qcom/qcs6490-rb3gen2.dts
>>>> +++ b/arch/arm64/boot/dts/qcom/qcs6490-rb3gen2.dts
>>>> @@ -954,7 +954,7 @@ pcie@3,0 {
>>>>                           ranges;
>>>>                           bus-range = <0x5 0xff>;
>>>>
>>>> -                       pcie@0,0 {
>>>> +                       pci@0,0 {
>>>
>>> The kernel should treat either name the same. There may have been some
>>> reason 'pci' was not included in checks. It could have been that only
>>> old things are (parallel, plain) 'pci' and anything new is 'pcie'.
>>
>> OK.  Does this mean "pci@" and "pcie@" should only represent bridge
>> devices?  (These devices are all endpoints and erroneously had
>> device_type = "pci" properties, among other things, so I'm already
>> fixing that.)
> 
> Yes.

OK.  This means that these nodes were misnamed, and that should
be fixed when addressing the broader problem of describing
these nodes as if they were a PCI bridges rather than endpoints.
That problem is addressed in this other series:

   https://lore.kernel.org/lkml/20260901013654.1343537-2-elder@riscstar.com/

Lots of reviews on that...  But I'll submit *one more version*
of it, as described below.

>> Do you want me to make a (separate) change to treat "pci" the
>> same as "pcie"?
> 
> Only if it fixes something besides consistency.

I have no example of this causing a problem, so I will not
implement any such change.

>>> These are ethernet devices, right? Then the right name is
>>> 'ethernet@0,0'. If not, then pick something that matches what the node
>>> is. Both pci and pcie mean the node implements a PCI bus.
>>
>> They implement Ethernet devices, yes.  But they are used for
>> pci-ep-bus (and the Ethernet devices bind to a sub-node), and
>> that's what's important about these nodes.  What's the right
>> name?  The dynamically-generated node uses "dev@".
> 
> I don't love 'dev', but don't have a better suggestion for it.

OK.  The only reason I like "dev" is that it matches what the
dynamic PCI devicetree nodes are named.

>> Is "ethernet@" still right, if it's also used to access a
>> clock and a reset and ... via pci-ep-bus?
> 
> "ethernet@" belongs on the node that has ethernet-controller.yaml schema
> applied.

That makes sense and it's actually how it's done in our code
currently (not all of it is currently out for review).

>> I want to use the right name, I'm just unsure about what that
>> is, given its use for access via pci-ep-bus.
> 
> I don't know if there's a right name here. You just can't use a standard
> name if the node doesn't implement what the standard name defines.
> Granted we just have a list in the spec and some names (e.g. pci) imply
> more that other names.

Here is my plan.

First, I will use "dev@" rather than "pci@" for the names of
these endpoint nodes--in all of the affected Qualcomm DTS
files.

Second, rather than doing that as a follow-on to *this* series,
I will instead post version 3 of the series linked to above,
adding to the changes made that the names of the nodes will
get changed as well (for the reasons covered here).  I therefore
retract this series, because it will be merged into the other one.

==> MANI, KONRAD, ABEL:  I am going to keep your
     Reviewed-by tags on the new version, because I think it's
     more likely than not you agree with this change.

     Please just ask me to remove it when I post if you
     disagree.

					-Alex
> 
> Rob