Re: [PATCH RESEND v2] x86/early-quirks: Scan all functions in early_pci_scan_bus()

[Bjorn Helgaas]

On Tue, Oct 27, 2026 at 09:31:07PM +0100, Thorsten Blum wrote:
> On Tue, Oct 27, 2026 at 03:13:38PM -0500, Bjorn Helgaas wrote:
> > On Tue, Oct 27, 2026 at 11:40:07AM +0100, Thorsten Blum wrote:
> > > On Mon, Oct 26, 2026 at 01:37:18PM -0500, Bjorn Helgaas wrote:
> > > > On Wed, Sep 16, 2026 at 12:02:07PM +0200, Thorsten Blum wrote:
> > > > > early_pci_scan_bus() stops scanning a PCI slot when check_dev_quirk()
> > > > > returns nonzero, which avoids probing functions 1-7 on single-function
> > > > > devices, but also stops scanning when a function is absent on a
> > > > > multifunction device.
> > > > > 
> > > > > This can skip early quirks on multifunction devices with holes in their
> > > > > function numbering.
> > > > > 
> > > > > On iMac13,1 and iMac13,2, the BCM4331 AirPort card is behind root port
> > > > > 00:1c.3, also documented by the model list in commit abb2bafd295f
> > > > > ("x86/quirks: Add early quirk to reset Apple AirPort card").
> > > > > 
> > > > > Public lspci output for 2012 iMacs [1][2] shows that 00:1c.0, 00:1c.2,
> > > > > 00:1c.3 and 00:1c.4 are present, but 00:1c.1 is missing. The old code
> > > > > stops at 00:1c.1 and never reaches 00:1c.3, so the AirPort reset quirk
> > > > > is silently skipped on these machines.
> > > > > 
> > > > > Check function 0 first, and if it indicates a multifunction device, scan
> > > > > functions 1-7 independently so that absent functions do not cause later
> > > > > ones to be skipped.
> > > > > 
> > > > > Fixes: 15650a2f644a ("x86/PCI: fixup early quirk probing")
> > > > > Cc: stable@xxxxxxxxxxxxxxx
> > > > > Signed-off-by: Thorsten Blum <blum@xxxxxxxxxx>
> > > > > Link: https://forum.libreelec.tv/thread/26799-wifi-not-detected-on-2012-imac-in-11-0/ [1]
> > > > > Link: https://zoringroup.com/forum/5/7170/ [2]
> > > > > Reviewed-by: Lukas Wunner <lukas@xxxxxxxxx>
> > > > 
> > > > Acked-by: Bjorn Helgaas <bhelgaas@xxxxxxxxxx>
> > > > 
> > > > Let me know if you'd prefer this to be merged via the PCI tree.
> > > 
> > > Thanks for the Ack.
> > > 
> > > I'd appreciate it if you could take this through the PCI tree.
> > 
> > I don't mind doing that but would like to have an ack from the x86
> > folks.
> 
> Does the Acked-by: from H. Peter Anvin count?
> 
> https://lore.kernel.org/lkml/74A9835A-4B16-409E-B13A-4C34FAB5DC8E@xxxxxxxxx/

I saw that and intended no slight to Peter, but MAINTAINERS says
"reviewer", suggesting he might want less responsibility.  I was
hoping for Thomas, Ingo, Boris, or Dave to step up, especially since
Dave did ask a question.

I'm guessing this is v7.5 material since 15650a2f644a dates to 2008
and abb2bafd295f dates to 2016?