linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
To: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: linux-efi <linux-efi@vger.kernel.org>,
	Graeme Gregory <graeme.gregory@linaro.org>,
	"Rafael J. Wysocki" <rjw@rjwysocki.net>,
	Leif Lindholm <leif.lindholm@linaro.org>,
	Al Stone <astone@redhat.com>,
	ACPI Devel Maling List <linux-acpi@vger.kernel.org>,
	Peter Jones <pjones@redhat.com>,
	"Hsiung, Harry L" <harry.l.hsiung@intel.com>,
	linux-arm-kernel <linux-arm-kernel@lists.infradead.org>,
	Len Brown <lenb@kernel.org>
Subject: Re: [PATCH] acpi: bgrt: parse BGRT to obtain BMP address before it gets clobbered
Date: Tue, 22 Jan 2019 18:56:52 +0000	[thread overview]
Message-ID: <20190122185652.GC13206@e107981-ln.cambridge.arm.com> (raw)
In-Reply-To: <CAKv+Gu9-tDRbmt+T3or9pMs78-pU-9BpKorhB60N_=Bxo78A1g@mail.gmail.com>

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@arm.com> 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@redhat.com>
> > > Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
> >
> > 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

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

  reply	other threads:[~2019-01-22 18:57 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-01-22 15:06 [PATCH] acpi: bgrt: parse BGRT to obtain BMP address before it gets clobbered Ard Biesheuvel
2019-01-22 17:32 ` Lorenzo Pieralisi
2019-01-22 18:07   ` Ard Biesheuvel
2019-01-22 18:56     ` Lorenzo Pieralisi [this message]
2019-01-29 15:34     ` Peter Jones
2019-01-23  5:31 ` Dave Young
2019-01-23  9:44   ` Ard Biesheuvel
2019-01-29 16:11     ` Peter Jones
2019-02-09 13:41     ` Ard Biesheuvel
2019-01-29 14:36 ` Ard Biesheuvel
2019-01-29 15:09   ` Rafael J. Wysocki

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20190122185652.GC13206@e107981-ln.cambridge.arm.com \
    --to=lorenzo.pieralisi@arm.com \
    --cc=ard.biesheuvel@linaro.org \
    --cc=astone@redhat.com \
    --cc=graeme.gregory@linaro.org \
    --cc=harry.l.hsiung@intel.com \
    --cc=leif.lindholm@linaro.org \
    --cc=lenb@kernel.org \
    --cc=linux-acpi@vger.kernel.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-efi@vger.kernel.org \
    --cc=pjones@redhat.com \
    --cc=rjw@rjwysocki.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).