linux-kernel - Re: [PATCH v2] drivers/firmware: fix SYSFB depends to prevent build failures

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]

Date:   Tue, 27 Jul 2021 12:03:47 +0200
From:   Geert Uytterhoeven <geert@...ux-m68k.org>
To:     Javier Martinez Canillas <javierm@...hat.com>
Cc:     Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Thomas Zimmermann <tzimmermann@...e.de>,
        dri-devel <dri-devel@...ts.freedesktop.org>,
        Peter Robinson <pbrobinson@...il.com>,
        Mark Brown <broonie@...nel.org>,
        kernel test robot <lkp@...el.com>,
        Borislav Petkov <bp@...e.de>,
        Colin Ian King <colin.king@...onical.com>,
        Daniel Vetter <daniel.vetter@...ll.ch>,
        Dinh Nguyen <dinguyen@...nel.org>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        John Stultz <john.stultz@...aro.org>,
        Krzysztof Kozlowski <krzysztof.kozlowski@...onical.com>,
        Linus Walleij <linus.walleij@...aro.org>,
        Nicolas Saenz Julienne <nsaenz@...nel.org>,
        Sudeep Holla <sudeep.holla@....com>
Subject: Re: [PATCH v2] drivers/firmware: fix SYSFB depends to prevent build failures

Hi Javier,

On Tue, Jul 27, 2021 at 11:33 AM Javier Martinez Canillas
<javierm@...hat.com> wrote:
> The Generic System Framebuffers support is built when the COMPILE_TEST
> option is enabled. But this wrongly assumes that all the architectures
> declare a struct screen_info.
>
> This is true for most architectures, but at least the following do not:
> arc, m68k, microblaze, openrisc, parisc and s390.
>
> By attempting to make this compile testeable on all architectures, it
> leads to linking errors as reported by the kernel test robot for parisc:
>
>   All errors (new ones prefixed by >>):
>
>      hppa-linux-ld: drivers/firmware/sysfb.o: in function `sysfb_init':
>      (.init.text+0x24): undefined reference to `screen_info'
>   >> hppa-linux-ld: (.init.text+0x28): undefined reference to `screen_info'
>
> To prevent these errors only allow sysfb to be built on systems that are
> going to need it, which are x86 BIOS and EFI.
>
> The EFI Kconfig symbol is used instead of (ARM || ARM64 || RISC) because
> some of these architectures only declare a struct screen_info if EFI is
> enabled. And also, because the SYSFB code is only used for EFI on these
> architectures. For !EFI the "simple-framebuffer" device is registered by
> OF when parsing the Device Tree Blob (if a DT node for this was defined).
>
> Fixes: d391c5827107 ("drivers/firmware: move x86 Generic System Framebuffers support")
> Reported-by: kernel test robot <lkp@...el.com>
> Signed-off-by: Javier Martinez Canillas <javierm@...hat.com>

Thanks for your patch!

> --- 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 || EFI

Thanks, 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.

>
>  config SYSFB_SIMPLEFB
>         bool "Mark VGA/VBE/EFI FB as generic system framebuffer"

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@...ux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds