Julius Werner has posted comments on this change. ( https://review.coreboot.org/c/coreboot/+/34075 )
Change subject: arch, include, soc: Use common stdint.h ......................................................................
Patch Set 5:
(2 comments)
https://review.coreboot.org/c/coreboot/+/34075/4/src/arch/arm/armv7/mmu.c File src/arch/arm/armv7/mmu.c:
https://review.coreboot.org/c/coreboot/+/34075/4/src/arch/arm/armv7/mmu.c@16... PS4, Line 168: printk(BIOS_DEBUG, "Creating new subtable @%p for [%#.8" PRIxPTR ":%#.8" PRIxPTR ")\n",
The idea is that PRIxPTR is the portable way of printing a uintptr_t, since we generally cannot assu […]
This is an architecture file, so we know what the underlying type is (even if it wasn't the same for all architectures anyway). I don't think this patch should change anything here if it's not necessary to make it build.
The reason we want to suppor the PRI macros is mostly for third-party code (e.g. vboot) that's using them. For coreboot code, especially if it only runs on one architecture, I think continuing to use explicit specifiers is fine.
https://review.coreboot.org/c/coreboot/+/34075/4/src/soc/nvidia/tegra210/mmu... File src/soc/nvidia/tegra210/mmu_operations.c:
https://review.coreboot.org/c/coreboot/+/34075/4/src/soc/nvidia/tegra210/mmu... PS4, Line 26: uintptr_t start, end;
memory_in_range_below_4gb() expects uintptr_t, and now that uintptr_t is unsigned long we need to up […]
Does this mean uint64_t doesn't implicitly convert to uintptr_t on 64-bit architectures anymore? ...C conversion rules can be really stupid sometimes. -.- But okay.
I'm surprised that this is the only code that breaks, though, if that's the case.