lkml.org 
[lkml]   [2007]   [Dec]   [23]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [patch] Make MMCONFIG space (extended PCI config space) a driver opt-in issue


On Sun, 23 Dec 2007, Ivan Kokshaysky wrote:
>
> This is a result of all-or-none approach, as mmconfig is fundamentally
> unsafe until after PCI init is done.

Yes. One of the things I want to have happen (and which
"pci_enable_mmconf()" would do automatically) is that we always probe
using conf1 cycles in any machine where conf1 works at all.

Then, some late PCI quirk or some per-device quirk (or driver) can decide
to enable mmconf later, and that avoids the current nightmare with the
whole resource ordering.

Of course, if there really are machines that have somehow disabled conf1
accesses, we'd have to use mmconfig early, but that should automatically
be handled by the PCI config probing stuff (ie we already test whether
conf1 accesses seem to work, and would fall back on alternate config
cycle accesses if conf1 looks broken).

Right now, the check that MMCONF space has to be in e820-reserved memory
space protects us from *most* of the probe-time problems, but that's also
obviously the check that actually means that MMCONF isn't actually used on
the vast majority of machines out there.

(For example: I have three machines that I know have working MMCONF. On
only one of theose does Linux actually even enable MMCONF accesses,
because on the two other ones the BIOSes do the crazy "put it in some
space that is reserved by PnP crap later", so we actually refuse to touch
it. So at least in my limited environment, we hardly get any MMCONFIG test
coverage, exactly because we have to be so totally anal about not enabling
it early, because we cannot guarantee that it's not clashing with anything
else).

Linus


\
 
 \ /
  Last update: 2007-12-23 18:35    [W:0.163 / U:0.252 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site