On Sat, Dec 29, 2007 at 12:12:19AM +0300, Ivan Kokshaysky wrote:
quoted text
> 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). There is good reasons to think no such PCI-X 266Mhz/533 device
> > will ever have an extended-space (no capability IDs was ever defined in
> > the PCI-X 2.0 spec, no new revision is planned). Such a check would
> > avoid the possibility of trying extended-conf-space access for PCI-X 2.0
> > devices behind a amd-8132 or similar (such accesses would just returnd
> > -1, but there was some objections raised about doing anything like that
> > other than at initialization time, even if there is ample reasons to
> > argue it would be harmless).
> 
> 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.  There are relatively
few of them in existance, and my impression is that PCI-X2 is only being
implemented on server-class machines.  'Consumer grade' equipment is
where all the problems lie anyway.

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.

So I don't believe any change in this area is appropriate.

-- 
Intel are signing my paycheques ... these opinions are still mine
"Bill, look, we understand that you're interested in selling us this
operating system, but compare it to ours.  We can't possibly take such
a retrograde step."
--
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/