[PATCH 0/4] Fix RP1 DeviceTree hierarchy and drop overlay support
Rob Herring
robh at kernel.org
Fri Dec 19 07:25:26 PST 2025
On Thu, Dec 18, 2025 at 08:09:05PM +0100, Andrea della Porta wrote:
> The current RP1 implementation is plagued by several issues, as follows:
>
> - the node name for RP1 is too specific and should be generic instead
> (see [1]).
>
> - the fully defined DTS has its PCI hierarchy wrongly described. There
> should be a PCI root port between the root complex and the endpoint
> (see [1]).
>
> - since CONFIG_PCI_DYNAMIC_OF_NODES can be dropped in the future
> becoming an automatically enabled feature, it would be wise to not
> depend on it (see [2]).
>
> - overlay support has led to a lot of confusion. It's not really usable
> right now and users are not even used to it (see [3]).
>
> This patch aims at solving the aforementioned problems by amending the
> PCI topology as follows:
>
> ...
> pcie at 1000120000 {
> ...
>
> pci at 0,0 {
> device_type = "pci";
> reg = <0x00 0x00 0x00 0x00 0x00>;
> ...
>
> dev at 0,0 {
> compatible = "pci1de4,1";
> reg = <0x10000 0x00 0x00 0x00 0x00>;
> ...
>
> pci-ep-bus at 1 {
> compatible = "simple-bus";
> ...
>
> /* peripherals child nodes */
> };
> };
> };
> };
>
> The reg property is important since it permits the binding the OF
> device_node structure to the pci_dev, encoding the BDF in the upper
> portion of the address.
>
> This patch also drops the overlay support in favor of the fully
> described DT while streamlining it as a result.
>
> Links:
> [1] - https://lore.kernel.org/all/aTvz_OeVnciiqATz@apocalypse/
> [2] - https://lore.kernel.org/all/CAL_JsqJUzB71QdMcxJtNZ7raoPcK+SfTh7EVzGmk=syo8xLKQw@mail.gmail.com/
> [3] - https://lore.kernel.org/all/CAL_JsqJUzB71QdMcxJtNZ7raoPcK+SfTh7EVzGmk=syo8xLKQw@mail.gmail.com/
>
> Andrea della Porta (4):
> dt-bindings: misc: pci1de4,1: add required reg property for endpoint
> misc: rp1: drop overlay support
> arm64: dts: broadcom: bcm2712: fix RP1 endpoint PCI topology
> arm64: dts: broadcom: rp1: drop RP1 overlay
Thanks for doing this.
Reviewed-by: Rob Herring <robh at kernel.org>
More information about the linux-arm-kernel
mailing list