On Tue, Jul 2, 2019 at 2:59 PM Leif Lindholm <leif.lindholm@xxxxxxxxxx> wrote: > > On Tue, Jul 02, 2019 at 02:01:49PM -0700, Rob Clark wrote: > > > > 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. > > > > yeah, it isn't pretty, but there *are* some other similar cases where > > efi-stub is populating DT.. (like update_fdt_memmap() and > > kaslr-seed).. > > The problem isn't with the stub updating the DT, the problem is what > it updates it with. > > update_fdt_memmap() is the stub filling in the information it > communicates to the main kernel. > > kaslr-seed sets a standard property using a standard interface if that > interface is available to it at the point of execution. > > Since what we're doing here is dressing up an ACPI platform to make it > look like it was a DT platform, and since we have the ability to tweak > the DT before ever passing it to the kernel, let's just do that. > > Yes, I know I said I'd rather not, but it's way nicer than sticking > platform-specific hacks into the EFI stub. > > (If adding it as a DT property is indeed the thing to do.) > > > > ... but saving variables at boot time for consumption at runtime is > > > something that we will likely see more of in the future. > > > > I think this will be nice, but it also doesn't address the need for a > > quirk to get this into /chosen.. I guess we *could* use a shim or > > something that runs before the kernel to do this. But that just seems > > like a logistical/support nightmare. > > > > There is one kernel, and there > > are N distro's, so debugging a users "I don't get a screen at boot" > > problem because their distro missed some shim patch really just > > doesn't seem like a headache I want to have. > > The distros should not need to be aware *at all* of the hacks required > to disguise these platforms as DT platforms. > > If they do, they're already device-specific installers and have > already accepted the logistical/support nightmare. > I guess I'm not *against* a DT loader shim populating the panel-id over into /chosen.. I had it in mind as a backup plan. Ofc still need to get dt folks to buy into /chosen/panel-id but for DT boot I think that is the best option. (At least the /chosen/panel-id approach doesn't require the shim to be aware of how the panel is wired up to dsi controller and whether their is a bridge in between, and that short of thing, so the panel-id approach seems more maintainable that other options.) I am a bit fearful of problems arising from different distros and users using different versions of shim, and how to manage that. I guess if somehow "shim thing" was part of the kernel, there would by one less moving part... I'd know if user had kernel vX.Y.Z they'd be good to go vs not. But *also* depending on a new-enough version of a shim, where the version # is probably not easily apparent to the end user, sounds a bit scary from the "all the things that can go wrong" point of view. Maybe I'm paranoid, but I'm a bit worried about how to manage that. BR, -R
