linux-kernel - Re: [PATCH 0/5] efi: x86: Provide EDID from GOP device

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <CAMj1kXF62pEMUJAM12HnF7qMt5xhZaZXpPoMdebMUKCfoAYisQ@mail.gmail.com>
Date: Fri, 14 Nov 2025 09:31:13 +0100
From: Ard Biesheuvel <ardb@...nel.org>
To: Thomas Zimmermann <tzimmermann@...e.de>
Cc: jonathan@...ek.ca, javierm@...hat.com, linux-efi@...r.kernel.org, 
	dri-devel@...ts.freedesktop.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 0/5] efi: x86: Provide EDID from GOP device

On Wed, 15 Oct 2025 at 18:08, Thomas Zimmermann <tzimmermann@...e.de> wrote:
>
> Add support for EFI_EDID_ACTIVE_PROTOCOL and EFI_EDID_DISCOVERED_PROTOCOL
> on x86. Refactor the GOP helpers for EDID support, then retrieve the EDID
> into x86 boot_params.
>
> Later boot code copies the EDID from the boot parameters into the global
> variable edid_info. Graphics drivers, such as efidrm, can pick up the
> information from there. In the case of efidrm, it provides the EDID to
> user-space compositors, which use it for improved QoS on the display
> output. Similar functionality is already available on old VESA systems
> with vesadrm.
>
> Tested on x86 EFI systems.
>
> Another patch is required to provide EDID on non-x86 systems via the
> generic EFI stub. The implementation can directly build upon this
> series.
>
> Thomas Zimmermann (5):
>   efi: Fix trailing whitespace in header file
>   efi/libstub: gop: Find GOP handle instead of GOP data
>   efi/libstub: gop: Initialize screen_info in helper function
>   efi/libstub: gop: Add support for reading EDID
>   efi/libstub: x86: Store EDID in boot_params
>

Hi,

Apologies for the delay. This series looks fine to me, although I
would prefer it if we could make things a bit more generic?

Everything you are adding here is arch-agnostic, except for the bit
where we use x86-specific plumbing to pass the EDID info between the
EFI stub and the core kernel.

More specifically, could we do the following:
- move struct edid_info edid_info into common code
- pass the detected EDID info block via a EFI config table instead of
boot_params
- make CONFIG_FIRMWARE_EDID depend on (X86 || EFI_STUB)