Well, we are talking about using a different method to access the
extended config space only. This space is independent from the legacy
config space.
not really. In many ways it's the same space.
I don't see how mixing the old and new methods like this could lead to
any problem, we are not going to mix them to access the same registers.
the spec simply doesn't allow it. Sure it may work on your machine today,
but that doesn't make it a good idea ;)
We need to improve this "mmconfig disabled" anyhow. Having the extended
config space unavailable on lots of machines is also far from a viable
solution :)
it's unlikely to be many machines though.
If you still do not like this first proposal, what do you
think of my other one ? (having chipset-specific checks in
pci_mmcfg_init to find out for sure whether mmconfig will work)
I'm all in favor of a more detailed test; just we HAVE to have a test
for this since it's simply broken too often. What the test needs to do
is check if the MCFG entry actually points to a working mmconfig area,
so 1) that it actually points to an mmconfig area and not to garbage, and 2)
that accesses to it actually work ;)
the current approach doesn't test 2) realistically, only 1), but if you weaken
the 1) test as you propose you really ought to substitute it with a 2) test...
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
