Date:	Sun, 13 Jan 2008 02:19:03 -0500
From:	Loic Prylli <loic@...i.com>
To:	Matthew Wilcox <matthew@....cx>
CC:	Ivan Kokshaysky <ink@...assic.park.msu.ru>,
	Arjan van de Ven <arjan@...radead.org>,
	Daniel Barkalow <barkalow@...ervon.org>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Kai Ruhnau <kai@...getaschen.dyndns.org>,
	Robert Hancock <hancockr@...w.ca>,
	Jeff Garzik <jeff@...zik.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	gregkh@...e.de, linux-pci <linux-pci@...ey.karlin.mff.cuni.cz>,
	Benjamin Herrenschmidt <benh@...nel.crashing.org>,
	Martin Mares <mj@....cz>
Subject: Re: [Patch v2] Make PCI extended config space (MMCONFIG) a driver
 opt-in



On 1/13/2008 1:01 AM, Matthew Wilcox wrote:
> On Sat, Dec 29, 2007 at 12:12:19AM +0300, Ivan Kokshaysky wrote:
>   
>> On Fri, Dec 28, 2007 at 12:40:53PM -0500, Loic Prylli wrote:
>>     
>>> One thing that could be changed in pci_cfg_space_size() is to avoid
>>> making a special case for PCI-X 266MHz/533Mhz (assume cfg_size == 256
>>> for such devices too, reserve extended cfg-space for pci-express
>>> devices). 
>>>       
>> I agree, we should remove it. IIRC, this PCI-X check was written
>> long ago with some draft (not a final spec) in hands. Matthew?
>>     
>
> I have what I believe to be the released version of PCI-X 2.0a (July
> 22, 2003).  It is quite clear that Mode 2 devices (ie those running at
> 266MHz or 533MHz) are required to support all 4096 bytes of extended
> config space.
>
> More to the point, I don't think we have any bug reports suggesting that
> PCI-X Mode 2 devices/bridges have any problems. 



As PCI-X2 bridge/chipset, I only knows about the AMD-8132 (from what I 
understand it does PCI-X Mode 2), and some obscure IBM enterprise 
chipset (I am sure there are a few more).



Too bad for the spec, but we definitely know for sure the AMD-8132 
doesn't do ext-space (and makes it unusable for any device behind it).



> There are relatively
> few of them in existance, and my impression is that PCI-X2 is only being
> implemented on server-class machines. 



True.



>  'Consumer grade' equipment is
> where all the problems lie anyway.
>   



mmconfig has been a pain on the servers too (there are a lot of server 
class amd machines using one pcie/mmconfig/chipset + amd-8131/2).


> While the PCI-X 2.0a spec does not define any Extended Capability IDs,
> it simply states that "This field is a PCI-SIG defined ID number that
> indicates the nature and format of the Extended Capabilities List item".
> The PCIe spec does define Extended Capability IDs, and I would think
> it's entirely appropriate to use the same IDs for PCI-X Mode 2 devices.
>   


Sure it might be needed on PCI-X2. But contrary to pcie (where the 
driver/pci/pcie/aer subsystem already use ext-conf-space, and other 
usages are bound to increase), needing ext-conf-space in the future on 
pci-x2 is quite unlikely (pcie is long-lived, whereas PCI-X2 was 
short-lived, obsoleted by PCI-E, and nobody has mentioned yet an example 
of using ext-registers with a PCI-X2 device).

I was only mentioning that because of the very small trade-off:  if you 
don't exclude PCI-X2, on platforms with the amd-8132+bad-MCFG, you might 
trigger a cfg-read==0xffffffff/master-abort in pci_cfg_space_size() for 
such devices with Ivan patch. This is harmless, because a lot of similar 
master-abort happen during PCI-probing anyway, so one more won't change 
anything.


Anyway, I am equally happy with keeping pci_cfg_space_size() as it is.


Loic

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

Powered by blists - more mailing lists