https://bugzilla.kernel.org/show_bug.cgi?id=213079
--- Comment #4 from Erhard F. (erhar...@mailbox.org) --- Created attachment 297191 --> https://bugzilla.kernel.org/attachment.cgi?id=297191&action=edit bisect.log Turns out the problem was introduced between v5.11 and v5.12 by following commit: # git bisect good fbbefb320214db14c3e740fce98e2c95c9d0669b is the first bad commit commit fbbefb320214db14c3e740fce98e2c95c9d0669b Author: Oliver O'Halloran <ooh...@gmail.com> Date: Tue Nov 3 15:35:07 2020 +1100 powerpc/pci: Move PHB discovery for PCI_DN using platforms Make powernv, pseries, powermac and maple use ppc_mc.discover_phbs. These platforms need to be done together because they all depend on pci_dn's being created from the DT. The pci_dn contains a pointer to the relevant pci_controller so they need to be created after the pci_controller structures are available, but before PCI devices are scanned. Currently this ordering is provided by initcalls and the sequence is: 1. PHBs are discovered (setup_arch) (early boot, pre-initcalls) 2. pci_dn are created from the unflattended DT (core initcall) 3. PHBs are scanned pcibios_init() (subsys initcall) The new ppc_md.discover_phbs() function is also a core_initcall so we can't guarantee ordering between the creation of pci_controllers and the creation of pci_dn's which require a pci_controller. We could use the postcore, or core_sync initcall levels, but it's cleaner to just move the pci_dn setup into the per-PHB inits which occur inside of .discover_phb() for these platforms. This brings the boot-time path in line with the PHB hotplug path that is used for pseries DLPAR operations too. Signed-off-by: Oliver O'Halloran <ooh...@gmail.com> [mpe: Squash powermac & maple in to avoid breakage those platforms, convert memblock allocs to use kmalloc to avoid warnings] Signed-off-by: Michael Ellerman <m...@ellerman.id.au> Link: https://lore.kernel.org/r/20201103043523.916109-2-ooh...@gmail.com -- You may reply to this email to add a comment. You are receiving this mail because: You are watching the assignee of the bug.
