summaryrefslogtreecommitdiffstats
path: root/drivers/net
diff options
context:
space:
mode:
authorBjorn Helgaas <bjorn.helgaas@hp.com>2009-11-04 18:39:18 +0100
committerJesse Barnes <jbarnes@virtuousgeek.org>2009-11-04 22:06:46 +0100
commit03db42adfeeabe856dbb6894dd3aaff55838330a (patch)
treef78101e96ce2171a503bd1119d08d89e31118a69 /drivers/net
parentx86/PCI: for debuggability, show host bridge windows even when ignoring _CRS (diff)
downloadlinux-03db42adfeeabe856dbb6894dd3aaff55838330a.tar.xz
linux-03db42adfeeabe856dbb6894dd3aaff55838330a.zip
x86/PCI: fix bogus host bridge window start/end alignment from _CRS
PCI device BARs are guaranteed to start and end on at least a four-byte (I/O) or a sixteen-byte (MMIO) boundary because they're aligned on their size and the low BAR bits are reserved. PCI-to-PCI bridge apertures have even larger alignment restrictions. However, some BIOSes (e.g., HP DL360 BIOS P31) report host bridge windows like "[io 0x0000-0x2cfe]". This is wrong because it excludes the last port at 0x2cff: it's impossible for a downstream device to claim 0x2cfe without also claiming 0x2cff. In fact, this BIOS configures a device behind the bridge to "[io 0x2c00-0x2cff]", so we know the window actually does include 0x2cff. This patch rounds the start and end of apertures to the appropriate boundary. I experimentally determined that Windows contains a similar workaround; details here: http://bugzilla.kernel.org/show_bug.cgi?id=14337 Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Diffstat (limited to 'drivers/net')
0 files changed, 0 insertions, 0 deletions