Hi
Am 27.01.26 um 09:04 schrieb Tzung-Bi Shih:
On Tue, Jan 27, 2026 at 07:49:46AM +0000, Tzung-Bi Shih wrote:
On Thu, Jan 15, 2026 at 08:57:22AM +0100, Thomas Zimmermann wrote:
diff --git a/include/linux/coreboot.h b/include/linux/coreboot.h
[...]
@@ -63,9 +68,13 @@ struct lb_framebuffer {
u8 blue_mask_size;
u8 reserved_mask_pos;
u8 reserved_mask_size;
+ u8 orientation;
} __packed;
#define LB_FRAMEBUFFER_HAS_LFB(__fb) \
((__fb)->size >= offsetofend(struct lb_framebuffer, reserved_mask_size))
+#define LB_FRAMEBUFFER_HAS_ORIENTATION(__fb) \
+ ((__fb)->size >= offsetofend(struct lb_framebuffer, orientation))
Wouldn't the new field in struct lb_framebuffer break LB_FRAMEBUFFER_HAS_LFB()?
E.g., fb->size == offsetofend(struct lb_framebuffer, reserved_mask_size)
-> LB_FRAMEBUFFER_HAS_LFB(fb) == true
-> LB_FRAMEBUFFER_HAS_ORIENTATION(fb) == false?
The example is wrong, please forget it.
Again, I supposed the "LFB" is tailing data of struct lb_framebuffer.
I meant: is it possible that there is no tailing data
-> fb->size == offsetofend(struct lb_framebuffer, orientation)
-> LB_FRAMEBUFFER_HAS_LFB() == true falsely.
I'm not quite sure if I understand the question: _HAS_LFB test is the
provided entry is large enough to hold framebuffer information (true
unless the firmware is broken). _HAS_ORIENTATION tests is the provided
entry is large enough to hold the orientation field. That depends on the
coreboot version, as early versions might not have it. If either macro
is true, we can safely look at the rsp fields; otherwise the fields are
undefined.
If provided, the individual fields still need to be validated whether
they have meaning full values.
Best regards
Thomas
--
--
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)
