linux-kernel - Re: [PATCH 0/4] drm+dt+efi: support devices with multiple possible panels

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: <20190630211520.GI7043@pendragon.ideasonboard.com>
Date:   Mon, 1 Jul 2019 00:15:20 +0300
From:   Laurent Pinchart <laurent.pinchart@...asonboard.com>
To:     Rob Clark <robdclark@...il.com>
Cc:     dri-devel <dri-devel@...ts.freedesktop.org>,
        linux-arm-msm <linux-arm-msm@...r.kernel.org>,
        freedreno <freedreno@...ts.freedesktop.org>,
        aarch64-laptops@...ts.linaro.org,
        Rob Clark <robdclark@...omium.org>,
        Ard Biesheuvel <ard.biesheuvel@...aro.org>,
        Catalin Marinas <catalin.marinas@....com>,
        "open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS" 
        <devicetree@...r.kernel.org>, Ingo Molnar <mingo@...nel.org>,
        Julien Thierry <julien.thierry@....com>,
        "open list:EXTENSIBLE FIRMWARE INTERFACE (EFI)" 
        <linux-efi@...r.kernel.org>,
        open list <linux-kernel@...r.kernel.org>,
        Lukas Wunner <lukas@...ner.de>,
        Steve Capper <steve.capper@....com>,
        Will Deacon <will@...nel.org>
Subject: Re: [PATCH 0/4] drm+dt+efi: support devices with multiple possible
 panels

Hi Rob,

On Sun, Jun 30, 2019 at 02:05:21PM -0700, Rob Clark wrote:
> On Sun, Jun 30, 2019 at 1:47 PM Laurent Pinchart wrote:
> > On Sun, Jun 30, 2019 at 01:36:04PM -0700, Rob Clark wrote:
> > > From: Rob Clark <robdclark@...omium.org>
> > >
> > > Now that we can deal gracefully with bootloader (firmware) initialized
> > > display on aarch64 laptops[1], the next step is to deal with the fact
> > > that the same model of laptop can have one of multiple different panels.
> > > (For the yoga c630 that I have, I know of at least two possible panels,
> > > there might be a third.)
> >
> > I have to ask the obvious question: why doesn't the boot loader just
> > pass a correct DT to Linux ? There's no point in passing a list of
> > panels that are not there, this seems quite a big hack to me. A proper
> > boot loader should construct the DT based on hardware detection.
> 
> Hi Laurent,
> 
> Actually the bootloader on these devices is passing *no* dt (they boot
> ACPI, we are loading dtb from grub currently)

Ah, the broken promises of ACPI on ARM64. I wonder how long it will take
before a public acknowledgement that it was a bad idea. Bad ideas happen
and can be forgiven, but stubborness in claiming it was the right
decision is another story.

(Not that you can be blamed for this of course :-))

> I think normally a device built w/ dt in mind would populate
> /chosen/panel-id directly (rather than the way it is currently
> populated based on reading an efi variable prior to ExitBootServices).
> But that is considerably easier ask than having it re-write of_graph
> bindings. Either way, we aren't in control of the bootloader on these
> devices,

If you can't control the initial boot loader, then I see two options,
none of which you will like I'm afraid.

- As you pass the DT to Linux from grub, there's your intermediate boot
  loader where you can construct a valid DT.

- If the ACPI cult needs to be venerated, then drivers should be
  converted to support ACPI without the need for DT.

A possible a middleground could be a platform driver (in
drivers/firmware/efi/ ? in drivers/platform/ ?) that will patch the DT
to instantiate the right panel based on the information retrieved from
the boot loader. We will need something similar for the Intel IPU3
camera driver, as Intel decided to come up with two different ACPI
"bindings", one for Windows and one for Chrome OS, leaving Windows
machine impossible to handle from a kernel driver due to required
information being hardcoded in Windows drivers shipped by Intel. This is
thus an option that may (unfortunately) need to become more widespread
for ACPI-based systems.

> so it is a matter of coming up with something that works on actual hw
> that we don't like rather than idealized hw that we don't have ;-)

That doesn't however justify not going for the best solution we can
achieve. What do you like best in the above ? :-)

-- 
Regards,

Laurent Pinchart