[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