[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 2/5] arm64: dts: qcom: qcs6490-rb3gen2-industrial-mezzanine: use pci for device nodes

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:

Pre-existing issues:
- [High] The patch claims to fix PCIe endpoints being incorrectly treated as PCI bridges by renaming them from `pcie@` back to `pci@`. However, this is a placebo fix that fails to resolve the issue because the nodes still retain the `device_type = "pci"` property.
--

commit 8f05438af7136e29082530fe0089fb496985289a
Author: Alex Elder <elder@riscstar.com>

arm64: dts: qcom: qcs6490-rb3gen2-industrial-mezzanine: use pci for device nodes

This commit renames embedded PCIe endpoint nodes on the TC9564 SoCs from
pcie@ back to pci@ to prevent them from being incorrectly treated as PCI
bridges. The commit message states that the previous name pcie@ caused
of_node_is_pcie() to match them as bridge nodes.

> 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>;

[Severity: High]
This is a pre-existing issue, but does this rename actually resolve the
problem of endpoints being treated as PCI bridges?

Looking at drivers/of/address.c, the devicetree match logic in
of_bus_pci_match() is evaluated as:

    return of_node_is_type(np, "pci") || of_node_is_type(np, "pciex") ||
           of_node_is_type(np, "vci") || of_node_is_type(np, "ht") ||
           of_node_is_pcie(np);

Since the endpoint node retains the device_type = "pci" property just below
these cells, of_node_is_type(np, "pci") evaluates to true. This short-circuits
the condition before the of_node_is_pcie(np) name check is ever reached.

Because of this property, will the nodes continue to be matched as PCI buses
even with the name changed to pci@0,0, making this a placebo fix?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260901172058.1512508-1-elder@riscstar.com?part=2

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

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] Conceptual Flaw / False Premise: Renaming the node does not prevent it from being treated as a PCI bus because `device_type = "pci"` is still present.
--

commit 3cd795cb2f33ffae376d5bceb9ba0da490602d05
Author: Alex Elder <elder@riscstar.com>

arm64: dts: qcom: qcs6490-rb3gen2: use pci for device nodes

This commit renames devicetree nodes from pcie@ to pci@ with the intent of
stopping the embedded PCIe endpoints from being treated as PCI buses by the
devicetree parsing code.

> 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>;
>  				device_type = "pci";

[Severity: Medium]
Does this node rename actually prevent the devicetree parsing code from
treating it as a PCI bus?

The commit message indicates that renaming the node away from pcie@ will stop
of_node_is_pcie() from matching it. However, because this node explicitly
specifies device_type = "pci", of_bus_pci_match() in drivers/of/address.c
will still return true immediately.

When evaluating buses, of_bus_pci_match() checks:

    of_node_is_type(np, "pci") || of_node_is_pcie(np)

Since the device type is explicitly "pci", the match succeeds before
of_node_is_pcie() is evaluated. Should device_type = "pci" also be removed to
actually prevent this endpoint from being treated as a PCI bridge?

[ ... ]

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260901172058.1512508-1-elder@riscstar.com?part=1

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

[Alex Elder]

On 9/1/26 12:39 PM, sashiko-bot@kernel.org wrote:
> Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
> - [Medium] Conceptual Flaw / False Premise: Renaming the node does not prevent it from being treated as a PCI bus because `device_type = "pci"` is still present.
> --
> 
> commit 3cd795cb2f33ffae376d5bceb9ba0da490602d05
> Author: Alex Elder <elder@riscstar.com>
> 
> arm64: dts: qcom: qcs6490-rb3gen2: use pci for device nodes
> 
> This commit renames devicetree nodes from pcie@ to pci@ with the intent of
> stopping the embedded PCIe endpoints from being treated as PCI buses by the
> devicetree parsing code.
> 
>> 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>;
>>   				device_type = "pci";
> 
> [Severity: Medium]
> Does this node rename actually prevent the devicetree parsing code from
> treating it as a PCI bus?

