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

[Benjamin Herrenschmidt <benh@kernel.crashing.org>]

On Sat, 2007-12-22 at 21:00 -0800, Linus Torvalds wrote:
> 
> On Sat, 22 Dec 2007, Jeff Garzik wrote:
> > 
> > But regardless of problems, enabling should be done globally, not per
> > device...
> 
> I'm ok with trying the "globally" idea, but it has to be "globally but 
> only if absolutely required".
> 
> And quite frankly, how do you tell whether it's absolutely required or 
> not?
> 
> I have an idea: the drivers that really need it will do a "please enable 
> MMCONFIG, because I will need it" thing?

What about this approach:

 - At boot, MMCONFIG is disabled, you perform the initial probe of all
devices.

 - During that probe, you set a flag if any device has capabilities that
extend beyond 0xff.

 - Once the main probe pass is done (before drivers are hooked up, which
on PCI is a separate phase), if that flag has been set, you print a fat
warning (on peecee's, which are our main concern, this will generally be
visible on vga console), that you're about to enable MMCONFIG for this
device and if the machine crashes, send a bug report and boot with
nommconfig. Then, for each of those devices, attempt to re-read the
config space header with MMCONFIG, and compare to what is supposed to be
there (+/- irrelevant status bits). If that fails, warn and keep
MMCONFIG disabled.

At this point, you can decide to either keep MMCONFIG on/off on a
per-device basis (if a device has capabilities in the ext space, use
MMCONFIG for it). In that case, your proposed API is useful to
force-enabling MMCONFIG for a given device if there are no such
capabilities but the driver wants to force-enable. That case should be
extremely rare if existing at all

Or you can decide to keep the enable/disable global (if a single device
fails, don't enable MMCONFIG globally).

Ben.


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