linux-arm-msm.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Shawn Guo <shawn.guo@linaro.org>
To: Ard Biesheuvel <ardb@kernel.org>
Cc: Catalin Marinas <catalin.marinas@arm.com>,
	Will Deacon <will@kernel.org>,
	Jeffrey Hugo <jhugo@codeaurora.org>,
	Bjorn Andersson <bjorn.andersson@linaro.org>,
	linux-efi <linux-efi@vger.kernel.org>,
	Linux ARM <linux-arm-kernel@lists.infradead.org>,
	linux-arm-msm@vger.kernel.org
Subject: Re: [PATCH] arm64: efi: add check for broken efi poweroff
Date: Fri, 5 Mar 2021 16:02:47 +0800	[thread overview]
Message-ID: <20210305080245.GJ17424@dragon> (raw)
In-Reply-To: <CAMj1kXEezoDanHsKiN566r0xP1o8pQBk5UZPff0zYxG+Aw7-Og@mail.gmail.com>

On Fri, Mar 05, 2021 at 08:46:35AM +0100, Ard Biesheuvel wrote:
> On Fri, 5 Mar 2021 at 08:32, Shawn Guo <shawn.guo@linaro.org> wrote:
> >
> > On Fri, Mar 05, 2021 at 08:01:02AM +0100, Ard Biesheuvel wrote:
> > > On Fri, 5 Mar 2021 at 07:51, Shawn Guo <shawn.guo@linaro.org> wrote:
> > > >
> > > > Poweroff via UEFI Runtime Services doesn't always work on every single
> > > > arm64 machine.  For example, on Lenovo Flex 5G laptop, it results in
> > > > a system reboot rather than shutdown.  Add a DMI check to keep such
> > > > system stay with the original poweroff method (PSCI).
> > > >
> > > > Signed-off-by: Shawn Guo <shawn.guo@linaro.org>
> > >
> > > What is the point of using EFI runtime services on this machine if
> > > poweroff doesn't work either?
> >
> > Hmm, I'm not sure how many EFI runtime services are being used by
> > kernel, but this is the only one broken I have seen.  Not sure we want
> > to disable the whole thing completely.  Also, I'm looking at commit log
> > of 0c5ed61adbdb ("efi/reboot: Allow powering off machines using EFI")
> > below.
> >
> >     Not only can EfiResetSystem() be used to reboot, it can also be used to
> >     power down machines.
> >
> >     By and large, this functionality doesn't work very well across the range
> >     of EFI machines in the wild, so it should definitely only be used as a
> >     last resort. In an ideal world, this wouldn't be needed at all.
> >
> >     Unfortunately, we're starting to see machines where EFI is the *only*
> >     reliable way to power down, and nothing else, not PCI, not ACPI, works.
> >
> > It seems poweroff via EFI runtime services is known not working for
> > every machine, and was meant to be the last resort if nothing else can
> > power off system.  If we try PSCI first on arm64, you do not see my
> > patch at all :)
> >
> > > Can't we just boot this thing with
> > > efi=noruntime?
> >
> > We are trying to get arm64 laptop support into distros, and patching
> > kernel cmdline with 'efi=novamap' is already a pain.  We do not really
> > want to have more of it.
> >
> 
> I suppose we have to rely on DtbLoader for these platforms anyway,
> right? That means we should be able to rely on it to publish a RT_PROP
> configuration table which tells the kernel which EFI runtime services
> are usable and which are not. This way, we could get rid of
> efi=novamap as well.

Two things:

- DtbLoader is loaded as an EFI driver.  It works fine on Yoga C630, but
  it's not loaded by Flex 5G UEFI for some reason.  So DtbLoader is not
  really working on Flex 5G at this point.

- We are running not only DT kernel on these laptops but also ACPI
  kernel in which case DtbLoader shouldn't needed.

> I'd prefer to rely on that than on DMI quirks - we have not used those
> at all on arm64/ARM so far, and the DMI tables are parsed relatively
> late, so in some cases, DMI quirks may not be reliable.

I'm all ears in case there are other runtime mechanisms to get around
it. 

Shawn

  reply	other threads:[~2021-03-05  8:03 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-03-05  6:51 [PATCH] arm64: efi: add check for broken efi poweroff Shawn Guo
2021-03-05  7:01 ` Ard Biesheuvel
2021-03-05  7:31   ` Shawn Guo
2021-03-05  7:46     ` Ard Biesheuvel
2021-03-05  8:02       ` Shawn Guo [this message]
2021-03-05  8:21         ` Ard Biesheuvel
2021-05-17  0:59   ` Shawn Guo
2021-05-18  7:44     ` Ard Biesheuvel
2021-05-19 14:05       ` Shawn Guo
2021-05-19 14:20         ` Ard Biesheuvel

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=20210305080245.GJ17424@dragon \
    --to=shawn.guo@linaro.org \
    --cc=ardb@kernel.org \
    --cc=bjorn.andersson@linaro.org \
    --cc=catalin.marinas@arm.com \
    --cc=jhugo@codeaurora.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-arm-msm@vger.kernel.org \
    --cc=linux-efi@vger.kernel.org \
    --cc=will@kernel.org \
    /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).