Re: [PATCH 2/4] efi/libstub: detect panel-id

From: Ard Biesheuvel <ard.biesheuvel@linaro.org>
To: Rob Clark <robdclark@gmail.com>
Cc: dri-devel <dri-devel@lists.freedesktop.org>,
	linux-arm-msm <linux-arm-msm@vger.kernel.org>,
	freedreno@lists.freedesktop.org,
	aarch64-laptops@lists.linaro.org,
	Rob Clark <robdclark@chromium.org>,
	Ingo Molnar <mingo@kernel.org>, Will Deacon <will@kernel.org>,
	Leif Lindholm <leif.lindholm@linaro.org>,
	Alexander Graf <agraf@suse.de>,
	Steve Capper <steve.capper@arm.com>,
	Lukas Wunner <lukas@wunner.de>,
	Julien Thierry <julien.thierry@arm.com>,
	linux-efi <linux-efi@vger.kernel.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 2/4] efi/libstub: detect panel-id
Date: Tue, 2 Jul 2019 22:35:16 +0200	[thread overview]
Message-ID: <CAKv+Gu-KhPJxxJA3+J813OPcnoAD4nHq6MhiRTJSd_5y1dPNnw@mail.gmail.com> (raw)
In-Reply-To: <CAKv+Gu_8BOt+f8RTspHo+se-=igZba1zL0+jWLV2HuuUXCKYpA@mail.gmail.com>

On Tue, 2 Jul 2019 at 22:26, Ard Biesheuvel <ard.biesheuvel@linaro.org> wrote:
>
> On Sun, 30 Jun 2019 at 22:36, Rob Clark <robdclark@gmail.com> wrote:
> >
> > From: Rob Clark <robdclark@chromium.org>
> >
> > On snapdragon aarch64 laptops, a 'UEFIDisplayInfo' variable is provided
> > to communicate some information about the display.  Crutially it has the
> > panel-id, so the appropriate panel driver can be selected.  Read this
> > out and stash in /chosen/panel-id so that display driver can use it to
> > pick the appropriate panel.
> >
> > Signed-off-by: Rob Clark <robdclark@chromium.org>
>
> Hi Rob,
>
> I understand why you are doing this, but this *really* belongs elsewhere.
>
> So we are dealing with a platform that violates the UEFI spec, since
> it does not bother to implement variable services at runtime (because
> MS let the vendor get away with this).
>

To clarify, the above remark applies to populating the DT from the OS
rather than from the firmware.

> First of all, to pass data between the EFI stub and the OS proper, we
> should use a configuration table rather than a DT property, since the
> former is ACPI/DT agnostic. Also, I'd like the consumer of the data to
> actually interpret it, i.e., just dump the whole opaque thing into a
> config table in the stub, and do the parsing in the OS proper.
>
> However, I am not thrilled at adding code to the stub that
> unconditionally looks for some variable with some magic name on all
> ARM/arm64 EFI systems, so this will need to live under a Kconfig
> option that depends on ARM64 (and does not default to y)
>

... but saving variables at boot time for consumption at runtime is
something that we will likely see more of in the future.