[PATCH 2/2] ARM: dts: BCM5301X: Describe PCIe controllers fully
Florian Fainelli
florian.fainelli at broadcom.com
Wed Apr 24 09:57:29 PDT 2024
On 4/23/24 23:43, Rafał Miłecki wrote:
> On 23.04.2024 21:03, Florian Fainelli wrote:
>> On 4/23/24 04:02, Rafał Miłecki wrote:
>>> From: Rafał Miłecki <rafal at milecki.pl>
>>>
>>> This fixes:
>>> arch/arm/boot/dts/broadcom/bcm4708-asus-rt-ac56u.dtb: pcie at 18012000:
>>> 'device_type' is a required property
>>> from schema $id:
>>> http://devicetree.org/schemas/pci/pci-bus.yaml#
>>> arch/arm/boot/dts/broadcom/bcm4708-asus-rt-ac56u.dtb: pcie at 18012000:
>>> 'ranges' is a required property
>>> from schema $id:
>>> http://devicetree.org/schemas/pci/pci-bus.yaml#
>>> arch/arm/boot/dts/broadcom/bcm4708-asus-rt-ac56u.dtb: pcie at 18013000:
>>> 'device_type' is a required property
>>> from schema $id:
>>> http://devicetree.org/schemas/pci/pci-bus.yaml#
>>> arch/arm/boot/dts/broadcom/bcm4708-asus-rt-ac56u.dtb: pcie at 18013000:
>>> 'ranges' is a required property
>>> from schema $id:
>>> http://devicetree.org/schemas/pci/pci-bus.yaml#
>>> arch/arm/boot/dts/broadcom/bcm4708-asus-rt-ac56u.dtb: pcie at 18014000:
>>> 'device_type' is a required property
>>> from schema $id:
>>> http://devicetree.org/schemas/pci/pci-bus.yaml#
>>> arch/arm/boot/dts/broadcom/bcm4708-asus-rt-ac56u.dtb: pcie at 18014000:
>>> 'ranges' is a required property
>>> from schema $id:
>>> http://devicetree.org/schemas/pci/pci-bus.yaml#
>>>
>>> Cc: Arınç ÜNAL <arinc.unal at arinc9.com>
>>> Signed-off-by: Rafał Miłecki <rafal at milecki.pl>
>>
>> OK, so this is the rationale for patch #1, because you are adding a
>> 'ranges' property to each PCIe root complex node, and you need the
>> values in the 'ranges' property to be expressed relative to the global
>> address space, and not the axi at 18000000 address space, you needed to
>> flatten the axi at 18000000 range.
>>
>> Why not just bring those 3 nodes out of the axi at 18000000 node into the
>> global address space then? That would greatly limit the amount of
>> changes in patch #1, some of which are just unfortunate noise.
>>
>> From the chip diagram, each PCIe controller has its own separate AXI
>> interface to the NIC 301 AXI fabric, so having 3 independent nodes
>> which are not tied to the axi at 18000000 would not be wrong IMHO.
>
> I got impression that memory mapped blocks should preferably go into a
> "soc" node. It's what I seen in some other platforms and what is also
> present (thought not directly documented) in the dts-coding-style.rst .
>
> We don't have "soc" node but "axi at 18000000" seems like our substitute.
>
> So I thought we should keep PCIe controllers nodes in axi@ (soc@).
PCIe Host Bridges are sort of special because they are bridges but also
have a configuration interface via the MMIO register space. Tying them
to a particular bus node in the .dts(i) that accurately describes how
they are interfaced to the host CPU might be a tad difficult sometimes.
My preference as a maintainer would be to minimize the amount of node(s)
being changed and just isolate the 3 PCIe host bridges directly under
the root node.
Krysztof, any objection to that?
--
Florian
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4221 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20240424/8b6c46d2/attachment-0001.p7s>
More information about the linux-arm-kernel
mailing list