From: "Rafael J. Wysocki" <rjw@rjwysocki.net>
To: Lv Zheng <lv.zheng@intel.com>
Cc: "Rafael J. Wysocki" <rafael.j.wysocki@intel.com>,
Len Brown <len.brown@intel.com>, Lv Zheng <zetalog@gmail.com>,
linux-kernel@vger.kernel.org, linux-acpi@vger.kernel.org
Subject: Re: [PATCH v2 3/3] ACPI / sysfs: Provide quirk mechanism to prevent GPE flooding
Date: Mon, 04 Jul 2016 16:07:31 +0200 [thread overview]
Message-ID: <4384014.XRXPIxbxM5@vostro.rjw.lan> (raw)
In-Reply-To: <d1685f10f7fd135f984e4d08bfa5faedf47c9a23.1466662469.git.lv.zheng@intel.com>
On Thursday, June 23, 2016 02:20:30 PM Lv Zheng wrote:
> Sometimes, the users may require a quirk to be provided from ACPI subsystem
> core to prevent a GPE from flooding. Normally, if a GPE cannot be
> dispatched, ACPICA core automatically prevents the GPE from firing. But
> there are cases the GPE is dispatched by _Lxx/_Exx provided via AML table,
> and OSPM is lacking of the knowledge to get _Lxx/_Exx correctly executed to
> handle the GPE, thus the GPE flooding may still occur.
>
> This patch provides a quirk mechanism to stop this kind of GPE flooding.
>
> Link: https://bugzilla.kernel.org/show_bug.cgi?id=53071
> Link: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/887793
> Signed-off-by: Lv Zheng <lv.zheng@intel.com>
> ---
> Documentation/kernel-parameters.txt | 10 +++++++
> drivers/acpi/internal.h | 1 +
> drivers/acpi/scan.c | 1 +
> drivers/acpi/sysfs.c | 56 +++++++++++++++++++++++++++++++++++
> 4 files changed, 68 insertions(+)
>
> diff --git a/Documentation/kernel-parameters.txt b/Documentation/kernel-parameters.txt
> index 82b42c9..2079b9a 100644
> --- a/Documentation/kernel-parameters.txt
> +++ b/Documentation/kernel-parameters.txt
> @@ -274,6 +274,16 @@ bytes respectively. Such letter suffixes can also be entirely omitted.
> use by PCI
> Format: <irq>,<irq>...
>
> + acpi_mask_gpe= [HW,ACPI]
> + Due to the existence of _Lxx/_Exx, some GPEs triggered
> + by unsupported hardware/firmware features can result in
> + GPE floodings that cannot be automatically disabled by
> + the GPE dispatcher.
> + This facility can be used to prevent such uncontrolled
> + GPE floodings.
> + Format: <int>
> + Support masking of GPEs numbered from 0x00 to 0x63.
So what about if someone needs to mask more than one GPE?
The code indicates that acpi_mask_gpe= needs to be used multiple times then,
but it would be good to mention that here too.
> +
> acpi_no_auto_serialize [HW,ACPI]
> Disable auto-serialization of AML methods
> AML control methods that contain the opcodes to create
> diff --git a/drivers/acpi/internal.h b/drivers/acpi/internal.h
> index 27cc7fe..370e184 100644
> --- a/drivers/acpi/internal.h
> +++ b/drivers/acpi/internal.h
> @@ -37,6 +37,7 @@ void acpi_amba_init(void);
> static inline void acpi_amba_init(void) {}
> #endif
> int acpi_sysfs_init(void);
> +void acpi_gpe_apply_masked_gpes(void);
> void acpi_container_init(void);
> void acpi_memory_hotplug_init(void);
> #ifdef CONFIG_ACPI_HOTPLUG_IOAPIC
> diff --git a/drivers/acpi/scan.c b/drivers/acpi/scan.c
> index 5f28cf7..ea70d20 100644
> --- a/drivers/acpi/scan.c
> +++ b/drivers/acpi/scan.c
> @@ -1958,6 +1958,7 @@ int __init acpi_scan_init(void)
> }
> }
>
> + acpi_gpe_apply_masked_gpes();
> acpi_update_all_gpes();
>
> out:
> diff --git a/drivers/acpi/sysfs.c b/drivers/acpi/sysfs.c
> index 0303c99..6fabbcf 100644
> --- a/drivers/acpi/sysfs.c
> +++ b/drivers/acpi/sysfs.c
> @@ -704,6 +704,62 @@ end:
> return result ? result : size;
> }
>
> +/*
> + * A Quirk Mechanism for GPE Flooding Prevention:
> + *
> + * Quirks may be needed to prevent GPE flooding on a specific GPE. The
> + * flooding typically cannot be detected and automatically prevented by
> + * ACPI_GPE_DISPATCH_NONE check because there is a _Lxx/_Exx prepared in
> + * the AML tables. This normally indicates a feature gap in Linux, thus
> + * instead of providing endless quirk tables, we provide a boot parameter
> + * for those who want this quirk. For example, if the users want to prevent
> + * the GPE flooding for GPE 00, they need to specify the following boot
> + * parameter:
> + * acpi_mask_gpe=0x00
> + * The masking status can be modified by the following runtime controlling
> + * interface:
> + * echo unmask > /sys/firmware/acpi/interrupts/gpe00
> + */
> +
> +/*
> + * Currently, the GPE flooding prevention only supports to mask the GPEs
> + * numbered from 00 to 63.
> + */
> +#define ACPI_MASKABLE_GPE_MAX 64
> +
> +static u64 acpi_masked_gpes;
> +
> +static int __init acpi_gpe_set_masked_gpes(char *val)
> +{
> + u8 gpe;
> +
> + if (kstrtou8(val, 0, &gpe) || gpe > ACPI_MASKABLE_GPE_MAX)
> + return -EINVAL;
> + acpi_masked_gpes |= ((u64)1<<gpe);
This looks sort of hackish.
In principle you can create a list here and then free it when you do the
actual masking.
Also, why can't the masking be applied right here?
> +
> + return 1;
> +}
> +__setup("acpi_mask_gpe=", acpi_gpe_set_masked_gpes);
> +
> +void acpi_gpe_apply_masked_gpes(void)
> +{
> + acpi_handle handle;
> + acpi_status status;
> + u8 gpe;
> +
> + for (gpe = 0;
> + gpe < min_t(u8, ACPI_MASKABLE_GPE_MAX, acpi_current_gpe_count);
> + gpe++) {
> + if (acpi_masked_gpes & ((u64)1<<gpe)) {
> + status = acpi_get_gpe_device(gpe, &handle);
> + if (ACPI_SUCCESS(status)) {
> + pr_info("Masking GPE 0x%x.\n", gpe);
> + (void)acpi_mask_gpe(handle, gpe, TRUE);
> + }
> + }
> + }
> +}
> +
> void acpi_irq_stats_init(void)
> {
> acpi_status status;
>
Thanks,
Rafael
next prev parent reply other threads:[~2016-07-04 14:03 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <cover.1463389639.git.lv.zheng@intel.com>
2016-05-16 9:11 ` [PATCH 1/3] ACPICA: Events: Introduce acpi_block_gpe()/acpi_unblock_gpe()/acpi_control_gpe_handling() to allow administrative GPE enabling/disabling Lv Zheng
2016-06-07 22:01 ` Rafael J. Wysocki
2016-06-08 7:49 ` Zheng, Lv
2016-06-08 20:17 ` Rafael J. Wysocki
2016-05-16 9:11 ` [PATCH 2/3] ACPI / sys: Update /sys/firmware/acpi/interrupts/gpexx using new GPE forced disabling/enabling mechanism Lv Zheng
2016-05-16 9:11 ` [PATCH 3/3] ACPI / sysfs: Provide quirk mechanism to prevent GPE flooding Lv Zheng
2016-06-23 6:20 ` [PATCH v2 0/3] ACPI / gpe: Add GPE masking/unmasking mechanism Lv Zheng
2016-06-23 6:20 ` [PATCH v2 1/3] ACPICA: Events: Introduce acpi_mask_gpe()/acpi_unmask_gpe() to implement GPE masking mechanism Lv Zheng
2016-07-04 13:59 ` [UPDATE PATCH v2 1/3] ACPICA: Events: Introduce acpi_mask_gpe() " Rafael J. Wysocki
2016-07-16 0:55 ` Rafael J. Wysocki
2016-07-18 10:34 ` Zheng, Lv
2016-06-23 6:20 ` [PATCH v2 2/3] ACPI / sys: Update /sys/firmware/acpi/interrupts/gpexx using new " Lv Zheng
2016-06-23 6:20 ` [PATCH v2 3/3] ACPI / sysfs: Provide quirk mechanism to prevent GPE flooding Lv Zheng
2016-07-04 14:07 ` Rafael J. Wysocki [this message]
2016-12-08 4:50 ` [PATCH v3] " Lv Zheng
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=4384014.XRXPIxbxM5@vostro.rjw.lan \
--to=rjw@rjwysocki.net \
--cc=len.brown@intel.com \
--cc=linux-acpi@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=lv.zheng@intel.com \
--cc=rafael.j.wysocki@intel.com \
--cc=zetalog@gmail.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).