Cc: Ingo Molnar <mingo@...>, Thomas Gleixner <tglx@...>, H. Peter Anvin <hpa@...>, Andrew Morton <akpm@...>, Jesse Barnes <jbarnes@...>, <linux-kernel@...>
Well, I'm not sure whether PnP or e820 should be first, as long as any
"real hardware" probing takes precedence over either. I _suspect_ that
e820 is more trustworthy, which implies that PnP should probably be added
last. It would be good to have some idea what Windows does, since usually
all the firmware bugs are essentially hidden by whatever that other OS
happens to do.
The basic rule really should be: "What do we trust most?" and probe things
in that order.
So e820 is fairly trustworthy, but we know that it will have various
random things marked as reserved because they are special in some way (but
we don't know _how_ they are special - they may well be real BAR's that
just have a fixed meaning to ACPI or whatever).
But we obviously trust _part_ of it (the RAM stuff) more than we trust
other parts. So it does make sense to consider that separately.
PnP I personally wouldn't trust at all, except as a way to keep dynamic
resources away from those things, which is why I'd put it last. But that's
just my personal gut feeling.
Hardware we generally trust more than any firmware, but even hardware can
have bugs. And some classes of hardware tends to be less buggy than others
(ie I'd trust some on-die APIC base pointer before I would trust a Cardbus
controller BAR, for example).
But yes, I think your patch looks like it is definitely moving in the
right direction. If this means that we can now do PCI probing without
having the BAR's move around because they also happened to be covered by
an e820 map, then that sounds like a good thing.
Of course, I bet there will be cases where this causes problems. It feels
like we have _never_ worked around some PCI BAR allocation problem without
hitting another unexpected one..
Linus
--
