The commit 0f27cff8597d ("ACPI: sysfs: Make ACPI GPE mask kernel
parameter cover all GPEs") says:
"Use a bitmap of size 0xFF instead of a u64 for the GPE mask so 256
GPEs can be masked"
But the masking of GPE 0xFF it not supported and the check condition
"gpe > ACPI_MASKABLE_GPE_MAX" is not valid because the type of gpe is
u8.
So modify the macro ACPI_MASKABLE_GPE_MAX to 0x100, and drop the "gpe >
ACPI_MASKABLE_GPE_MAX" check. In addition, update the docs "Format" for
acpi_mask_gpe parameter.
Fixes: 0f27cff8597d ("ACPI: sysfs: Make ACPI GPE mask kernel parameter cover all GPEs")
Signed-off-by: Yunfeng Ye <[email protected]>
---
v1 -> v2:
- drop the "gpe > ACPI_MASKABLE_GPE_MAX" check
- update the docs "Format" from <int> to <byte> for acpi_mask_gpe parameter
- update the commit comment
Documentation/admin-guide/kernel-parameters.txt | 2 +-
drivers/acpi/sysfs.c | 4 ++--
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt
index a84a83f8881e..87e27186dc69 100644
--- a/Documentation/admin-guide/kernel-parameters.txt
+++ b/Documentation/admin-guide/kernel-parameters.txt
@@ -113,7 +113,7 @@
the GPE dispatcher.
This facility can be used to prevent such uncontrolled
GPE floodings.
- Format: <int>
+ Format: <byte>
acpi_no_auto_serialize [HW,ACPI]
Disable auto-serialization of AML methods
diff --git a/drivers/acpi/sysfs.c b/drivers/acpi/sysfs.c
index 75948a3f1a20..0a83ce186bc4 100644
--- a/drivers/acpi/sysfs.c
+++ b/drivers/acpi/sysfs.c
@@ -819,14 +819,14 @@ static ssize_t counter_set(struct kobject *kobj,
* interface:
* echo unmask > /sys/firmware/acpi/interrupts/gpe00
*/
-#define ACPI_MASKABLE_GPE_MAX 0xFF
+#define ACPI_MASKABLE_GPE_MAX 0x100
static DECLARE_BITMAP(acpi_masked_gpes_map, ACPI_MASKABLE_GPE_MAX) __initdata;
static int __init acpi_gpe_set_masked_gpes(char *val)
{
u8 gpe;
- if (kstrtou8(val, 0, &gpe) || gpe > ACPI_MASKABLE_GPE_MAX)
+ if (kstrtou8(val, 0, &gpe))
return -EINVAL;
set_bit(gpe, acpi_masked_gpes_map);
--
2.7.4
On Thu, Nov 14, 2019 at 8:16 AM Yunfeng Ye <[email protected]> wrote:
>
> The commit 0f27cff8597d ("ACPI: sysfs: Make ACPI GPE mask kernel
> parameter cover all GPEs") says:
> "Use a bitmap of size 0xFF instead of a u64 for the GPE mask so 256
> GPEs can be masked"
>
> But the masking of GPE 0xFF it not supported and the check condition
> "gpe > ACPI_MASKABLE_GPE_MAX" is not valid because the type of gpe is
> u8.
>
> So modify the macro ACPI_MASKABLE_GPE_MAX to 0x100, and drop the "gpe >
> ACPI_MASKABLE_GPE_MAX" check. In addition, update the docs "Format" for
> acpi_mask_gpe parameter.
>
> Fixes: 0f27cff8597d ("ACPI: sysfs: Make ACPI GPE mask kernel parameter cover all GPEs")
> Signed-off-by: Yunfeng Ye <[email protected]>
Applying as 5.5 material, thanks!
> ---
> v1 -> v2:
> - drop the "gpe > ACPI_MASKABLE_GPE_MAX" check
> - update the docs "Format" from <int> to <byte> for acpi_mask_gpe parameter
> - update the commit comment
>
> Documentation/admin-guide/kernel-parameters.txt | 2 +-
> drivers/acpi/sysfs.c | 4 ++--
> 2 files changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt
> index a84a83f8881e..87e27186dc69 100644
> --- a/Documentation/admin-guide/kernel-parameters.txt
> +++ b/Documentation/admin-guide/kernel-parameters.txt
> @@ -113,7 +113,7 @@
> the GPE dispatcher.
> This facility can be used to prevent such uncontrolled
> GPE floodings.
> - Format: <int>
> + Format: <byte>
>
> acpi_no_auto_serialize [HW,ACPI]
> Disable auto-serialization of AML methods
> diff --git a/drivers/acpi/sysfs.c b/drivers/acpi/sysfs.c
> index 75948a3f1a20..0a83ce186bc4 100644
> --- a/drivers/acpi/sysfs.c
> +++ b/drivers/acpi/sysfs.c
> @@ -819,14 +819,14 @@ static ssize_t counter_set(struct kobject *kobj,
> * interface:
> * echo unmask > /sys/firmware/acpi/interrupts/gpe00
> */
> -#define ACPI_MASKABLE_GPE_MAX 0xFF
> +#define ACPI_MASKABLE_GPE_MAX 0x100
> static DECLARE_BITMAP(acpi_masked_gpes_map, ACPI_MASKABLE_GPE_MAX) __initdata;
>
> static int __init acpi_gpe_set_masked_gpes(char *val)
> {
> u8 gpe;
>
> - if (kstrtou8(val, 0, &gpe) || gpe > ACPI_MASKABLE_GPE_MAX)
> + if (kstrtou8(val, 0, &gpe))
> return -EINVAL;
> set_bit(gpe, acpi_masked_gpes_map);
>
> --
> 2.7.4
>
On Wed, Nov 13, 2019 at 11:17 PM Yunfeng Ye <[email protected]> wrote:
>
> The commit 0f27cff8597d ("ACPI: sysfs: Make ACPI GPE mask kernel
> parameter cover all GPEs") says:
> "Use a bitmap of size 0xFF instead of a u64 for the GPE mask so 256
> GPEs can be masked"
>
> But the masking of GPE 0xFF it not supported and the check condition
> "gpe > ACPI_MASKABLE_GPE_MAX" is not valid because the type of gpe is
> u8.
>
> So modify the macro ACPI_MASKABLE_GPE_MAX to 0x100, and drop the "gpe >
> ACPI_MASKABLE_GPE_MAX" check. In addition, update the docs "Format" for
> acpi_mask_gpe parameter.
>
> Fixes: 0f27cff8597d ("ACPI: sysfs: Make ACPI GPE mask kernel parameter cover all GPEs")
> Signed-off-by: Yunfeng Ye <[email protected]>
> ---
> v1 -> v2:
> - drop the "gpe > ACPI_MASKABLE_GPE_MAX" check
> - update the docs "Format" from <int> to <byte> for acpi_mask_gpe parameter
> - update the commit comment
>
> Documentation/admin-guide/kernel-parameters.txt | 2 +-
> drivers/acpi/sysfs.c | 4 ++--
> 2 files changed, 3 insertions(+), 3 deletions(-)
Bisect flags commit eb09878e1301 "ACPI: sysfs: Change
ACPI_MASKABLE_GPE_MAX to 0x100" in -next as the reason for a boot
regression in my qemu-kvm test environment. It spews:
[ 1.456728] ACPI: Masking GPE 0x0.
...
[ 161.721420] ACPI: Masking GPE 0x0.
...and then hangs.
A straight revert gets the configuration back on its feet.
qemu-system-x86_64 --version
QEMU emulator version 4.0.50 (v4.0.0-928-g49c6c6ac0cd8)
On Sat, Nov 16, 2019 at 9:06 PM Dan Williams <[email protected]> wrote:
>
> On Wed, Nov 13, 2019 at 11:17 PM Yunfeng Ye <[email protected]> wrote:
> >
> > The commit 0f27cff8597d ("ACPI: sysfs: Make ACPI GPE mask kernel
> > parameter cover all GPEs") says:
> > "Use a bitmap of size 0xFF instead of a u64 for the GPE mask so 256
> > GPEs can be masked"
> >
> > But the masking of GPE 0xFF it not supported and the check condition
> > "gpe > ACPI_MASKABLE_GPE_MAX" is not valid because the type of gpe is
> > u8.
> >
> > So modify the macro ACPI_MASKABLE_GPE_MAX to 0x100, and drop the "gpe >
> > ACPI_MASKABLE_GPE_MAX" check. In addition, update the docs "Format" for
> > acpi_mask_gpe parameter.
> >
> > Fixes: 0f27cff8597d ("ACPI: sysfs: Make ACPI GPE mask kernel parameter cover all GPEs")
> > Signed-off-by: Yunfeng Ye <[email protected]>
> > ---
> > v1 -> v2:
> > - drop the "gpe > ACPI_MASKABLE_GPE_MAX" check
> > - update the docs "Format" from <int> to <byte> for acpi_mask_gpe parameter
> > - update the commit comment
> >
> > Documentation/admin-guide/kernel-parameters.txt | 2 +-
> > drivers/acpi/sysfs.c | 4 ++--
> > 2 files changed, 3 insertions(+), 3 deletions(-)
>
> Bisect flags commit eb09878e1301 "ACPI: sysfs: Change
> ACPI_MASKABLE_GPE_MAX to 0x100" in -next as the reason for a boot
> regression in my qemu-kvm test environment. It spews:
>
> [ 1.456728] ACPI: Masking GPE 0x0.
> ...
> [ 161.721420] ACPI: Masking GPE 0x0.
>
> ...and then hangs.
>
> A straight revert gets the configuration back on its feet.
>
> qemu-system-x86_64 --version
> QEMU emulator version 4.0.50 (v4.0.0-928-g49c6c6ac0cd8)
OK, I'll drop it then, thanks!
On Mon, Nov 18, 2019 at 1:04 AM Rafael J. Wysocki <[email protected]> wrote:
>
> On Sat, Nov 16, 2019 at 9:06 PM Dan Williams <[email protected]> wrote:
> >
> > On Wed, Nov 13, 2019 at 11:17 PM Yunfeng Ye <[email protected]> wrote:
> > >
> > > The commit 0f27cff8597d ("ACPI: sysfs: Make ACPI GPE mask kernel
> > > parameter cover all GPEs") says:
> > > "Use a bitmap of size 0xFF instead of a u64 for the GPE mask so 256
> > > GPEs can be masked"
> > >
> > > But the masking of GPE 0xFF it not supported and the check condition
> > > "gpe > ACPI_MASKABLE_GPE_MAX" is not valid because the type of gpe is
> > > u8.
> > >
> > > So modify the macro ACPI_MASKABLE_GPE_MAX to 0x100, and drop the "gpe >
> > > ACPI_MASKABLE_GPE_MAX" check. In addition, update the docs "Format" for
> > > acpi_mask_gpe parameter.
> > >
> > > Fixes: 0f27cff8597d ("ACPI: sysfs: Make ACPI GPE mask kernel parameter cover all GPEs")
> > > Signed-off-by: Yunfeng Ye <[email protected]>
> > > ---
> > > v1 -> v2:
> > > - drop the "gpe > ACPI_MASKABLE_GPE_MAX" check
> > > - update the docs "Format" from <int> to <byte> for acpi_mask_gpe parameter
> > > - update the commit comment
> > >
> > > Documentation/admin-guide/kernel-parameters.txt | 2 +-
> > > drivers/acpi/sysfs.c | 4 ++--
> > > 2 files changed, 3 insertions(+), 3 deletions(-)
> >
> > Bisect flags commit eb09878e1301 "ACPI: sysfs: Change
> > ACPI_MASKABLE_GPE_MAX to 0x100" in -next as the reason for a boot
> > regression in my qemu-kvm test environment. It spews:
> >
> > [ 1.456728] ACPI: Masking GPE 0x0.
> > ...
> > [ 161.721420] ACPI: Masking GPE 0x0.
> >
> > ...and then hangs.
> >
> > A straight revert gets the configuration back on its feet.
> >
> > qemu-system-x86_64 --version
> > QEMU emulator version 4.0.50 (v4.0.0-928-g49c6c6ac0cd8)
>
> OK, I'll drop it then, thanks!
We're seeing the same issue wtih 5.4.0-rc7-next-20191118 on a Linux VM
running on Hyper-V :
[ 0.133029] ACPI: 1 ACPI AML tables successfully acquired and loaded
[ 0.144023] ACPI: Interpreter enabled
[ 0.145023] ACPI: (supports S0 S5)
[ 0.146023] ACPI: Using IOAPIC for interrupt routing
[ 0.147024] PCI: Using host bridge windows from ACPI; if necessary,
use "pci=nocrs" and report a bug
[ 0.148031] ACPI: Masking GPE 0x0.
...
[ 774.839023] ACPI: Masking GPE 0x0.
[ 774.840023] ACPI: Masking GPE 0x0.
I guess the patch is only tested on a physical machine and not on a VM...
Thanks,
Dexuan
On Mon, Nov 18, 2019 at 8:44 PM Dexuan-Linux Cui <[email protected]> wrote:
>
> On Mon, Nov 18, 2019 at 1:04 AM Rafael J. Wysocki <[email protected]> wrote:
> >
> > On Sat, Nov 16, 2019 at 9:06 PM Dan Williams <[email protected]> wrote:
> > >
> > > On Wed, Nov 13, 2019 at 11:17 PM Yunfeng Ye <[email protected]> wrote:
> > > >
> > > > The commit 0f27cff8597d ("ACPI: sysfs: Make ACPI GPE mask kernel
> > > > parameter cover all GPEs") says:
> > > > "Use a bitmap of size 0xFF instead of a u64 for the GPE mask so 256
> > > > GPEs can be masked"
> > > >
> > > > But the masking of GPE 0xFF it not supported and the check condition
> > > > "gpe > ACPI_MASKABLE_GPE_MAX" is not valid because the type of gpe is
> > > > u8.
> > > >
> > > > So modify the macro ACPI_MASKABLE_GPE_MAX to 0x100, and drop the "gpe >
> > > > ACPI_MASKABLE_GPE_MAX" check. In addition, update the docs "Format" for
> > > > acpi_mask_gpe parameter.
> > > >
> > > > Fixes: 0f27cff8597d ("ACPI: sysfs: Make ACPI GPE mask kernel parameter cover all GPEs")
> > > > Signed-off-by: Yunfeng Ye <[email protected]>
> > > > ---
> > > > v1 -> v2:
> > > > - drop the "gpe > ACPI_MASKABLE_GPE_MAX" check
> > > > - update the docs "Format" from <int> to <byte> for acpi_mask_gpe parameter
> > > > - update the commit comment
> > > >
> > > > Documentation/admin-guide/kernel-parameters.txt | 2 +-
> > > > drivers/acpi/sysfs.c | 4 ++--
> > > > 2 files changed, 3 insertions(+), 3 deletions(-)
> > >
> > > Bisect flags commit eb09878e1301 "ACPI: sysfs: Change
> > > ACPI_MASKABLE_GPE_MAX to 0x100" in -next as the reason for a boot
> > > regression in my qemu-kvm test environment. It spews:
> > >
> > > [ 1.456728] ACPI: Masking GPE 0x0.
> > > ...
> > > [ 161.721420] ACPI: Masking GPE 0x0.
> > >
> > > ...and then hangs.
> > >
> > > A straight revert gets the configuration back on its feet.
> > >
> > > qemu-system-x86_64 --version
> > > QEMU emulator version 4.0.50 (v4.0.0-928-g49c6c6ac0cd8)
> >
> > OK, I'll drop it then, thanks!
>
> We're seeing the same issue wtih 5.4.0-rc7-next-20191118 on a Linux VM
> running on Hyper-V :
>
> [ 0.133029] ACPI: 1 ACPI AML tables successfully acquired and loaded
> [ 0.144023] ACPI: Interpreter enabled
> [ 0.145023] ACPI: (supports S0 S5)
> [ 0.146023] ACPI: Using IOAPIC for interrupt routing
> [ 0.147024] PCI: Using host bridge windows from ACPI; if necessary,
> use "pci=nocrs" and report a bug
> [ 0.148031] ACPI: Masking GPE 0x0.
> ...
> [ 774.839023] ACPI: Masking GPE 0x0.
> [ 774.840023] ACPI: Masking GPE 0x0.
>
> I guess the patch is only tested on a physical machine and not on a VM...
It looks like the patch hasn't been tested at all.
Please try to change the data type of gpe in
acpi_gpe_apply_masked_gpes() to u16 and see if that helps.
On 2019/11/19 5:15, Rafael J. Wysocki wrote:
> On Mon, Nov 18, 2019 at 8:44 PM Dexuan-Linux Cui <[email protected]> wrote:
>>
>> On Mon, Nov 18, 2019 at 1:04 AM Rafael J. Wysocki <[email protected]> wrote:
>>>
>>> On Sat, Nov 16, 2019 at 9:06 PM Dan Williams <[email protected]> wrote:
>>>>
>>>> On Wed, Nov 13, 2019 at 11:17 PM Yunfeng Ye <[email protected]> wrote:
>>>>>
>>>>> The commit 0f27cff8597d ("ACPI: sysfs: Make ACPI GPE mask kernel
>>>>> parameter cover all GPEs") says:
>>>>> "Use a bitmap of size 0xFF instead of a u64 for the GPE mask so 256
>>>>> GPEs can be masked"
>>>>>
>>>>> But the masking of GPE 0xFF it not supported and the check condition
>>>>> "gpe > ACPI_MASKABLE_GPE_MAX" is not valid because the type of gpe is
>>>>> u8.
>>>>>
>>>>> So modify the macro ACPI_MASKABLE_GPE_MAX to 0x100, and drop the "gpe >
>>>>> ACPI_MASKABLE_GPE_MAX" check. In addition, update the docs "Format" for
>>>>> acpi_mask_gpe parameter.
>>>>>
>>>>> Fixes: 0f27cff8597d ("ACPI: sysfs: Make ACPI GPE mask kernel parameter cover all GPEs")
>>>>> Signed-off-by: Yunfeng Ye <[email protected]>
>>>>> ---
>>>>> v1 -> v2:
>>>>> - drop the "gpe > ACPI_MASKABLE_GPE_MAX" check
>>>>> - update the docs "Format" from <int> to <byte> for acpi_mask_gpe parameter
>>>>> - update the commit comment
>>>>>
>>>>> Documentation/admin-guide/kernel-parameters.txt | 2 +-
>>>>> drivers/acpi/sysfs.c | 4 ++--
>>>>> 2 files changed, 3 insertions(+), 3 deletions(-)
>>>>
>>>> Bisect flags commit eb09878e1301 "ACPI: sysfs: Change
>>>> ACPI_MASKABLE_GPE_MAX to 0x100" in -next as the reason for a boot
>>>> regression in my qemu-kvm test environment. It spews:
>>>>
>>>> [ 1.456728] ACPI: Masking GPE 0x0.
>>>> ...
>>>> [ 161.721420] ACPI: Masking GPE 0x0.
>>>>
>>>> ...and then hangs.
>>>>
>>>> A straight revert gets the configuration back on its feet.
>>>>
>>>> qemu-system-x86_64 --version
>>>> QEMU emulator version 4.0.50 (v4.0.0-928-g49c6c6ac0cd8)
>>>
>>> OK, I'll drop it then, thanks!
>>
>> We're seeing the same issue wtih 5.4.0-rc7-next-20191118 on a Linux VM
>> running on Hyper-V :
>>
>> [ 0.133029] ACPI: 1 ACPI AML tables successfully acquired and loaded
>> [ 0.144023] ACPI: Interpreter enabled
>> [ 0.145023] ACPI: (supports S0 S5)
>> [ 0.146023] ACPI: Using IOAPIC for interrupt routing
>> [ 0.147024] PCI: Using host bridge windows from ACPI; if necessary,
>> use "pci=nocrs" and report a bug
>> [ 0.148031] ACPI: Masking GPE 0x0.
>> ...
>> [ 774.839023] ACPI: Masking GPE 0x0.
>> [ 774.840023] ACPI: Masking GPE 0x0.
>>
>> I guess the patch is only tested on a physical machine and not on a VM...
>
> It looks like the patch hasn't been tested at all.
>
> Please try to change the data type of gpe in
> acpi_gpe_apply_masked_gpes() to u16 and see if that helps.
>
Sorry for this problem, I have no good test after modification according to
inspection opinions.
The first version patch is ok, the type of gpe is changed to u32. and I have
test it before.
thanks.
> .
>
On Tue, Nov 19, 2019 at 3:22 AM Yunfeng Ye <[email protected]> wrote:
>
>
>
> On 2019/11/19 5:15, Rafael J. Wysocki wrote:
> > On Mon, Nov 18, 2019 at 8:44 PM Dexuan-Linux Cui <[email protected]> wrote:
> >>
> >> On Mon, Nov 18, 2019 at 1:04 AM Rafael J. Wysocki <[email protected]> wrote:
> >>>
> >>> On Sat, Nov 16, 2019 at 9:06 PM Dan Williams <[email protected]> wrote:
> >>>>
> >>>> On Wed, Nov 13, 2019 at 11:17 PM Yunfeng Ye <[email protected]> wrote:
> >>>>>
> >>>>> The commit 0f27cff8597d ("ACPI: sysfs: Make ACPI GPE mask kernel
> >>>>> parameter cover all GPEs") says:
> >>>>> "Use a bitmap of size 0xFF instead of a u64 for the GPE mask so 256
> >>>>> GPEs can be masked"
> >>>>>
> >>>>> But the masking of GPE 0xFF it not supported and the check condition
> >>>>> "gpe > ACPI_MASKABLE_GPE_MAX" is not valid because the type of gpe is
> >>>>> u8.
> >>>>>
> >>>>> So modify the macro ACPI_MASKABLE_GPE_MAX to 0x100, and drop the "gpe >
> >>>>> ACPI_MASKABLE_GPE_MAX" check. In addition, update the docs "Format" for
> >>>>> acpi_mask_gpe parameter.
> >>>>>
> >>>>> Fixes: 0f27cff8597d ("ACPI: sysfs: Make ACPI GPE mask kernel parameter cover all GPEs")
> >>>>> Signed-off-by: Yunfeng Ye <[email protected]>
> >>>>> ---
> >>>>> v1 -> v2:
> >>>>> - drop the "gpe > ACPI_MASKABLE_GPE_MAX" check
> >>>>> - update the docs "Format" from <int> to <byte> for acpi_mask_gpe parameter
> >>>>> - update the commit comment
> >>>>>
> >>>>> Documentation/admin-guide/kernel-parameters.txt | 2 +-
> >>>>> drivers/acpi/sysfs.c | 4 ++--
> >>>>> 2 files changed, 3 insertions(+), 3 deletions(-)
> >>>>
> >>>> Bisect flags commit eb09878e1301 "ACPI: sysfs: Change
> >>>> ACPI_MASKABLE_GPE_MAX to 0x100" in -next as the reason for a boot
> >>>> regression in my qemu-kvm test environment. It spews:
> >>>>
> >>>> [ 1.456728] ACPI: Masking GPE 0x0.
> >>>> ...
> >>>> [ 161.721420] ACPI: Masking GPE 0x0.
> >>>>
> >>>> ...and then hangs.
> >>>>
> >>>> A straight revert gets the configuration back on its feet.
> >>>>
> >>>> qemu-system-x86_64 --version
> >>>> QEMU emulator version 4.0.50 (v4.0.0-928-g49c6c6ac0cd8)
> >>>
> >>> OK, I'll drop it then, thanks!
> >>
> >> We're seeing the same issue wtih 5.4.0-rc7-next-20191118 on a Linux VM
> >> running on Hyper-V :
> >>
> >> [ 0.133029] ACPI: 1 ACPI AML tables successfully acquired and loaded
> >> [ 0.144023] ACPI: Interpreter enabled
> >> [ 0.145023] ACPI: (supports S0 S5)
> >> [ 0.146023] ACPI: Using IOAPIC for interrupt routing
> >> [ 0.147024] PCI: Using host bridge windows from ACPI; if necessary,
> >> use "pci=nocrs" and report a bug
> >> [ 0.148031] ACPI: Masking GPE 0x0.
> >> ...
> >> [ 774.839023] ACPI: Masking GPE 0x0.
> >> [ 774.840023] ACPI: Masking GPE 0x0.
> >>
> >> I guess the patch is only tested on a physical machine and not on a VM...
> >
> > It looks like the patch hasn't been tested at all.
> >
> > Please try to change the data type of gpe in
> > acpi_gpe_apply_masked_gpes() to u16 and see if that helps.
> >
> Sorry for this problem, I have no good test after modification according to
> inspection opinions.
I see.
Well, reviewers make mistakes too ...
> The first version patch is ok, the type of gpe is changed to u32. and I have
> test it before.
OK
So I have added the u8 -> u16 change for gpe in
acpi_gpe_apply_masked_gpes() and applied it again, as that should work
AFAICS.