This patch (series) is being done separate from another pre-existing
series that addresses that particular issue.  I suppose once that
is merged I can re-issue this one.

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

It looks like I might get a similar comment from Sashiko on other
patches in this series... I won't respond to any others unless what
is noted differs from what I've explained here.

					-Alex

> The commit message indicates that renaming the node away from pcie@ will stop
> of_node_is_pcie() from matching it. However, because this node explicitly
> specifies device_type = "pci", of_bus_pci_match() in drivers/of/address.c
> will still return true immediately.
> 
> When evaluating buses, of_bus_pci_match() checks:
> 
>      of_node_is_type(np, "pci") || of_node_is_pcie(np)
> 
> Since the device type is explicitly "pci", the match succeeds before
> of_node_is_pcie() is evaluated. Should device_type = "pci" also be removed to
> actually prevent this endpoint from being treated as a PCI bridge?
> 
> [ ... ]
> 

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

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] Ineffective Bug Fix / Logic Flaw: renaming nodes fails to prevent them from being parsed as PCI bridges
--

commit a26d89db10179b360a293aeb14a12f49b7daf216
Author: Alex Elder <elder@riscstar.com>

arm64: dts: qcom: lemans-evk-ifp-mezzanine: use pci for device nodes

This patch renames the PCIe endpoint nodes from "pcie@" to "pci@" in the
Lemans EVK IFP mezzanine devicetree. The goal is to prevent the devicetree
parsing code from incorrectly treating these endpoint nodes as PCI bridge
nodes.

> 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>;
>  				device_type = "pci";

[Severity: Medium]
Will this rename successfully prevent the node from being matched as a PCI
bridge?

When the devicetree address parser matches the bus type, it iterates of_busses
and calls of_bus_pci_match() which checks:

of_bus_pci_match() {
    return of_node_is_type(np, "pci") || ... || of_node_is_pcie(np);
}

Since this node still retains the device_type = "pci" property,
of_node_is_type(np, "pci") will evaluate to true immediately.

Does this mean the of_node_is_pcie() check is completely bypassed, leaving the
node still incorrectly matched as a PCI bus? Should the device_type = "pci"
property be removed from these endpoint nodes instead, as required by the
devicetree specification?

>  				ranges;
>  			};
>  
> -			pcie@0,1 {
> +			pci@0,1 {
>  				reg = <0x50100 0x0 0x0 0x0 0x0>;
>  				#address-cells = <3>;
>  				#size-cells = <2>;
>  				device_type = "pci";

[Severity: Medium]
Does the same logic flaw apply to this node as well?

Because the device_type = "pci" property is also still present here, it
appears this node will also unconditionally match as a PCI bus in
of_bus_pci_match() regardless of the rename.

>  				ranges;
>  			};
>  		};

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260901172058.1512508-1-elder@riscstar.com?part=3

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

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:

New issues:
- [Medium] Mismatch between the commit title and the patch implementation regarding the new node name.

Pre-existing issues:
- [High] Renaming the endpoint nodes from 'pcie@' to 'pci@' will not prevent them from being treated as PCI buses, because the `device_type = "pci"` property is retained.
--

commit c206fa07d8c746582b6a4894fa608acb472261eb
Author: Alex Elder <elder@riscstar.com>

> arm64: dts: qcom: monaco-evk-ifp-mezzanine: use dev for device nodes

[Severity: Medium]
Does the commit title match the implementation? The title explicitly mentions
using "dev for device nodes", but the patch renames the nodes to "pci@",
not "dev@".

This patch aims to fix an issue where embedded PCIe endpoints were
incorrectly treated as PCI buses after being renamed to pcie@. It
renames the nodes to pci@ to restore previous behavior and avoid
them being mistaken for bridge nodes.

> 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>;
>  				device_type = "pci";

[Severity: High]
This is a pre-existing issue, but does renaming the node to "pci@" actually
prevent it from being treated as a PCI bus?

