Hi
Am 27.01.26 um 08:49 schrieb Tzung-Bi Shih:
On Thu, Jan 15, 2026 at 08:57:21AM +0100, Thomas Zimmermann wrote:
Add corebotdrm, a DRM driver for coreboot framebuffers. The driver
^ oo
diff --git a/include/linux/coreboot.h b/include/linux/coreboot.h
index 514c95f9d0e3..e81ee5746e2b 100644
--- a/include/linux/coreboot.h
+++ b/include/linux/coreboot.h
@@ -14,6 +14,7 @@
#include <linux/compiler_attributes.h>
#include <linux/types.h>
+#include <linux/stddef.h>
/* List of coreboot entry structures that is used */
@@ -64,4 +65,7 @@ struct lb_framebuffer {
u8 reserved_mask_size;
} __packed;
+#define LB_FRAMEBUFFER_HAS_LFB(__fb) \
+ ((__fb)->size >= offsetofend(struct lb_framebuffer, reserved_mask_size))
+
Does LFB stand for "Linear Frame Buffer"?
Yes.
I supposed the LFB follows the struct lb_framebuffer in memory. If yes, I'm
wondering does LB_FRAMEBUFFER_HAS_LFB() work? As the struct lb_framebuffer
definition is different from [1].
`offsetofend(struct lb_framebuffer, reserved_mask_size)` is 37 in the kernel
but the tailing data (i.e., LFB in the context) might start from offset 40 in
coreboot.
Newer versions of coreboot add fields to the end of struct
cb_framebuffer. So it keeps growing in size.
This macro checks is the provided size is large enough to cover
framebuffer information. The framebuffer info consists of all the fields
up-to-and-including reserved_mask_size. Testing with
LB_FRAMEBUFFER_HAS_LFB is a safety measure, as we can assume that it's
always there.
If coreboot provides less fields, it is likely broken. If it provides
more fields, it doesn't affect the framebuffer.
Best regards
Thomas
[1]
https://github.com/coreboot/coreboot/blob/main/payloads/libpayload/include/coreboot_tables.h#L232
--
--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Frankenstr. 146, 90461 Nürnberg, Germany, www.suse.com
GF: Jochen Jaser, Andrew McDonald, Werner Knoblich, (HRB 36809, AG Nürnberg)
