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

From: Jeff Garzik
Date: Sun Dec 23 2007 - 00:44:54 EST


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


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/