summaryrefslogtreecommitdiff
path: root/drivers/firmware/google/coreboot_table.c
diff options
context:
space:
mode:
authorAlper Nebi Yasak <alpernebiyasak@gmail.com>2023-11-08 21:25:13 +0300
committerTzung-Bi Shih <tzungbi@kernel.org>2023-11-13 05:38:32 +0300
commitecea08916418a94f99f89c543303877cb6e08a11 (patch)
treee4c8d58aa72a74c4eb52f1a392a236f71111b718 /drivers/firmware/google/coreboot_table.c
parentb85ea95d086471afb4ad062012a4d73cd328fa86 (diff)
downloadlinux-ecea08916418a94f99f89c543303877cb6e08a11.tar.xz
firmware: coreboot: framebuffer: Avoid invalid zero physical address
On ARM64 systems coreboot defers framebuffer allocation to its payload, to be done by a libpayload function call. In this case, coreboot tables still include a framebuffer entry with display format details, but the physical address field is set to zero (as in [1], for example). Unfortunately, this field is not automatically updated when the framebuffer is initialized through libpayload, citing that doing so would invalidate checksums over the entire coreboot table [2]. This can be observed on ARM64 Chromebooks with stock firmware. On a Google Kevin (RK3399), trying to use coreboot framebuffer driver as built-in to the kernel results in a benign error. But on Google Hana (MT8173) and Google Cozmo (MT8183) it causes a hang. When the framebuffer physical address field in the coreboot table is zero, we have no idea where coreboot initialized a framebuffer, or even if it did. Instead of trying to set up a framebuffer located at zero, return ENODEV to indicate that there isn't one. [1] https://review.coreboot.org/c/coreboot/+/17109 [2] https://review.coreboot.org/c/coreboot/+/8797 Signed-off-by: Alper Nebi Yasak <alpernebiyasak@gmail.com> Reviewed-by: Julius Werner <jwerner@chromium.org> Link: https://lore.kernel.org/r/20231108182625.46563-1-alpernebiyasak@gmail.com Signed-off-by: Tzung-Bi Shih <tzungbi@kernel.org>
Diffstat (limited to 'drivers/firmware/google/coreboot_table.c')
0 files changed, 0 insertions, 0 deletions