summaryrefslogtreecommitdiff
path: root/drivers/input/pc_keyb.c
diff options
context:
space:
mode:
authorStephen Warren <swarren@nvidia.com>2016-01-29 16:10:04 -0700
committerSimon Glass <sjg@chromium.org>2016-02-09 15:41:19 -0700
commit986fe378172fa4bd5be1432ab2f8f7c2b1c43bae (patch)
tree643948b0e7d77d99ae113978bf435623bd92af1e /drivers/input/pc_keyb.c
parent1934665742e38c8ced9342a9c3005a3eab0b1a7c (diff)
downloadu-boot-imx-986fe378172fa4bd5be1432ab2f8f7c2b1c43bae.zip
u-boot-imx-986fe378172fa4bd5be1432ab2f8f7c2b1c43bae.tar.gz
u-boot-imx-986fe378172fa4bd5be1432ab2f8f7c2b1c43bae.tar.bz2
itest: allow map_physmem to return 0 in limited cases
On some systems, RAM starts at address 0. If the user executes itest against address 0 on such a system, it will call map_physmem(0, ...) which will return 0 back; mapping only changes the address on sandbox. This causes itest to believe map_physmem() has failed, and hence fails the comparison. Fix itest so that it allows map_physmem() to return 0 /if/ the orignal address passed to it was also 0. This fixes "tegra-uboot-flasher flash" on Tegra20. This has the disadvantage that on sandbox, failed mapping attempts for address 0 are not detected. Instead, should the code only call map_physmem() on sandbox? Or, should map_physmem() return its error status some other way. Or, should the special case only be allowed on systems where the base of RAM is 0 somehow? Fixes: 7861204c9af7 ("itest: make memory access work under sandbox") Signed-off-by: Stephen Warren <swarren@nvidia.com>
Diffstat (limited to 'drivers/input/pc_keyb.c')
0 files changed, 0 insertions, 0 deletions