From: Al Stone <al.stone@linaro.org>
To: Matthew Garrett <mjg59@srcf.ucam.org>
Cc: linux-acpi@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
patches@linaro.org, linaro-kernel@lists.linaro.org,
linaro-acpi@lists.linaro.org
Subject: Re: [PATCH v4 3/5] ACPI: HW reduced mode does not allow use of the FADT sci_interrupt field
Date: Mon, 06 Jan 2014 16:14:26 -0700 [thread overview]
Message-ID: <52CB38D2.30307@linaro.org> (raw)
In-Reply-To: <20131227045630.GA21429@srcf.ucam.org>
On 12/26/2013 09:56 PM, Matthew Garrett wrote:
> On Mon, Dec 16, 2013 at 05:16:39PM -0700, al.stone@linaro.org wrote:
>
>> + if (!acpi_gbl_reduced_hardware) {
>
> I don't really understand this. You've explained that runtime hardware
> reduced mode switching isn't expected to work, but you're making this
> conditional on a runtime flag?
>
Correct. My apologies if I've made this unclear.
Suppose I build a kernel with full ACPI support. The kernel would
then include legacy and hardware-reduced support. If I pass that
kernel ACPI tables specifying legacy mode, things work fine. If I
pass that same kernel ACPI tables with the hardware-reduced flag
set in the FADT, that should also work -- iff the ACPI driver checks
the acpi_gbl_reduced_hardware flag at run-time. This patch is adding
some of those checks that were missing so that at least the files in
drivers/acpi/*.[ch] are correct; I contend that there are still places
in the drivers/acpi/acpica/*.[ch] files where a Linux driver can call
code it should not be allowed to when in hardware-reduced (e.g., when
using the ACPI global lock [0]). Patching the ACPICA code I'm viewing
as a separate issue yet to be done.
If I build a kernel with only hardware-reduced ACPI support, using
ACPI tables without the hardware-reduced flag set in the FADT will
clearly not work -- nor do I expect it to in this case since most of
the legacy code gets removed at compile time. If the ACPI tables do
have hardware-reduced mode set in the FADT, I expect the kernel to
behave correctly. It may turn out to be exactly the same patch for
ACPICA as mentioned above, but I contend that ACPICA does not
completely handle this case properly at runtime, either.
Does that make sense?
[0] No driver should be doing this but it cannot currently be precluded
by the kernel. You can call me paranoid but I think if it can be
abused by a driver, it will be.
--
ciao,
al
-----------------------------------
Al Stone
Software Engineer
Linaro Enterprise Group
al.stone@linaro.org
-----------------------------------
WARNING: multiple messages have this Message-ID (diff)
From: al.stone@linaro.org (Al Stone)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v4 3/5] ACPI: HW reduced mode does not allow use of the FADT sci_interrupt field
Date: Mon, 06 Jan 2014 16:14:26 -0700 [thread overview]
Message-ID: <52CB38D2.30307@linaro.org> (raw)
In-Reply-To: <20131227045630.GA21429@srcf.ucam.org>
On 12/26/2013 09:56 PM, Matthew Garrett wrote:
> On Mon, Dec 16, 2013 at 05:16:39PM -0700, al.stone at linaro.org wrote:
>
>> + if (!acpi_gbl_reduced_hardware) {
>
> I don't really understand this. You've explained that runtime hardware
> reduced mode switching isn't expected to work, but you're making this
> conditional on a runtime flag?
>
Correct. My apologies if I've made this unclear.
Suppose I build a kernel with full ACPI support. The kernel would
then include legacy and hardware-reduced support. If I pass that
kernel ACPI tables specifying legacy mode, things work fine. If I
pass that same kernel ACPI tables with the hardware-reduced flag
set in the FADT, that should also work -- iff the ACPI driver checks
the acpi_gbl_reduced_hardware flag at run-time. This patch is adding
some of those checks that were missing so that at least the files in
drivers/acpi/*.[ch] are correct; I contend that there are still places
in the drivers/acpi/acpica/*.[ch] files where a Linux driver can call
code it should not be allowed to when in hardware-reduced (e.g., when
using the ACPI global lock [0]). Patching the ACPICA code I'm viewing
as a separate issue yet to be done.
If I build a kernel with only hardware-reduced ACPI support, using
ACPI tables without the hardware-reduced flag set in the FADT will
clearly not work -- nor do I expect it to in this case since most of
the legacy code gets removed at compile time. If the ACPI tables do
have hardware-reduced mode set in the FADT, I expect the kernel to
behave correctly. It may turn out to be exactly the same patch for
ACPICA as mentioned above, but I contend that ACPICA does not
completely handle this case properly at runtime, either.
Does that make sense?
[0] No driver should be doing this but it cannot currently be precluded
by the kernel. You can call me paranoid but I think if it can be
abused by a driver, it will be.
--
ciao,
al
-----------------------------------
Al Stone
Software Engineer
Linaro Enterprise Group
al.stone at linaro.org
-----------------------------------
next prev parent reply other threads:[~2014-01-06 23:14 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-12-17 0:16 [PATCH v4 0/5] Hardware Reduced Mode Cleanup for ACPI al.stone
2013-12-17 0:16 ` al.stone at linaro.org
2013-12-17 0:16 ` [PATCH v4 1/5] ACPI: introduce CONFIG_ACPI_REDUCED_HARDWARE to enable this ACPI mode al.stone
2013-12-17 0:16 ` al.stone at linaro.org
2013-12-27 4:58 ` Matthew Garrett
2013-12-27 4:58 ` Matthew Garrett
2014-01-06 22:38 ` Al Stone
2014-01-06 22:38 ` Al Stone
2013-12-17 0:16 ` [PATCH v4 2/5] ACPI: bus master reload not supported in reduced HW mode al.stone
2013-12-17 0:16 ` al.stone at linaro.org
2013-12-17 0:16 ` [PATCH v4 3/5] ACPI: HW reduced mode does not allow use of the FADT sci_interrupt field al.stone
2013-12-17 0:16 ` al.stone at linaro.org
2013-12-27 4:56 ` Matthew Garrett
2013-12-27 4:56 ` Matthew Garrett
2014-01-06 23:14 ` Al Stone [this message]
2014-01-06 23:14 ` Al Stone
2013-12-17 0:16 ` [PATCH v4 4/5] ACPI: in HW reduced mode, using FADT PM information is not allowed al.stone
2013-12-17 0:16 ` al.stone at linaro.org
2013-12-17 0:16 ` [PATCH v4 5/5] ACPI: do not map/unmap memory regions for FADT entries in reduced HW mode al.stone
2013-12-17 0:16 ` al.stone at linaro.org
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=52CB38D2.30307@linaro.org \
--to=al.stone@linaro.org \
--cc=linaro-acpi@lists.linaro.org \
--cc=linaro-kernel@lists.linaro.org \
--cc=linux-acpi@vger.kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=mjg59@srcf.ucam.org \
--cc=patches@linaro.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.