summaryrefslogtreecommitdiffstats
path: root/src/drivers/net/intel.c
diff options
context:
space:
mode:
authorMichael Brown2014-07-16 16:27:16 +0200
committerMichael Brown2014-07-16 16:39:59 +0200
commitae778091cac3e6324d0f4876bcc12869679c26e4 (patch)
treefb1c85795bf6a92cf21c89332ec954a9e1169b5c /src/drivers/net/intel.c
parent[efi] Use EFI_CONSOLE_CONTROL_PROTOCOL to set text mode if available (diff)
downloadipxe-ae778091cac3e6324d0f4876bcc12869679c26e4.tar.gz
ipxe-ae778091cac3e6324d0f4876bcc12869679c26e4.tar.xz
ipxe-ae778091cac3e6324d0f4876bcc12869679c26e4.zip
[ioapi] Fail ioremap() when attempting to map a zero bus address
When a 32-bit iPXE binary is running on a system which allocates PCI memory BARs above 4GB, our PCI subsystem will return the base address for any such BARs as zero (with a warning message if DEBUG=pci is enabled). Currently, ioremap() will happily map an address pointing to the start of physical memory, providing no sensible indication of failure. Fix by always returning NULL if we are asked to ioremap() a zero bus address. With a totally flat memory model (e.g. under EFI), this provides an accurate failure indication since no PCI peripheral will be mapped to the zero bus address. With the librm memory model, there is the possibility of a spurious NULL return from ioremap() if the bus address happens to be equal to virt_offset. Under the current virtual memory map, the NULL virtual address will always be the start of .textdata, and so this problem cannot occur; a NULL return from ioremap() will always be an accurate failure indication. Debugged-by: Anton D. Kachalov <mouse@yandex-team.ru> Signed-off-by: Michael Brown <mcb30@ipxe.org>
Diffstat (limited to 'src/drivers/net/intel.c')
0 files changed, 0 insertions, 0 deletions