linux-kernel - Re: [RFC PATCH] of/platform: Disable sysfb if a simple-framebuffer node is found

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: <CAL_JsqKHTN5hfd4qpg5RXbmQLKZNVywDkSj9mxvfGmjrcChQQg@mail.gmail.com>
Date:   Wed, 15 Nov 2023 14:34:13 -0600
From:   Rob Herring <robh@...nel.org>
To:     Javier Martinez Canillas <javierm@...hat.com>
Cc:     linux-kernel@...r.kernel.org,
        Thomas Zimmermann <tzimmermann@...e.de>,
        Ard Biesheuvel <ardb@...nel.org>,
        Sima Vetter <daniel.vetter@...ll.ch>,
        dri-devel@...ts.freedesktop.org,
        Andrew Worsley <amworsley@...il.com>,
        Hector Martin <marcan@...can.st>,
        Sergio Lopez <slp@...hat.com>,
        Frank Rowand <frowand.list@...il.com>,
        devicetree@...r.kernel.org
Subject: Re: [RFC PATCH] of/platform: Disable sysfb if a simple-framebuffer
 node is found

On Mon, Nov 13, 2023 at 2:53 AM Javier Martinez Canillas
<javierm@...hat.com> wrote:
>
> Some DT platforms use EFI to boot and in this case the EFI Boot Services
> may register a EFI_GRAPHICS_OUTPUT_PROTOCOL handle, that will later be
> queried by the Linux EFI stub to fill the global struct screen_info data.
>
> The data is used by the Generic System Framebuffers (sysfb) framework to
> add a platform device with platform data about the system framebuffer.
>
> But if there is a "simple-framebuffer" node in the DT, the OF core will
> also do the same and add another device for the system framebuffer.
>
> This could lead for example, to two platform devices ("simple-framebuffer"
> and "efi-framebuffer") to be added and matched with their corresponding
> drivers. So both efifb and simpledrm will be probed, leading to following:
>
> [    0.055752] efifb: framebuffer at 0xbd58dc000, using 16000k, total 16000k
> [    0.055755] efifb: mode is 2560x1600x32, linelength=10240, pages=1
> [    0.055758] efifb: scrolling: redraw
> [    0.055759] efifb: Truecolor: size=2:10:10:10, shift=30:20:10:0
> ...
> [    3.295896] simple-framebuffer bd58dc000.framebuffer: [drm] *ERROR*
> could not acquire memory range [??? 0xffff79f30a29ee40-0x2a5000001a7
> flags 0x0]: -16
> [    3.298018] simple-framebuffer: probe of bd58dc000.framebuffer
> failed with error -16
>
> To prevent the issue, make the OF core to disable sysfb if there is a node
> with a "simple-framebuffer" compatible. That way only this device will be
> registered and sysfb would not attempt to register another one using the
> screen_info data even if this has been filled.
>
> This seems the correct thing to do in this case because:
>
> a) On a DT platform, the DTB is the single source of truth since is what
>    describes the hardware topology. Even if EFI Boot Services are used to
>    boot the machine.

This is the opposite of what we do for memory and memory reservations.
EFI is the source of truth for those.

This could also lead to an interesting scenario. As simple-framebuffer
can define its memory in a /reserved-memory node, but that is ignored
in EFI boot. Probably would work, but only because EFI probably
generates its memory map table from the /reserved-memory nodes.

Rob