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

[Tony Camuso]

Arjan van de Ven wrote:
> On Sat, 12 Jan 2008 20:36:59 -0500
> Tony Camuso <tcamuso@xxxxxxxxxx> wrote:
>
>
> Just about NOBODY has devices that need the extended config space. At all.

The PCI express spec requires the platform to provide access to this space
for express-compliance. More devices will be using this space as express
becomes the dominant IO bus technology.

> > As far as the device is concerned, after the Northbridge translates
> > the config access into PCI bus cycles, the device has no idea what
> > mechanism drove the Northbridge to the translation.
>
> Wanne bet there'll be devices that screw this up? THere's devices that even screwed
> up the 64-256 region after all.

There may have been devices that incorrectly applied the PCI spec to
various fields in the header, I'll grant you that.

However, there is no way a device can determine electrically whether the
Northbridge received Port IO or MMCONFIG cycles. This is between the CPU
and the Northbridge and is utterly opaque to the devices on the bus.

> > The patch I devised concerned itself with Northbridges and separated
> > MMCONFIG-compliant buses from those that could not handle MMCONFIG.
>
> THis kind of patchup has been going on for the better part of a year (well 2 years)
> by now and it's STILL NOT ENOUGH, as you can see by the more patchups that have
> been proposed as "alternative" to my approach.

Which is why Loic's proposal and Ivan's implementation of it is so elegant.
It solves all these problems in one sweep, and eliminates the code rendered
cruft by Ivan's patch. A two-fer, by my reckoning.

> > In other words, for x86, I don't think we need to worry about Port
> > IO config access ever going away at all.
>
> You're wrong there. Sad to say, but you're wrong there.

The PCI spec provides for conf1 as an architected solution. It's not
going away, and especially not in x86 land where Port IO is built-in
to the CPU.



--
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/