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 <[email protected]> > --- > 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
