Arjan van de Ven wrote:
> Brice Goglin wrote:er.
>>
>> What would you think of a patch implementing the following strategy:
>> 1) if MMCONFIG works, always use it (no change)
>> 2) if MMCONFIG is disabled and we are accessing the regular config
>> space, use direct conf (no change, should ensure that any machine will
>> still boot fine)
>> 3) if MMCONFIG is disabled but we are accessing the _extended_ config
>> space, try mmconfig anyway since there's no other way to do it.
>
> an OS isn't allowed to mix old and new access methods realistically so
> I don't think
> this is a viable good solution...
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.
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.
But I agree with Andi about the possible dangerousness.
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 :) 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)
Thanks,
Brice
-
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]
