From: Tzung-Bi Shih <tzungbi@kernel.org>
To: Thomas Zimmermann <tzimmermann@suse.de>
Cc: briannorris@chromium.org, jwerner@chromium.org,
javierm@redhat.com, samuel@sholland.org,
maarten.lankhorst@linux.intel.com, mripard@kernel.org,
airlied@gmail.com, simona@ffwll.ch,
chrome-platform@lists.linux.dev, dri-devel@lists.freedesktop.org
Subject: Re: [PATCH v3 11/12] drm/sysfb: corebootdrm: Add DRM driver for coreboot framebuffers
Date: Fri, 6 Feb 2026 09:20:06 +0000 [thread overview]
Message-ID: <aYWyRiqpGdpze46p@google.com> (raw)
In-Reply-To: <0a85e1ab-e1d1-4a3a-8f3e-7478d814d400@suse.de>
On Fri, Feb 06, 2026 at 08:44:02AM +0100, Thomas Zimmermann wrote:
> Am 06.02.26 um 06:14 schrieb Tzung-Bi Shih:
> > On Tue, Feb 03, 2026 at 02:52:30PM +0100, Thomas Zimmermann wrote:
> > > Add corebootdrm, a DRM driver for coreboot framebuffers. The driver
> > > supports a pre-initialized framebuffer with various packed RGB formats.
> > > The driver code is fairly small and uses the same logic as the other
> > > sysfb drivers. Most of the implementation comes from existing sysfb
> > > helpers.
> > >
> > > Until now, coreboot relied on simpledrm or simplefb for boot-up graphics
> > > output. Initialize the platform device for corebootdrm in the same place
> > > in framebuffer_probe(). With a later commit, the simple-framebuffer should
> > > be removed.
> > >
> > > v3:
> > > - comment on _HAS_LFB semantics (Tzung-Bi)
> > > - fix typo in commit description (Tzung-Bi)
> > > - comment on simple-framebuffer being obsolete for coreboot
> > > v2:
> > > - reimplement as platform driver
> > > - limit resources and mappings to known framebuffer memory; no
> > > page alignment
> > > - create corebootdrm device from coreboot framebuffer code
> > Changelog should be after "---" otherwise it becomes part of commit message.
>
> I see. In DRM land, we usually keep the change log in the commit message.
> I'll change it for the coreboot patches, but I'd rather keep it for the DRM
> patches. I can split off the coreboot changes for this patch into its own.
I see. Please keep it if this is a convention in DRM land.
> > > +static int corebootdrm_probe(struct platform_device *pdev)
> > > +{
> > [...]
> > > + if (!fb) {
> > > + drm_err(dev, "coreboot framebuffer not found\n");
> > > + return -EINVAL;
> > > + } else if (!LB_FRAMEBUFFER_HAS_LFB(fb)) {
> > > + drm_err(dev, "coreboot framebuffer entry too small\n");
> > > + return -EINVAL;
> > > + }
> > > +
> > > + /*
> > > + * Hardware settings
> > > + */
> > > +
> > > + format = corebootdrm_get_format_fb(dev, fb);
> > > + if (!format)
> > > + return -EINVAL;
> > > + width = corebootdrm_get_width_fb(dev, fb);
> > > + if (width < 0)
> > > + return width;
> > > + height = corebootdrm_get_height_fb(dev, fb);
> > > + if (height < 0)
> > > + return height;
> > [...]
> > > diff --git a/include/linux/coreboot.h b/include/linux/coreboot.h
> > > index 5746b99a070d..b51665165f9f 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>
> > Move it before types.h? 's' vs. 't'.
> >
> > > +/*
> > > + * True if the coreboot-provided data is large enough to hold information
> > > + * on the linear framebuffer. False otherwise.
> > > + */
> > > +#define LB_FRAMEBUFFER_HAS_LFB(__fb) \
> > > + ((__fb)->size >= offsetofend(struct lb_framebuffer, reserved_mask_size))
> > > +
> > To make sure I understand, do you mean:
> >
> > - The __fb->size is possibly less than sizeof(struct lb_framebuffer).
> > LB_FRAMEBUFFER_HAS_LFB() is for checking the following fields
> > (e.g. fb->x_resolution) are available?
>
> Yes.
>
> >
> > struct lb_framebuffer {
> > u32 tag;
> > u32 size;
> >
> > u64 physical_address;
> > u32 x_resolution;
> > u32 y_resolution;
> > u32 bytes_per_line;
> > u8 bits_per_pixel;
> > u8 red_mask_pos;
> > u8 red_mask_size;
> > u8 green_mask_pos;
> > u8 green_mask_size;
> > u8 blue_mask_pos;
> > u8 blue_mask_size;
> > u8 reserved_mask_pos;
> > u8 reserved_mask_size;
> > };
> >
> > - If answer of the previous question is yes, the next question: does
> > LB_FRAMEBUFFER_HAS_LFB() needs to check up to `reserved_mask_size`?
> > As in the patch, it only accesses up to `blue_mask_size`.
>
> Well, it's a correctness thing. The reserved_mask fields have been part of
> the structure since the first version in commit b700254aa5 ("Add coreboot
> framebuffer support to libpayload"). I'd that expect that the framebuffer
> entry is bogus if it does not contain these fields. If you really want to
> leave them out, we can do that of course.
I see. All makes sense. Let's leave it as is.
For drivers/firmware/google/ and include/linux/coreboot.h,
Acked-by: Tzung-Bi Shih <tzungbi@kernel.org>
next prev parent reply other threads:[~2026-02-06 9:20 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-02-03 13:52 [PATCH v3 00/12] drm, coreboot: Add DRM coreboot driver Thomas Zimmermann
2026-02-03 13:52 ` [PATCH v3 01/12] firmware: google: framebuffer: Do not unregister platform device Thomas Zimmermann
2026-02-03 13:52 ` [PATCH v3 02/12] firmware: google: framebuffer: Do not mark framebuffer as busy Thomas Zimmermann
2026-02-03 13:52 ` [PATCH v3 03/12] firmware: google: framebuffer: Init memory resource with helper macro Thomas Zimmermann
2026-02-03 13:52 ` [PATCH v3 04/12] firmware: google: framebuffer: Tie platform device to PCI hardware Thomas Zimmermann
2026-02-03 13:52 ` [PATCH v3 05/12] firmware: google: framebuffer: Fix dependencies Thomas Zimmermann
2026-02-03 13:52 ` [PATCH v3 06/12] firmware: google: Init coreboot bus with subsys_initcall() Thomas Zimmermann
2026-02-03 13:52 ` [PATCH v3 07/12] firmware: google: Clean up include statements in coreboot_table.h Thomas Zimmermann
2026-02-03 13:52 ` [PATCH v3 08/12] firmware: google: Export coreboot table entries Thomas Zimmermann
2026-02-03 13:52 ` [PATCH v3 09/12] firmware: google: Pack structures for " Thomas Zimmermann
2026-02-06 5:13 ` Tzung-Bi Shih
2026-02-03 13:52 ` [PATCH v3 10/12] drm/sysfb: Generalize pixel-format matching Thomas Zimmermann
2026-02-03 13:52 ` [PATCH v3 11/12] drm/sysfb: corebootdrm: Add DRM driver for coreboot framebuffers Thomas Zimmermann
2026-02-06 5:14 ` Tzung-Bi Shih
2026-02-06 7:44 ` Thomas Zimmermann
2026-02-06 9:20 ` Tzung-Bi Shih [this message]
2026-02-16 10:25 ` Javier Martinez Canillas
2026-02-03 13:52 ` [PATCH v3 12/12] drm/sysfb: corebootdrm: Support panel orientation Thomas Zimmermann
2026-02-06 9:21 ` Tzung-Bi Shih
2026-02-16 10:27 ` Javier Martinez Canillas
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=aYWyRiqpGdpze46p@google.com \
--to=tzungbi@kernel.org \
--cc=airlied@gmail.com \
--cc=briannorris@chromium.org \
--cc=chrome-platform@lists.linux.dev \
--cc=dri-devel@lists.freedesktop.org \
--cc=javierm@redhat.com \
--cc=jwerner@chromium.org \
--cc=maarten.lankhorst@linux.intel.com \
--cc=mripard@kernel.org \
--cc=samuel@sholland.org \
--cc=simona@ffwll.ch \
--cc=tzimmermann@suse.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.