Re: [PATCH 3/8] firmware: sysfb: Make CONFIG_SYSFB a user-selectable option
Javier Martinez Canillas <[email protected]>
| Newsgroups | org.kernel.vger.linux-efi,dev.linux.lists.loongarch,org.freedesktop.lists.dri-devel,org.infradead.lists.linux-arm-kernel,org.infradead.lists.linux-riscv,org.kernel.vger.linux-fbdev,org.kernel.vger.linux-hyperv |
|---|---|
| Message-ID | <[email protected]> |
Thomas Zimmermann <[email protected]> writes: Hello, [...] >>>>>> On Thu, Apr 2, 2026, at 11:09, Thomas Zimmermann wrote: >>>>>> I don't really like this part of the series and would prefer >>>>>> to keep CONFIG_SYSFB hidden as much as possible as an x86 I tend to agree with Arnd here, I'm also not seeing that much value on making this symbol user selectable. For now I would just keep it hidden. [...] >> Yes, I saw that as well and don't have an immediate idea for how >> to best do it. I saw that you already abstracted the access to >> the screen_info members in drm_sysfb_screen_info.c, which I think >> is a step in that direction. >> >> I also noticed that efidrm is mostly a subset of vesadrm, so >> in theory they could be merged back into an x86 drm driver >> along with the drm_sysfb_screen_info helpers, and have a non-x86 >> driver that constructs a drm_sysfb_device directly from the >> EFI structures. > > I would not want to have a unifed driver for all-things-screen_info. The > code that can easily be shared is already in the sysfb helpers. But I > don't mind adding a separate driver for EFI's Graphics Output Protocol. I agree. It is much more maintainable if we have dedicated DRM drivers that use shared helpers, than attempting to have a driver for different platforms. As Thomas explained, the maintance effort is small on the DRM side and he has done a lot of work to split simpledrm in efidrm, vesadrm and ofdrm. -- Best regards, Javier Martinez Canillas Core Platforms Red Hat