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

[Leif Lindholm <leif.lindholm@linaro.org>]

On Tue, Jul 02, 2019 at 03:48:48PM -0700, Rob Clark wrote:
> > > 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 leaning like Ard towards preferring a configuration table though.

That removes the question of no runtime services (needing to manually
cache things, at least until EBBR 1.2 (?) is out and in use), and
means we don't have to use different paths for DT and ACPI. Now we
have UEFI in U-Boot, do we really need to worry about the non-UEFI
case?

> 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...

Sure, but that's insurance against bindings changing
non-backwards-compatibly - which there are ways to prevent, and which
streamlining the design for really isn't the way to discourage...

Distros have no need to worry about the DT loader - the whole point of
it is to remove the need for the distro to worry about anything other
than getting the required drivers in.

> 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.

Until the hardware abstractions provided by the system firmware (ACPI)
is supported, these platforms are not going to be appropriate for
end users anyway. No matter how many not-quite-upstream hacks distros
include, they won't be able to support the next minor spin that comes
off the production line and is no longer compatible with existing DTs.

/
    Leif