On Tue, 2 Jul 2019 at 22:26, Ard Biesheuvel <ard.biesheuvel@xxxxxxxxxx> wrote: > > On Sun, 30 Jun 2019 at 22:36, Rob Clark <robdclark@xxxxxxxxx> wrote: > > > > From: Rob Clark <robdclark@xxxxxxxxxxxx> > > > > 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@xxxxxxxxxxxx> > > 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.
