Looks good. I had two remaining comments, neither of which should block merging:

1. I think this would be better to inherit from ofwpci than pci_generic, since the code just works around all the things pci_generic adds to ofwpci.
2. The DTS bindings being used don't match the vendor ones. Barring some compelling reason to diverge, I think we should use the vendor's device trees.

In general, pci_generic contains one feature which ofw_pci lacks: it's able to enumerate devices which are present in DTS under the PCI-controller node, which are not PCI devices. I know this is a mess and does not comply with standard nor logic, but some arm64-vendors are using this type of DTSes and by now it is hard to convince them to fix DTS once it's already been put into production.

I'd leave Alpine PCI controller being a child of generic_pci like all others arm64 systems until we come up with a solution that can flawlessly merge both arm64 and x86 worlds not loosing any functionality.

In D7571#161529, @wma wrote:

In general, pci_generic contains one feature which ofw_pci lacks: it's able to enumerate devices which are present in DTS under the PCI-controller node, which are not PCI devices. I know this is a mess and does not comply with standard nor logic, but some arm64-vendors are using this type of DTSes and by now it is hard to convince them to fix DTS once it's already been put into production.

That is quite strange, but is supported by ofwpci as well, at least if used in conjunction with ofw_pcibus.c. However, I now see that ofw_pcibus.c and ofw_pcib_pci.c were never moved from /sys/powerpc/ofw like ofwpci.c was. Let's leave this as pcie_generic for the time being and then move over the remainder of the PowerPC PCI support code, which is all actually machine-independent.

it's able to enumerate devices which are present in DTS under the PCI-controller node, which are not PCI devices

I don't think that this is right. The nodes under PCI-controller node describes configuration for individual ports of PCIe root complex, these are part of PCIe-controller configuration.
These are not a independent devices at all so instantiation new newbus devices for them looks like pure nonsense.

In D7571#161544, @meloun-miracle-cz wrote:

it's able to enumerate devices which are present in DTS under the PCI-controller node, which are not PCI devices

I don't think that this is right. The nodes under PCI-controller node describes configuration for individual ports of PCIe root complex, these are part of PCIe-controller configuration.
These are not a independent devices at all so instantiation new newbus devices for them looks like pure nonsense.

Per the spec, device tree children are supposed to be PCI devices. I assume these are (potentially fictional) PCI<->PCI bridges for the root ports? Those are what I've always seen, anyway.

Yes and no :) .
These nodes doesn't have 'compatible' property, so doesn't have driver. It's job of PCI(e) driver to read and use them (assign lanes to ports, allocate memory for memory mapped configuration space ...)

Please see one (documented) example:
https://github.com/torvalds/linux/blob/master/Documentation/devicetree/bindings/pci/nvidia%2Ctegra20-pcie.txt#L113
and
https://github.com/torvalds/linux/blob/master/arch/arm/boot/dts/tegra124.dtsi#L53