Re: [patch] Make MMCONFIG space (extended PCI config space) a driver opt-in issue

[Jeff Garzik <jeff@garzik.org>]

Loic Prylli wrote:
> Supporting extended-conf-space is independant of the issue of using
> mmconf for legacy conf-space.

True.


> There is no real reason to use the same
> method to access both. I have seen several arguments used that were
> implying that, and they all seem really bogus to me. Not only are the
> two ranges (<= 256 and >= 256) structurally independant (you have
> totally independant capabilities lists that are independantly organized
> in each of them), even if they were not there is no consistency issue
> that cannot be dealt with a memory barrier, and the concern about taking
> an extra branch for each pci-conf-space access is also bogus once you
> look at the numbers.
> 
> By possibly using different implementations for the two ranges you avoid
> introducing a new API, you avoid taking risks with mmconf when you don't
> need it. That doesn't preclude using mmconf for everything either if the
> user requests it or based on enough knowledge of the system to be sure
> nothing will break.

Are you prepared to guarantee that freely mixing mmconfig and type1 
config accesses at runtime will always work, on all chipsets?  I'm 
talking about silicon here, not kernel software.

Furthermore, is it best for our users to find problems with mixed config 
accesses -- not at boot time, not at driver load time, but at some 
random time when some random driver does its first extended config space 
access?  IMO, no.  If you are going to fail, failing in a predictable, 
visible way is best.

Failures are more predictable and more consistent with an all-or-none 
scenario.  The all-or-none solutions are the least complex on the 
software side, and far more widely tested than any mixed config access 
scheme.

	Jeff