Re: [PATCH] acpi: bgrt: parse BGRT to obtain BMP address before it gets clobbered

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Tue, Jan 22, 2019 at 07:07:30PM +0100, Ard Biesheuvel wrote:
> On Tue, 22 Jan 2019 at 18:32, Lorenzo Pieralisi
> <lorenzo.pieralisi@xxxxxxx> wrote:
> >
> > On Tue, Jan 22, 2019 at 04:06:16PM +0100, Ard Biesheuvel wrote:
> > > The bitmap left in the framebuffer by the firmware is described by an
> > > ACPI table called "BGRT", which describes the size, pixel format and
> > > the address of a BMP image in memory. While the BGRT ACPI table is
> > > guaranteed to reside in a "ACPI reclaim" memory region, which is
> > > never touched by Linux. The BMP image, however, typically resides
> > > in EFI Boot Services Memory, which may have been overwritten by the
> > > time the BGRT discovery routine runs.
> > >
> > > So instead, drop the handling from the ACPI init code, and call the
> > > BGRT parsing code immediately after going over the EFI configuration
> > > table array, at which time no memory has been touched yet except for
> > > the .data/.bss regions covered by the static kernel image.
> > >
> > > Unfortunately, this involves a non-trivial amount of ACPI entry
> > > point and root table parsing, but we cannot rely on the normal
> > > ACPI infrastructure yet this early in the boot.
> > >
> > > Also note that we cannot take the 'acpi_disabled' global variable
> > > into account, since it may not have assumed the correct value yet
> > > (on arm64, the default value is '1' which is overridden to '0' if
> > > no DT description has been made available by the firmware)
> > >
> > > Cc: Peter Jones <pjones@xxxxxxxxxx>
> > > Signed-off-by: Ard Biesheuvel <ard.biesheuvel@xxxxxxxxxx>
> >
> > Technically this is a fix, right ?
> >
> 
> I would argue that it is a hack to work around a deficiency in the
> ACPI spec, i.e., that the BGRT table but not the image are passed in
> ACPI reclaim memory.

I assume there are designs out there that this patch is fixing (I
understand it is hackish but there is not much else you can do,
especially so with firmware already in the field), I was wondering
if we want to update older kernels too.

Cheers,
Lorenzo



[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux OMAP]     [Linux MIPS]     [ECOS]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux