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@xxxxxxxxxxxx> 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@xxxxxxxxxxxx>
> > > ---
> > >   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