cpu/x86/mtrr: Fix _FROM_4G_TOP() macro

This macro was unnecessarily complex. Trying to avoid an overflow
for unknown reasons, and instead shifted the result into the sign
bit in C. Using a plain number literal that forces C to use an
adequate integer type seems to be safe. We start with 0xffffffff,
subtract `x` and add 1 again. Turned out to be a common pattern
and can't overflow for any positive 32-bit `x`.

Change-Id: Ibb0c5b88a6e42d3ef2990196a5b99ace90ea8ee8
Signed-off-by: Nico Huber <nico.h@gmx.de>
Reviewed-on: https://review.coreboot.org/c/31322
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
This commit is contained in:
Nico Huber 2019-02-10 20:14:57 +01:00
parent f751aee926
commit 540a664045
1 changed files with 1 additions and 1 deletions

View File

@ -150,7 +150,7 @@ static inline unsigned int fls(unsigned int x)
#define _ALIGN_DOWN_POW2(x) ((x) & ~_POW2_MASK(x))
/* Calculate `4GiB - x` (e.g. absolute address for offset from 4GiB) */
#define _FROM_4G_TOP(x) (((1 << 20) - ((x) >> 12)) << 12)
#define _FROM_4G_TOP(x) ((0xffffffff - (x)) + 1)
/* At the end of romstage, low RAM 0..CACHE_TM_RAMTOP may be set
* as write-back cacheable to speed up ramstage decompression.