tree 0f807067986ae5145945395aa499dd15c2291dac
parent 7a1562d4f2d01721ad07c3a326db7512077ceea9
author Yinghai Lu <yinghai@kernel.org> 1416432632 -0700
committer Bjorn Helgaas <bhelgaas@google.com> 1416432632 -0700

PCI: Support 64-bit bridge windows if we have 64-bit dma_addr_t

Aaron reported that a 32-bit x86 kernel with Physical Address Extension
(PAE) support complains about bridge prefetchable memory windows above 4GB:

  pci_bus 0000:00: root bus resource [mem 0x380000000000-0x383fffffffff]
  ...
  pci 0000:03:00.0: reg 0x10: [mem 0x383fffc00000-0x383fffdfffff 64bit pref]
  pci 0000:03:00.0: reg 0x20: [mem 0x383fffe04000-0x383fffe07fff 64bit pref]
  pci 0000:03:00.1: reg 0x10: [mem 0x383fffa00000-0x383fffbfffff 64bit pref]
  pci 0000:03:00.1: reg 0x20: [mem 0x383fffe00000-0x383fffe03fff 64bit pref]
  pci 0000:00:02.2: PCI bridge to [bus 03-04]
  pci 0000:00:02.2:   bridge window [io  0x1000-0x1fff]
  pci 0000:00:02.2:   bridge window [mem 0x91900000-0x91cfffff]
  pci 0000:00:02.2: can't handle 64-bit address space for bridge

In this kernel, unsigned long is 32 bits and dma_addr_t is 64 bits.
Previously we used "unsigned long" to hold the bridge window address.  But
this is a bus address, so we should use dma_addr_t instead.

Use dma_addr_t to hold the bridge window base and limit.

The question of whether the CPU can actually *address* the window is
separate and depends on what the physical address space of the CPU is and
whether the host bridge does any address translation.

[bhelgaas: fix "shift count > width of type", changelog, stable tag]
Fixes: d56dbf5bab8c ("PCI: Allocate 64-bit BARs above 4G when possible")
Link: https://bugzilla.kernel.org/show_bug.cgi?id=88131
Reported-by: Aaron Ma <mapengyu@gmail.com>
Tested-by: Aaron Ma <mapengyu@gmail.com>
Signed-off-by: Yinghai Lu <yinghai@kernel.org>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
CC: stable@vger.kernel.org	# v3.14+