[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <bcd83518-8652-409e-b614-30edab6f9b16@sirena.org.uk>
Date: Mon, 25 Nov 2024 17:41:47 +0000
From: Mark Brown <broonie@...nel.org>
To: Ard Biesheuvel <ardb@...nel.org>
Cc: Yeoreum Yun <yeoreum.yun@....com>, sami.mujawar@....com,
sudeep.holla@....com, pierre.gondois@....com, hagarhem@...zon.com,
catalin.marinas@....com, will@...nel.org, guohanjun@...wei.com,
Jonathan.Cameron@...wei.com, linux-arm-kernel@...ts.infradead.org,
linux-kernel@...r.kernel.org, linux-efi@...r.kernel.org
Subject: Re: [PATCH v2 1/2] arm64/acpi: panic when failed to init acpi table
with acpi=force option
On Mon, Nov 25, 2024 at 06:30:06PM +0100, Ard Biesheuvel wrote:
> On Mon, 25 Nov 2024 at 18:08, Yeoreum Yun <yeoreum.yun@....com> wrote:
> > when the acpi=force option is used,
> > the system does not fall back to the device tree (DT).
> > If it fails to initialize the ACPI table, it cannot proceed further.
> > In such cases, the system should invoke panic() to avoid contradicting
> > the user's explicit intent, as failing or
> > proceeding with unintended behavior would violate their wishes.
> Calling panic() at this point does not achieve anything useful,
> though. Without ACPI tables or a DT, the only way to observe this
> panic message is by using earlycon= with an explicit MMIO address, and
> it might be better to limp on instead. Is there anything bad that
> might happen because of this, other than the user's wishes getting
> violated?
It does rather depend why the user specified acpi=force, it's kind of an
unusual thing to specify on most systems...
Download attachment "signature.asc" of type "application/pgp-signature" (489 bytes)
Powered by blists - more mailing lists