On Sun, 13 Jan 2008 00:49:11 +0300
Ivan Kokshaysky <ink@jurassic.park.msu.ru> wrote:

quoted text
> On Sat, Jan 12, 2008 at 09:45:57AM -0800, Arjan van de Ven wrote:
> > btw this is my main objection to your patch; it intertwines the
> > conf1 and mmconfig code even more.
> 
> There is nothing wrong with it; please realize that mmconf and conf1
> are just different cpu-side interfaces. Both produce precisely the
> *same* bus cycles as far as the lower 256-byte space is concerned.
> 
> > When (and I'm saying "when" not "if") systems arrive that only have
> > MMCONFIG for some of the devices, we'll have to detangle this again,
> > and I'm really not looking forward to that.
> 
> MMCONFIG for *some* of the devices? This doesn't sound realistic
> from technical point of view.

you're wrong. 

quoted text
> MMCONFIG-only systems? Sure. I really hope to see these. But it won't
> be PC-AT architecture anymore. It has to be something like alpha,
> for instance, fully utilizing the 64-bit address space, and we'll have
> to have the whole low-level PCI infrastructure completely different
> for these future platforms anyway.
> Right now, each and every x86 chipset *does* require working
> conf1 just in order to set up the mmconf aperture. It's the very
> fundamental thing, sort of design philosophy.

s/x86/pc/

and not even that.

Really this is a huge design mistake in your patch, the hard coding of conf1,
and for that reason I really don't think it should go in.

We have 4 or so methods on PC today to access config space, probably going to 6 in the next year
or two. One of those methods *HARD PICKING* another one as "second best" for cases where it
doesn't want to deal with is WRONG. It really needs to be up to the architecture/platform
to decide which ops vector is the fallback. And yes on your current PC that might well be conf1.
But hardcoding that is not the right thing. We have the vectors, we have the ranking code,
just make a "second rank" thing. 
Oh wait, my patch did that ;)
Then let either the mmconfig code or the wrapper above it (doesn't matter, in fact, I can see
value of making this decision in the wrapper and keep mmconfig code simple and clean,
because maybe mmconfig IS the thing that the architecture says needs to deal with the lower 256 bytes)..

Oh wait my patch also did that pretty much ;)

The rest of my patch was defaulting to off. Is it that bit that you really hate?


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