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.