diff options
author | Alper Nebi Yasak <alpernebiyasak@gmail.com> | 2023-11-08 21:25:13 +0300 |
---|---|---|
committer | Tzung-Bi Shih <tzungbi@kernel.org> | 2023-11-13 05:38:32 +0300 |
commit | ecea08916418a94f99f89c543303877cb6e08a11 (patch) | |
tree | e4c8d58aa72a74c4eb52f1a392a236f71111b718 /drivers/firmware/google/coreboot_table.c | |
parent | b85ea95d086471afb4ad062012a4d73cd328fa86 (diff) | |
download | linux-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