linux-kernel - Re: [PATCH V11 09/22] LoongArch: Add boot and setup routines

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAAhV-H7yKVWaiU_VKnc2YnCSeZPOwedRWMY8ZTS-VWwk+vE0AA@mail.gmail.com>
Date:   Fri, 20 May 2022 23:19:54 +0800
From:   Huacai Chen <chenhuacai@...il.com>
To:     Javier Martinez Canillas <javierm@...hat.com>
Cc:     Ard Biesheuvel <ardb@...nel.org>,
        Huacai Chen <chenhuacai@...ngson.cn>,
        Arnd Bergmann <arnd@...db.de>,
        Andy Lutomirski <luto@...nel.org>,
        Thomas Gleixner <tglx@...utronix.de>,
        Peter Zijlstra <peterz@...radead.org>,
        Andrew Morton <akpm@...ux-foundation.org>,
        David Airlie <airlied@...ux.ie>,
        Jonathan Corbet <corbet@....net>,
        Linus Torvalds <torvalds@...ux-foundation.org>,
        linux-arch <linux-arch@...r.kernel.org>,
        Linux Doc Mailing List <linux-doc@...r.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Xuefeng Li <lixuefeng@...ngson.cn>,
        Yanteng Si <siyanteng@...ngson.cn>,
        Guo Ren <guoren@...nel.org>, Xuerui Wang <kernel@...0n.name>,
        Jiaxun Yang <jiaxun.yang@...goat.com>,
        Stephen Rothwell <sfr@...b.auug.org.au>,
        linux-efi <linux-efi@...r.kernel.org>
Subject: Re: [PATCH V11 09/22] LoongArch: Add boot and setup routines

Hi, Javier,

On Fri, May 20, 2022 at 10:23 PM Javier Martinez Canillas
<javierm@...hat.com> wrote:
>
> Hello Huacai,
>
> On 5/20/22 16:09, Huacai Chen wrote:
>
> [snip]
>
> >>
> >> In summary, just enable the following to use the firmware framebuffer:
> >>
> >> CONFIG_DRM_SIMPLEDRM=y
> >> CONFIG_DRM_FBDEV_EMULATION=y
> >> CONFIG_SYSFB=y
> >> CONFIG_SYSFB_SIMPLEFB=y
> > Thank you very much, since 5.15 sysfb_init() do all things of
> > register_gop_device(), so register_gop_device() here can be removed.
>
> Correct.
>
> > But there is another small problem: if simpledrm or efifb driver is
> > built-in, there is no display. The reason is both sysfb_init() and
> > display driver are in the same initcall level (device_initcall()).
> > From the comments I know that sysfb_init() should after PCI
> > enumeration which is in subsys_initcall(), so, could we make
> > sysfb_init() to be a subsys_initcall_sync()?
> >
>
> I don't understand why we would need that... it shouldn't matter the order
> in which the driver's init and sysfb_init() are done. If the driver's init
> is executed first, then the driver will be registered and later when the
> sysfb_init() registers the device, it will match the driver and probe.
>
> Conversely, if the sysfb_init() is executed first then the platform device
> will be registered and latter when the driver's init register the driver
> this will match the already registered device.
Yes, you are right, my consideration is too complex. The only real
problem is a harmless error "efifb: a framebuffer is already
registered" when both efifb and the native display driver are
built-in.

Huacai
>
> In other words, it will be handled by the Linux device model and we should
> not attempt to hand pick the initcall level for each. That's quite fragile.
>
> Or am I missing something here ?
>
> --
> Best regards,
>
> Javier Martinez Canillas
> Linux Engineering
> Red Hat
>