The node pci@0,0 retains the device_type = "pci" property. When the devicetree
address parser matches buses, of_bus_pci_match() in drivers/of/address.c
evaluates the type before checking the node name:

drivers/of/address.c:of_bus_pci_match() {
        ...
        return of_node_is_type(np, "pci") || of_node_is_type(np, "pciex") ||
                of_node_is_type(np, "vci") || of_node_is_type(np, "ht") ||
                of_node_is_pcie(np);
}

Because device_type = "pci" remains present in the endpoint node,
of_node_is_type() will still evaluate to true. Will this cause the node to
always be matched as a PCI bus unconditionally, rendering the rename
ineffective at restoring the default-flags bus behavior?

This same question applies to the pci@0,1 node modified later in the file.

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260901172058.1512508-1-elder@riscstar.com?part=4

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

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] The commit claims that renaming PCIe endpoint nodes from `pcie@` to `pci@` prevents them from being incorrectly treated as PCI buses by `of_bus_pci_match()`. However, this fix is logically flawed and entirely ineffective because the endpoint nodes still contain the `device_type = "pci"` property. `of_bus_pci_match()` checks `of_node_is_type(np, "pci")` before checking the node name via `of_node_is_pcie(np)`. Because the `device_type = "pci"` property is present on the nodes, the match short-circuits and evaluates to true unconditionally, bypassing the name check. As a result, the endpoints will still be treated as PCI buses, failing to restore the desired `default-flags` bus behavior.
--

commit 1271b9698d89ac8a7e9afe5810c933ffba016f7f
Author: Alex Elder <elder@riscstar.com>

arm64: dts: qcom: qcs6490-thundercomm-minipc-g1iot: use dev for device nodes

This commit renames the PCIe endpoint nodes from "pcie@" to "pci@" in the
Thundercomm AI Mini PC G1 IoT devicetree. The goal is to prevent these
endpoints from being incorrectly treated as PCI buses by the parsing logic
in of_node_is_pcie().

> 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>;

[Severity: Medium]
Does this rename actually prevent the node from being treated as a PCI
bridge?

The commit message states that renaming the nodes to "pci@" stops them from
being treated as PCI bridges by bypassing of_node_is_pcie(). However, these
nodes still contain the property device_type = "pci" (visible just below
this diff context).

During devicetree address parsing, of_bus_pci_match() in
drivers/of/address.c checks the device type before it checks the node name:

drivers/of/address.c:of_bus_pci_match() {
	return of_node_is_type(np, "pci") || of_node_is_type(np, "pciex") ||
		of_node_is_type(np, "vci") || of_node_is_type(np, "ht") ||
		of_node_is_pcie(np);
}

Since of_node_is_type(np, "pci") evaluates to true, the match short-circuits
and succeeds unconditionally, bypassing the of_node_is_pcie() check entirely.

Will these endpoints still be mistakenly treated as PCI buses despite the
name change?

[ ... ]

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260901172058.1512508-1-elder@riscstar.com?part=5

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

[Alex Elder]

On 9/1/26 12:54 PM, sashiko-bot@kernel.org wrote:
> New issues:
> - [Medium] Mismatch between the commit title and the patch implementation regarding the new node name.

This was indeed a mistake.  I will update to say "use pci"
rather than "use dev" in the title.

As an aside...  I initially tried using "dev" for these nodes.
The reason was that of_pci_make_dev_node() uses that convention
for non-bridge nodes.  This was introduced by commit 407d1a51921e9
("PCI: Create device tree node for bridge"), and I haven't yet
gone to see if there was discussion about that choice when that
patch was out for review.

However DTC complains if a node is not named "pci" or "pcie",
so I went back to using "pci" for these endpoint nodes instead.

I personally think dynamically-generated devicetree content should
honor the same conventions and restrictions used for static
devicetree files.  There isn't an automated way to do that though.

I was thinking of following up with a proposed change to
of_pci_make_dev_node() to at least use "pci" rather than "dev"
for non-bridge nodes, but I'm not sure that's the right thing
to do.

Comments welcome.

					-Alex

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