[PATCH 2/5] arm/pci: Use official API to iterate over PCI buses
Gerd Bayer
gbayer at linux.ibm.com
Mon May 18 08:45:50 PDT 2026
On Fri, 2026-05-15 at 16:22 +0200, Gerd Bayer wrote:
> Replace iterating over pci_root_buses with the official
> pci_find_next_bus() call provided by PCI core. This allows to make
> pci_root_buses private to PCI core.
>
> Signed-off-by: Gerd Bayer <gbayer at linux.ibm.com>
> ---
> arch/arm/kernel/bios32.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm/kernel/bios32.c b/arch/arm/kernel/bios32.c
> index ac0e890510da..35642c9ba054 100644
> --- a/arch/arm/kernel/bios32.c
> +++ b/arch/arm/kernel/bios32.c
> @@ -59,9 +59,9 @@ static void pcibios_bus_report_status(struct pci_bus *bus, u_int status_mask, in
>
> void pcibios_report_status(u_int status_mask, int warn)
> {
> - struct pci_bus *bus;
> + struct pci_bus *bus = NULL;
>
> - list_for_each_entry(bus, &pci_root_buses, node)
> + while ((bus = pci_find_next_bus(bus)) != NULL)
> pcibios_bus_report_status(bus, status_mask, warn);
> }
>
Hi Russell,
Sashiko
https://sashiko.dev/#/message/20260515145940.E85AAC2BCB0%40smtp.kernel.org
reported:
> Since pci_find_next_bus() unconditionally acquires the pci_bus_sem read-write
> semaphore using down_read(), this introduces a blocking operation into that
> atomic path:
>
> dc21285_abort_irq() [hardirq context]
> pcibios_report_status()
> pci_find_next_bus()
> down_read(&pci_bus_sem) [sleeps]
>
> Does this path need an alternative approach to safely iterate over the buses
> without taking a sleeping lock?
IMHO, it looks like this entire pcibios_report_status() iterating over
all PCI buses and all their devices would be better off if moved
outside of the hardirq context?
Or could pcibios_report_status() be converted to use
for_each_pci_device()?
Any suggestions welcome...
Gerd
More information about the linux-arm-kernel
mailing list