ARM64: PCI: do not enable resources on PROBE_ONLY systems

On ARM64 PROBE_ONLY PCI systems resources are not currently claimed, therefore they can't be enabled since they do not have a valid parent pointer; this in turn prevents enabling PCI devices on ARM64 PROBE_ONLY systems, causing PCI devices initialization to fail.

To solve this issue, resources must be claimed when devices are added on PROBE_ONLY systems, which ensures that the resource hierarchy is validated and the resource tree is sane, but this requires changes in the ARM64 resource management that can affect adversely existing PCI set-ups (claiming resources on !PROBE_ONLY systems might break existing ARM64 PCI platform implementations).

As a temporary solution in preparation for a proper resources claiming implementation in ARM64 core, to enable PCI PROBE_ONLY systems on ARM64, this patch adds a pcibios_enable_device() arch implementation that simply prevents enabling resources on PROBE_ONLY systems (mirroring ARM behaviour).

This is always a safe thing to do because on PROBE_ONLY systems the configuration space set-up can be considered immutable, and it is in preparation of proper resource claiming that would finally validate the PCI resources tree in the ARM64 arch implementation on PROBE_ONLY systems.

For !PROBE_ONLY systems resources enablement in pcibios_enable_device() on ARM64 is implemented as in current PCI core, leaving the behaviour unchanged.

PCI: generic: Claim bus resources on PCI_PROBE_ONLY set-ups

We claim PCI BAR and bridge window resources in pci_bus_assign_resources(), but when PCI_PROBE_ONLY is set, we treat those resources as immutable and don't call pci_bus_assign_resources(), so the resources aren't put in the resource tree.

When the resources aren't in the tree, they don't show up in /proc/iomem, we can't detect conflicts, and we need special cases elsewhere for PCI_PROBE_ONLY or resources without a parent pointer.

Claim all PCI BAR and window resources in the PCI_PROBE_ONLY case.

If a PCI_PROBE_ONLY platform assigns conflicting resources, Linux can't fix the conflicts. Previously we didn't notice the conflicts, but now we will, which may expose new failures.


The PCI host generic driver does not reassign bus resources on systems that require the BARs set-up to be immutable (ie PCI_PROBE_ONLY) since that would trigger system failures. Nonetheless, PCI bus resources allocated to PCI bridge and devices must be claimed in order to be validated and inserted in the kernel resource tree, but the current driver omits the resources claiming and relies on arch specific kludges to prevent probing failure (ie preventing resources enablement on PCI_PROBE_ONLY systems).

ARM64/PCI: Remove arch-specific pcibios_enable_device()

On systems with PCI_PROBE_ONLY set, we rely on BAR assignments from firmware. Previously we did not insert those resources into the resource tree, so we had to skip pci_enable_resources() because it fails if resources are not in the resource tree.

Now that we do insert resources even when PCI_PROBE_ONLY is set, we no longer need the ARM64-specific pcibios_enable_device(). Remove it so we use the generic version.


Where does arm64 claim PCI BAR resources for the non-PROBE_ONLY case?

arm64 (and arm) does not claim resources in arch code, they are always assigned in the respective host controllers (or the pcibios on arm), except for the PCI generic host when in PROBE_ONLY mode, where resources are neither claimed nor assigned (the reason for this patch to exist).

Certainly something to consolidate as part of the rework we talked about at LPC (PCI ACPI probing is yet another reason to consolidate it).

I know it must be there somewhere, but I don't see it.

It is not there, it is done in the host controllers by assigning the resources (which also "claim" them by assigning the parent pointer).

The host controller drivers should claim the apertures forwarded to the PCI bus. For pci-host-generic, this happens when gen_pci_parse_request_of_pci_ranges() calls devm_request_resource(). But that doesn't do anything for the BARs of the PCI devices themselves, of course.

Yes, the generic host claims the apertures at DT probing time.