On Monday 04 February 2008 02:16:52 pm Linus Torvalds wrote:
quoted text
> 
> On Mon, 4 Feb 2008, Bjorn Helgaas wrote:
> > 
> So where in this would you put the
> 
> 	pcibios_init() -> pcibios_resource_survey()
> 
> call (it's a subsys_initcall)?
> 
> THAT is the thing that actually registers the PCI resurces we've found 
> into the resource tree!

I think pcibios_init() currently happens after we register
ACPI & PNP drivers, i.e., at 3 below:

  1) enumerate PNP & ACPI devices
  2) initialize PNP & ACPI drivers
     2a) register ACPI PCI root bridge driver, which enumerates PCI
         devices behind the bridge
     2b) register PNP system driver and reserve resources (this is
         where the current quirk skips some reservations)
  3) pcibios_init() -> pcibios_resource_survey()
  4) initialize PCI drivers
     4a) register intel8x0 sound driver and reserve resources
         (conflict happens here)

quoted text
> The ACPI/PnP tables shouldn't be able to break the enumeration of the 
> actual hardware devices, now should it?

Well, no :-)  We have to make PNP & ACPI smart enough to not cause
trouble, and I fully accept that the burden is on PNP.

But PNPBIOS and ACPI by definition are for devices that don't have
their own enumeration protocol.  Obviously, we have a lot of legacy
drivers that blindly probe for devices at magic addresses, but
that's validating guesswork, not actually enumerating anything.

In this particular case, we can easily enumerate all the PCI devices
in domain 0.  But for machines that have multiple PCI domains, I don't
think we want to exhaustively scan all possible domains.  ACPI tells us
what root bridges exist and what domain each is in, so we can scan a
little more efficiently.

quoted text
> We should enumerate the PCI devices, then register their resources (and 
> no, I'm not at *all* convinced it should happen as a separate 
> subsys_initcall), and then register the PnP resources. 
> 
> So I think we should have roughly something like:
> 
>  - arch_initcall: this could enumerate the ACPI/PnP devices (but not 
>    register anything). Alternatively, do it as subsys_initcall, and just
>    make sure it happens early with link-order.

Scanning PCI buses has to happen here, which currently means that we
have to register the ACPI PCI root driver so we know which domains and
buses to scan.

quoted text
>  - subsys_initcall: this should do that pcibios_init() thing that surveys 
>    the resources (and the PCI enumeration needs to have happened before, 
>    probably in the same initcall thanks to link order)
> 
>  - PnP/ACPI resource allocation *after* it, but before driver loading 
>    (which wll cause new resources to be allocated). This could be 
>    fs_initcall, or whatever (that's what things like "acpi_event_init" 
>    already do).

If we put the PNP system driver here, we can easily do a quirk that
ignores PNP resources that overlap PCI resources.  But it's kind of
ugly to have the ACPI PCI root driver early and other PNP drivers
later because they're basically similar animals.

quoted text
>  - regular drivers will come along much later, as part of 
>    driver_initcall, and by the time this happens, we've now reserved all 
>    resources we know about.
> 
> Basically, we just want to register the most trust-worthy resources before 
> we register anything less trust-worthy. And actual device probing simply 
> tends to be more trust-worthy than any randomly broken ACPI/PnP tables.

I agree that PCI BARs are likely more trustworthy than firmware
tables.  Maybe we could figure out a way to do the PNP reservations,
then revert them if we find an overlapping PCI BAR.

Does anybody with this motherboard (or the Supermicro board with
similar SATA problems) also have Windows on it?  I'm curious to
see how Windows deals with this conflict, e.g., what shows up in
the device manager?

Bjorn
--
unsubscribe notice
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/