The problem is that in the event the MMCONFIG table is assigned to an
address range that conflicts with other devices, there's no guarantee
that MMCONFIG will have the higher decode priority. Apparently this is
exactly the case on some boards, the MMCONFIG is mapped on top of
chipset registers, and when we think we're accessing the MMCONFIG table
we're really scrambling random chipset registers and hosing things. So
we can't just blindly trust the values as being usable even when they
come directly from the chipset.
As I mentioned, though, really what we want to verify in this case is
that no other reserved resources fall inside the range being decoded by
the chipset. I may see if I can code something to do this. Essentially,
though, the existing patch effectively does this, on the assumption that
the board won't have conflicting reserved resources in the ACPI tables,
which is probably a safe assumption as Windows would likely be terribly
unhappy with that..
--
Robert Hancock Saskatoon, SK, Canada
To email, remove "nospam" from hancockr@nospamshaw.ca
Home Page: http://www.roberthancock.com/
-
