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

Andrew Worsley <amworsley@...il.com> writes:

Hello Andrew,

> On Mon, 13 Nov 2023 at 20:18, Thomas Zimmermann <tzimmermann@...e.de> wrote:
>> Am 13.11.23 um 09:51 schrieb Javier Martinez Canillas:
>> > 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.
>> >

[...]

>
> I applied the patch and just the simpledrm driver is probed (the efifb is not):
>
> grep -i -E 'drm|efifb' --color -C3 dmesg-6.5.0-asahi-00780-gf5aadc85a34d.txt
> [    2.621433] systemd-journald[276]: varlink-21: Changing state
> idle-server \xe2\x86\x92 pending-disconnect
> [    2.621437] systemd-journald[276]: varlink-21: Changing state
> pending-disconnect \xe2\x86\x92 processing-disconnect
> [    2.621439] systemd-journald[276]: varlink-21: Changing state
> processing-disconnect \xe2\x86\x92 disconnected
> [    2.878828] [drm] Initialized simpledrm 1.0.0 20200625 for
> bd58dc000.framebuffer on minor 0
> [    2.909764] Console: switching to colour frame buffer device 160x50

Great, thanks for testing. The patch works then as expected. Can I get
your Tested-by then ?

>
> I am wondering if the drm_aperture_remove_framebuffers() shouldn't be
> called in the probe function anyway
> as it ends up overriding the efifb one as wanted and handles the case
> the simpledrm (CONFIG_DRM_SIMPLEDRM)
> is not present.
> Perhaps there is an accepted principle that such kernels *should* fail
> to set up a FB?
>

We were talking with Thomas that the sysfb design seems to be reaching its
limits and need some rework but currently you either need some driver that
matches the "simple-framebuffer" device that is registered by OF or won't
get an early framebuffer in the system.

That could be either simpledrm or simplefb. But if a DT has a device node
for "simple-framebuffer", how can the OF core know if there is a driver to
match that device? And same for any other device defined in the DTB.

It's similar on platforms that use sysfb to register the device (e.g: x86)
since either "simple-framebuffer" is registered (if CONFIG_SYSFB_SIMPLEFB
is enabled) or "efi-framebuffer" (if CONFIG_SYSFB_SIMPLEFB is disabled).

That means CONFIG_SYSFB_SIMPLEFB=y and CONFIG_DRM_SIMPLEDRM disabled won't
work either, even if CONFIG_FB_EFI=y which is the case you are mentioning.

What I think that doesn't make sense is to remove conflicting framebuffers
from drivers that can only handle firmware provided framebuffers. As said
in the other thread, drm_aperture_remove_framebuffers() is only meant for
native DRM drivers.

> Andrew
>

-- 
Best regards,

Javier Martinez Canillas
Core Platforms
Red Hat