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

On Mon, Dec 4, 2023 at 3:39 AM Javier Martinez Canillas
<javierm@...hat.com> wrote:
>
> Rob Herring <robh@...nel.org> writes:
>
> Hello Rob,
>
> > On Fri, Dec 1, 2023 at 4:21 AM Javier Martinez Canillas
>
> [...]
>
> >> >> I don't have a better idea than this patch but maybe Thomas or Sima do?
> >> >
> >> > At SUSE, we've carried such a patch in our repos for some time. It works
> >> > around the double-framebuffer problem in a similar way. [1]
> >> >
> >>
> >> Thanks for the information. I see that your patch is basically mine but
> >> doing it unconditionally while this one only does the sysfb_disable() if
> >> a "simple-framebuffer" DT node has been found.
> >>
> >> > As Javier mentioned, we do track the framebuffer ranges for EFI/VESA/OF
> >> > framebuffers in the graphics aperture helpers. Fbdev has done this for
> >> > decades, and the current codebase extends and harmonizes this
> >> > functionality among fbdev and DRM drivers.
> >> >
> >> > WRT DT vs EFI: AFAIK the EFI support on affected platforms looks at the
> >> > DT to set up the EFI framebuffer. So IMHO the DT is the authoritative
> >> > source on the framebuffer.
> >> >
> >>
> >> Agreed. Sima Vetter also mentioned on IRC that they think this patch is
> >> the least bad option. Rob, Ard any thoughts? Maybe we can land this as
> >> a fix and then figure how this could be better handled in the long term?
> >
> > What about moving the DT setup code here to sysfb? Then we just setup
> > the right thing up front.
> >
>
> Right now sysfb is pretty platform agnostic, in the sense that just looks
> at the screen_info global struct and uses it to add the platform data that
> contains the firmware provided framebuffer.
>
> How the screen_info was filled (e.g: by the Linux EFI stub using the GOP
> or the x86 early boot code using VESA) is transparent to sysfb. For this
> reason adding platform specific logic there, like finding OF nodes, is not
> desirable.
>
> I also suggested to Thomas to move the DT setup code to sysfb but he said
> that would be the wrong approach for the reason mentioned above. Please
> correct me Thomas if I'm misremembering here.
>
> > However, there might be one other issue with that and this fix. The DT
> > simplefb can have resources such as clocks and regulators. With
> > fw_devlink, the driver won't probe until those dependencies are met.
> > So if you want the framebuffer console up early, then you may want to
> > register the EFI framebuffer first and then handoff to the DT simplefb
> > when it probes (rather than registering the device).
> >
> > But I agree, probably better to take this patch now and have those
> > quirks instead of flat out not working.
> >
>
> If we do that what's the plan? Are you thinking about merging this patch
> through your OF tree or do you want to go through drm-misc with your ack?

I can take it. Do we need this in 6.7 and stable?

Rob