Re: pci-disable-decode-of-io-memory-during-bar-sizing.patch

!MAILaRCHIVE_VOTE_RePLACE
Previous message: [thread] [date] [author]
Next message: [thread] [date] [author]
To: Arjan van de Ven <arjan@...>
Cc: Robert Hancock <hancockr@...>, Greg KH <greg@...>, Jesse Barnes <jbarnes@...>, <akpm@...>, <ak@...>, <rajesh.shah@...>, linux-kernel <linux-kernel@...>
Date: Tuesday, October 30, 2007 - 1:07 pm

On Tue, 30 Oct 2007, Arjan van de Ven wrote:

You have to, anyway. Even now the MMCONFIG stuff uses CONF1 cycles for 
startup.

Also, there's reason to believe that mixing things up _has_ to work 
anyway, and if the issue is between "works in practice" and "theory says 
that you shouldn't mix", I'll take practice every time.

Especially since we *know* that the theory is broken. Right now MMCONFIG 
is effectively disabled very aggressively because it's simply unusably 
flaky. So the choice is between:

 - don't use MMCONFIG at all, because it has so many problems
 - use MMCONFIG sparingly enough to hide the problems

and what "you're supposed to do" is simply trumped by Real Life(tm). 
Because Intel screwed up so badly when they designed that piece of shit.

(Where "screwed up badly" is the usual "left it to firmware people" thing, 
of course. Dammit, Intel *could* have just made it a real PCI BAR in the 
Northbridge, and specified it as such, and we wouldn't have these 
problems! But no, it had to be another idiotic "firmware tells where it 
is" thing)


No.

Maybe if you do it per-device, and only *after* probing (ie we have seen 
multiple, and successful, accesses), but globally, absolutely not. That 
would be useless. The bugs we have had in this area have been exactly the 
kinds of things like "we don't know the real size of the MMCONFIG areas" 
etc.

I could easily see device driver writers probing to see if something 
works, and I absolutely don't think we should just automatically enable 
MMCONFIG from then on.

But maybe we could have a per-device flag that a driver *can* set. Ie have 
the logic be:

 - use MMCONFIG if we have to (reg >= 256)

OR

 - use MMCONFIG if the driver specifically asked us to

and then drivers that absolutely need it, and know they do, can set that 
flag. Preferably after they actually verified that it works.

That way you _can_ get the "this is how you're supposed to do it" 
behaviour, but you get it when there is a reasonable chance that it 
actually works.

And quite frankly, if you're not supposed to mix these things even across 
devices, then I think we are better off just doing what we effectively do 
now: mostly ignore the damn thing because it's too broken to use.

Maybe somebody inside Intel could just clarify the documentation, and 
change it from "you're not supposed to mix" to "mix all you want". 

		Linus
-
Previous message: [thread] [date] [author]
Next message: [thread] [date] [author]

Messages in current thread:
Re: pci-disable-decode-of-io-memory-during-bar-sizing.patch, Linus Torvalds, (Tue Oct 30, 11:15 am)
Re: pci-disable-decode-of-io-memory-during-bar-sizing.patch, Arjan van de Ven, (Tue Oct 30, 12:47 pm)
Re: pci-disable-decode-of-io-memory-during-bar-sizing.patch, Linus Torvalds, (Tue Oct 30, 1:07 pm)
Re: pci-disable-decode-of-io-memory-during-bar-sizing.patch, Arjan van de Ven, (Tue Oct 30, 7:52 pm)
Re: pci-disable-decode-of-io-memory-during-bar-sizing.patch, Arjan van de Ven, (Tue Oct 30, 1:28 pm)
Re: pci-disable-decode-of-io-memory-during-bar-sizing.patch, Arjan van de Ven, (Thu Nov 1, 10:08 am)