[PATCH V3] drivers/firmware: Move sysfb_init() from device_initcall to subsys_initcall_sync

[Huacai Chen]

Ping?

On Tue, Jul 5, 2022 at 12:22 AM Huacai Chen <chenhuacai at loongson.cn> wrote:
>
> Consider a configuration like this:
> 1, efifb (or simpledrm) is built-in;
> 2, a native display driver (such as radeon) is also built-in.
>
> As Javier said, this is not a common configuration (the native display
> driver is usually built as a module), but it can happen and cause some
> trouble.
>
> In this case, since efifb, radeon and sysfb are all in device_initcall()
> level, the order in practise is like this:
>
> efifb registered at first, but no "efi-framebuffer" device yet. radeon
> registered later, and /dev/fb0 created. sysfb_init() comes at last, it
> registers "efi-framebuffer" and then causes an error message "efifb: a
> framebuffer is already registered". Make sysfb_init() to be subsys_
> initcall_sync() can avoid this. And Javier Martinez Canillas is trying
> to make a more general solution in commit 873eb3b11860 ("fbdev: Disable
> sysfb device registration when removing conflicting FBs").
>
> However, this patch still makes sense because it can make the screen
> display as early as possible (We cannot move to subsys_initcall, since
> sysfb_init() should be executed after PCI enumeration).
>
> Reviewed-by: Javier Martinez Canillas <javierm at redhat.com>
> Signed-off-by: Huacai Chen <chenhuacai at loongson.cn>
> ---
> V2: Update commit message.
> V3: Update commit message again.
>
>  drivers/firmware/sysfb.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/firmware/sysfb.c b/drivers/firmware/sysfb.c
> index 2bfbb05f7d89..aecf91517e54 100644
> --- a/drivers/firmware/sysfb.c
> +++ b/drivers/firmware/sysfb.c
> @@ -80,4 +80,4 @@ static __init int sysfb_init(void)
>  }
>
>  /* must execute after PCI subsystem for EFI quirks */
> -device_initcall(sysfb_init);
> +subsys_initcall_sync(sysfb_init);
> --
> 2.27.0
>