Hi Javier,
On Tue, Jul 27, 2021 at 12:22 PM Javier Martinez Canillas javierm@redhat.com wrote:
On 7/27/21 12:03 PM, Geert Uytterhoeven wrote:
--- a/drivers/firmware/Kconfig +++ b/drivers/firmware/Kconfig @@ -254,7 +254,7 @@ config QCOM_SCM_DOWNLOAD_MODE_DEFAULT config SYSFB bool default y
depends on X86 || ARM || ARM64 || RISCV || COMPILE_TEST
depends on X86 || EFIThanks, much better. Still, now this worm is crawling out of the X86 can, I'm wondering why this option is so important that it has to default to y? It is not just a dependency for SYSFB_SIMPLEFB, but also causes the inclusion of drivers/firmware/sysfb.c.
It defaults to yes because drivers/firmware/sysfb.c contains the logic to register a "simple-framebuffer" device (or "efi-framebuffer" if the CONFIG_SYSFB_SIMPLEFB Kconfig symbol is not enabled).
Not enabling this, would mean that a platform device to match a driver supporting the EFI GOP framebuffer (e.g: simple{drm,fb} or efifb) will not be registered. Which will lead to not having an early framebuffer.
Do all (embedded) EFI systems have a frame buffer?
Perhaps SYSFB should be selected by SYSFB_SIMPLEFB, FB_VESA, and FB_EFI?
The logic used to be in drivers/firmware/efi/efi-init.c, that's built in if CONFIG_EFI is enabled. We just consolidated both X86 and EFI:
https://cgit.freedesktop.org/drm/drm-misc/commit/?id=8633ef82f101
Thanks, I'm aware of that commit, as I was just about to reply to it, when I saw the patch is this thread ;-)
Gr{oetje,eeting}s,
Geert