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

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

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

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