[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