linux/drivers/firmware/google, branch master

Merge drm/drm-next into drm-misc-next

2026-02-23T10:48:20Z

Let's merge 7.0-rc1 to start the new drm-misc-next window Signed-off-by: Maxime Ripard

Convert 'alloc_obj' family to use the new default GFP_KERNEL argument

2026-02-22T01:09:51Z

This was done entirely with mindless brute force, using git grep -l '\

treewide: Replace kmalloc with kmalloc_obj for non-scalar types

2026-02-21T09:02:28Z

This is the result of running the Coccinelle script from scripts/coccinelle/api/kmalloc_objs.cocci. The script is designed to avoid scalar types (which need careful case-by-case checking), and instead replace kmalloc-family calls that allocate struct or union object instances: Single allocations: kmalloc(sizeof(TYPE), ...) are replaced with: kmalloc_obj(TYPE, ...) Array allocations: kmalloc_array(COUNT, sizeof(TYPE), ...) are replaced with: kmalloc_objs(TYPE, COUNT, ...) Flex array allocations: kmalloc(struct_size(PTR, FAM, COUNT), ...) are replaced with: kmalloc_flex(*PTR, FAM, COUNT, ...) (where TYPE may also be *VAR) The resulting allocations no longer return "void *", instead returning "TYPE *". Signed-off-by: Kees Cook

drm/sysfb: corebootdrm: Add DRM driver for coreboot framebuffers

2026-02-20T13:38:24Z

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. v4: - sort include statements (Tzung-Bi) 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 Signed-off-by: Thomas Zimmermann Reviewed-by: Javier Martinez Canillas Acked-by: Julius Werner Acked-by: Tzung-Bi Shih # coreboot Link: https://patch.msgid.link/20260217155836.96267-12-tzimmermann@suse.de

firmware: google: Export coreboot table entries

2026-02-20T13:38:21Z

Move types for coreboot table entries to . Allows drivers in other subsystems to use these structures. Signed-off-by: Thomas Zimmermann Acked-by: Tzung-Bi Shih Acked-by: Julius Werner Link: https://patch.msgid.link/20260217155836.96267-9-tzimmermann@suse.de

firmware: google: Clean up include statements in coreboot_table.h

2026-02-20T13:38:20Z

Include from source files and only forward- declare struct coreboot_device_id in coreboot_table.h. Signed-off-by: Thomas Zimmermann Reviewed-by: Javier Martinez Canillas Acked-by: Tzung-Bi Shih Acked-by: Julius Werner Link: https://patch.msgid.link/20260217155836.96267-8-tzimmermann@suse.de

firmware: google: Init coreboot bus with subsys_initcall()

2026-02-20T13:38:20Z

Using module_init()/device_initcall() is too late to initialize the coreboot bus, as there might already be drivers that depend on it. So far this hasn't been a problem, as coreboot controls all device creation. Initializing the coreboot bus earlier in subsys_initcall() will allow for external coreboot drivers to register themselves with device_initcall(). Prepares coreboot to support additional coreboot drivers from other subsystems. Signed-off-by: Thomas Zimmermann Reviewed-by: Javier Martinez Canillas Acked-by: Tzung-Bi Shih Acked-by: Julius Werner Link: https://patch.msgid.link/20260217155836.96267-7-tzimmermann@suse.de

firmware: google: framebuffer: Fix dependencies

2026-02-20T13:38:19Z

The framebuffer on the coreboot bus represents an entry in the coreboot payload table; not the actual device. [1] Hence it must not depend on any other driver setting. Signed-off-by: Thomas Zimmermann Link: https://lore.kernel.org/dri-devel/CAODwPW9_ym3E4za3yoUAs0+1sQfaKTDOau4Oh9Zm8+2uvYVgFQ@mail.gmail.com/ # [1] Acked-by: Tzung-Bi Shih Acked-by: Julius Werner Link: https://patch.msgid.link/20260217155836.96267-6-tzimmermann@suse.de

firmware: google: framebuffer: Tie platform device to PCI hardware

2026-02-20T13:38:19Z

Use the PCI device as parent of the system-framebuffer device instead of the coreboot device. Prevents SIGBUS or SIGSEG after hot-unplug of the PCI device while the framebuffer is active. The simple-framebuffer device depends on the PCI hardware, so this device needs to be its parent. The current coreboot parent is no longer needed after the system-framebuffer device has been created. On systems without PCI or if no PCI parent device could be found, the platform device hangs on the platform bus directly. The fix here is similar to code in sysfb, which contained that same bug. Signed-off-by: Thomas Zimmermann Acked-by: Tzung-Bi Shih Acked-by: Julius Werner Link: https://patch.msgid.link/20260217155836.96267-5-tzimmermann@suse.de

firmware: google: framebuffer: Init memory resource with helper macro

2026-02-20T13:38:18Z

Initialize framebuffer memory resource with DEFINE_RES_MEM() instead of open-coding the setup. While at it, drop the resource name to make the kernel use the device name of the simple-framebuffer device for the resource. The latter includes a device number. While the meaning of the resource name is somewhat fuzzy and varies across entries in /proc/iomem, showing the device name seems more helpful than showing a fixed name. Signed-off-by: Thomas Zimmermann Acked-by: Tzung-Bi Shih Acked-by: Julius Werner Link: https://patch.msgid.link/20260217155836.96267-4-tzimmermann@suse.de