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

[Alex Elder <elder@riscstar.com>]

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