Re: [tip:x86/urgent] x86/quirks: Add early quirk to reset Apple AirPort card

From: Lukas Wunner
Date: Wed Jun 08 2016 - 16:05:47 EST


On Wed, Jun 08, 2016 at 11:56:14AM -0700, Yinghai Lu wrote:
> On Wed, Jun 8, 2016 at 7:23 AM, tip-bot for Lukas Wunner <tipbot@xxxxxxxxx> wrote:
> > --- a/arch/x86/kernel/early-quirks.c
> > +++ b/arch/x86/kernel/early-quirks.c
> ...
>
> Extend bus scan range part should be in separated patch?
>
> and put apple_airport_reset() related in second patch.

I had considered that but decided against it as it would make things
a bit more complicated for stable maintainers.

Nevertheless I'll be happy to split in two if this is the consensus?
I'm not sure though if x86/urgent is a rebasing branch?


> > +
> > + if ((type & 0x7f) == PCI_HEADER_TYPE_BRIDGE) {
> > + sec = read_pci_config_byte(num, slot, func, PCI_SECONDARY_BUS);
> > + early_pci_scan_bus(sec);
>
> How do you know that sec is valid ?
>
> How about on the system that have one bridge that still have sec num register 0?
>
> it will be get into dead loop.

Good point. I've just checked pci_scan_bridge() and it does verify that
and avoids recursing to a child bus if it's number is zero. It also
ensures that sec > num before recursing.

I can provide a follow-up patch to fix that, will wait a bit though to
see if there are further comments.


> > -void __init early_quirks(void)
> > +static void __init early_pci_scan_bus(int bus)
> > {
> > int slot, func;
> >
> > - if (!early_pci_allowed())
> > - return;
> > -
> > /* Poor man's PCI discovery */
> > - /* Only scan the root bus */
> > for (slot = 0; slot < 32; slot++)
> > for (func = 0; func < 8; func++) {
> > /* Only probe function 0 on single fn devices */
> > - if (check_dev_quirk(0, slot, func))
> > + if (check_dev_quirk(bus, slot, func))
> > break;
> > }
> > }
> > +
> > +void __init early_quirks(void)
> > +{
> > + if (!early_pci_allowed())
> > + return;
> > +
> > + early_pci_scan_bus(0);
> > +}
>
> Would just revert to scan domain 0, bus 0 to 255.

The commit message of 8659c406ade3 sounds like this would lengthen
boot time noticeably, so I expected significant backlash had I just
gone back to this old algorithm.

Thanks,

Lukas