linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jonathan Toppins <jtoppins@redhat.com>
To: Bhupesh Sharma <bhsharma@redhat.com>
Cc: linux-arm-kernel <linux-arm-kernel@lists.infradead.org>,
	astone@redhat.com, Jonathan Masters <jcm@redhat.com>,
	Catalin Marinas <catalin.marinas@arm.com>,
	Will Deacon <will.deacon@arm.com>,
	rafael.j.wysocki@intel.com, Ingo Molnar <mingo@kernel.org>,
	Prarit Bhargava <prarit@redhat.com>,
	James Morse <james.morse@arm.com>,
	andriy.shevchenko@linux.intel.com, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] arm64/acpi: make ACPI boot preference configurable
Date: Tue, 27 Feb 2018 09:44:09 -0500	[thread overview]
Message-ID: <1b5a55bd-5bc7-ecd0-99f0-71dd05119743@redhat.com> (raw)
In-Reply-To: <CACi5LpM9hn17o7i7R3GUjQYy=6DFtCFKSbDUN7A7MGBTuf7=xw@mail.gmail.com>

On 02/27/2018 07:40 AM, Bhupesh Sharma wrote:
> Hi,
> 
> On Tue, Feb 27, 2018 at 11:35 AM, Jonathan Toppins <jtoppins@redhat.com> wrote:
>> This patch allows a user to configure ACPI to be preferred over
>> device-tree.
>>
>> Currently for ACPI to be used a user either has to set acpi=on on the
>> kernel command line or make sure any device tree passed to the kernel
>> is empty. If the dtb passed to the kernel is non-empty then device-tree
>> will be chosen as the boot method of choice even if it is not correct.
> 
> Hmm. Not sure if I correctly understand what you mean here by the term
> 'incorrect device tree'. Do you mean a corrupted device tree blob (but
> normally we can catch those cases via the device tree header) or a
> deliberate (or a broken) firmware attempt to pass an incorrect device
> tree blob to the OS.

I mean a device tree that doesn't list all devices in the SOC. So it is
more incomplete than incorrect. It could also be incorrect in that it
doesn't list proper timings, memory/pci/etc.

> 
> If its the later, I think the onus should be on the firmware (u-boot
> or UEFI or others.. ) to fix the problems. I know we carry a lot of
> fixes in the kernel for x86 firmware quirks but then we have several
> broken x86 machines on which kernel has been running since several
> years now.
> 
> IMO, if we have a known firmware quirk (to fix the broken DTB being
> passed from the firmware), we can look at adding it in the early arm64
> kernel code (similar to the quirk handling we do in the x86 early
> kernel code for broken firmware), rather than forcing ACPI as the boot
> method.
> 
>> To prevent this situation where a system is only intended to be booted
>> via ACPI a user can set this kernel configuration so it ignores
>> device-tree settings unless ACPI table checks fail.
> 
> Or, if decide to depreciate DTB as the boot method for such boards,
> can we look at setting 'acpi=force' in the bootagrs always to make
> sure that ACPI (and no fallback on DTB) is forced as the boot method
> for such arm64 machines.

For arm64 DT is suppose to *not* be the preferred method, yet still DT
is preferred if the firmware provides both tables to the kernel. So it
seems reasonable to eventually have a default that effectively does
acpi=force for arm64. This patch was taking the halfway approach to just
have the kernel prefer acpi. I would prefer to just change to kernel
bool values instead of compiling in kernel command line args, as command
line args are usually left for the end user to play with.

-Jon

  reply	other threads:[~2018-02-27 14:44 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-02-27  6:05 [PATCH] arm64/acpi: make ACPI boot preference configurable Jonathan Toppins
2018-02-27  7:22 ` Ard Biesheuvel
2018-02-27 14:28   ` Jonathan Toppins
2018-02-27 14:54     ` Ard Biesheuvel
2018-02-27 14:55     ` Robin Murphy
2018-02-27 12:40 ` Bhupesh Sharma
2018-02-27 14:44   ` Jonathan Toppins [this message]
2018-02-27 17:05     ` Mark Rutland
2018-02-27 18:59     ` Bhupesh Sharma
2018-02-28 10:07       ` Andy Shevchenko
2018-02-28 10:10         ` Rafael J. Wysocki
2018-02-28 10:32         ` Bhupesh Sharma

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=1b5a55bd-5bc7-ecd0-99f0-71dd05119743@redhat.com \
    --to=jtoppins@redhat.com \
    --cc=andriy.shevchenko@linux.intel.com \
    --cc=astone@redhat.com \
    --cc=bhsharma@redhat.com \
    --cc=catalin.marinas@arm.com \
    --cc=james.morse@arm.com \
    --cc=jcm@redhat.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@kernel.org \
    --cc=prarit@redhat.com \
    --cc=rafael.j.wysocki@intel.com \
    --cc=will.deacon@arm.com \
    /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).