summaryrefslogtreecommitdiff
path: root/drivers/crypto
diff options
context:
space:
mode:
authorLinus Torvalds <torvalds@woody.linux-foundation.org>2007-12-28 05:21:36 (GMT)
committerLinus Torvalds <torvalds@woody.linux-foundation.org>2007-12-28 05:21:36 (GMT)
commitad7edfe0490877864dc0312e5f3315ea37fc4b3a (patch)
tree5d73689cca22b683866d8c77406aefc26dbf7f40 /drivers/crypto
parentc68cb23dde29fb107575656effa46f7b9440ac04 (diff)
downloadlinux-fsl-qoriq-ad7edfe0490877864dc0312e5f3315ea37fc4b3a.tar.xz
[PCI] Do not enable CRS Software Visibility by default
It appears that some PCI-E bridges do the wrong thing in the presense of CRS Software Visibility and MMCONFIG. In particular, it looks like an ATI bridge (device ID 7936) will return 0001 in the vendor ID field of any bridged devices indefinitely. Not enabling CRS SV avoids the problem, and as we currently do not really make good use of the feature anyway (we just time out rather than do any threaded discovery as suggested by the CRS specs), we're better off just not enabling it. This should fix a slew of problem reports with random devices (generally graphics adapters or fairly high-performance networking cards, since it only affected PCI-E) not getting properly recognized on these AMD systems. If we really want to use CRS-SV, we may end up eventually needing a whitelist of systems where this should be enabled, along with some kind of "pcibios_enable_crs()" query to call the system-specific code. Suggested-by: Loic Prylli <loic@myri.com> Tested-by: Kai Ruhnau <kai@tragetaschen.dyndns.org> Cc: Matthew Wilcox <matthew@wil.cx> Cc: Greg Kroah-Hartman <greg@kroah.com> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Diffstat (limited to 'drivers/crypto')
0 files changed, 0 insertions, 0 deletions