Today, i2c drivers are making the assumption that their IRQs can also
be used as wake IRQs. This isn't always the case and it can lead to
spurious wakes. This has recently started to affect AMD Chromebooks.
With the introduction of
d62bd5ce12d7 ("pinctrl: amd: Implement irq_set_wake"), the AMD GPIO
controller gained the capability to set the wake bit on each GPIO. The
ACPI specification defines two ways to inform the system if a device is
wake capable:
1) The _PRW object defines the GPE that can be used to wake the system.
2) Setting ExclusiveAndWake or SharedAndWake in the _CRS GpioInt.
Currently only the first method is supported. The i2c drivers don't have
any indication that the IRQ is wake capable, so they guess. This causes
spurious interrupts, for example:
* We have an ACPI HID device that has `_PR0` and `_PR3`. It doesn't have
`_PRW` or `ExclusiveAndWake` so that means the device can't wake the
system.
* The IRQ line is active level low for this device and is pulled up by
the power resource defined in `_PR0`/`_PR3`.
* The i2c driver will (incorrectly) arm the GPIO for wake by calling
`enable_irq_wake` as part of its suspend hook.
* ACPI will power down the device since it doesn't have a wake GPE
associated with it.
* When the device is powered down, the IRQ line will drop, and it will
trigger a wake event.
See the following debug log:
[ 42.335804] PM: Suspending system (s2idle)
[ 42.340186] amd_gpio AMD0030:00: RX: Setting wake for pin 89 to enable
[ 42.467736] power-0416 __acpi_power_off : Power resource [PR00] turned off
[ 42.467739] device_pm-0280 device_set_power : Device [H05D] transitioned to D3cold
[ 42.475210] PM: pm_system_irq_wakeup: 11 triggered pinctrl_amd
[ 42.535293] PM: Wakeup unrelated to ACPI SCI
[ 42.535294] PM: resume from suspend-to-idle
In order to fix this, we need to take into account the wake capable bit
defined on the GpioInt. This is accomplished by:
* Migrating some of the i2c drivers over to using the PM subsystem to
manage the wake IRQ. max8925-i2c, elants_i2c, and raydium_i2c_ts still
need to be migrated, I can do that depending on the feedback to this
patch series.
* Expose the wake_capable bit from the ACPI GpioInt resource to the
i2c core.
* Use the wake_capable bit in the i2c core to call
`dev_pm_set_wake_irq`. This reuses the existing device tree flow.
* Make the i2c drivers stop calling `dev_pm_set_wake_irq` since it's now
handled by the i2c core.
* Make the ACPI device PM system aware of the wake_irq. This is
necessary so the device doesn't incorrectly get powered down when a
wake_irq is enabled.
I've tested this code with various combinations of having _PRW,
ExclusiveAndWake and power resources all defined or not defined, but it
would be great if others could test this out on their hardware.
Thanks,
Raul
Raul E Rangel (8):
Input: elan_i2c - Use PM subsystem to manage wake irq
HID: i2c-hid: Use PM subsystem to manage wake irq
gpiolib: acpi: Add wake_capable parameter to acpi_dev_gpio_irq_get_by
i2c: acpi: Use ACPI GPIO wake capability bit to set wake_irq
HID: i2c-hid: acpi: Stop setting wakeup_capable
Input: elan_i2c - Don't set wake_irq when using ACPI
HID: i2c-hid: Don't set wake_irq when using ACPI
ACPI: PM: Take wake IRQ into consideration when entering
suspend-to-idle
drivers/acpi/device_pm.c | 19 +++++++++++++++--
drivers/gpio/gpio-pca953x.c | 3 ++-
drivers/gpio/gpiolib-acpi.c | 11 +++++++++-
drivers/gpio/gpiolib-acpi.h | 2 ++
drivers/hid/i2c-hid/i2c-hid-acpi.c | 5 -----
drivers/hid/i2c-hid/i2c-hid-core.c | 33 +++++++++++------------------
drivers/i2c/i2c-core-acpi.c | 8 +++++--
drivers/i2c/i2c-core-base.c | 17 +++++++++------
drivers/i2c/i2c-core.h | 4 ++--
drivers/input/mouse/elan_i2c_core.c | 14 +++++-------
include/linux/acpi.h | 14 +++++++++---
11 files changed, 78 insertions(+), 52 deletions(-)
--
2.37.2.672.g94769d06f0-goog
This change adds support for ACPI devices that use ExclusiveAndWake or
SharedAndWake in their _CRS GpioInt definition (instead of using _PRW),
and also provide power resources. Previously the ACPI subsystem had no
idea if the device had a wake capable interrupt armed. This resulted
in the ACPI device PM system placing the device into D3Cold, and thus
cutting power to the device. With this change we will now query the
_S0W method to figure out the appropriate wake capable D-state.
Signed-off-by: Raul E Rangel <[email protected]>
---
drivers/acpi/device_pm.c | 19 +++++++++++++++++--
1 file changed, 17 insertions(+), 2 deletions(-)
diff --git a/drivers/acpi/device_pm.c b/drivers/acpi/device_pm.c
index 9dce1245689ca2..6bc81f525d5160 100644
--- a/drivers/acpi/device_pm.c
+++ b/drivers/acpi/device_pm.c
@@ -681,8 +681,23 @@ static int acpi_dev_pm_get_state(struct device *dev, struct acpi_device *adev,
d_min = ret;
wakeup = device_may_wakeup(dev) && adev->wakeup.flags.valid
&& adev->wakeup.sleep_state >= target_state;
- } else {
- wakeup = adev->wakeup.flags.valid;
+ } else if (acpi_device_can_wakeup(adev)) {
+ /* ACPI GPE from specified by _PRW. */
+ wakeup = true;
+ } else if (device_may_wakeup(dev) && dev->power.wakeirq) {
+ /*
+ * The ACPI subsystem doesn't manage the wake bit for IRQs
+ * defined with ExclusiveAndWake and SharedAndWake. Instead we
+ * expect them to be managed via the PM subsystem. Drivers
+ * should call dev_pm_set_wake_irq to register an IRQ as a wake
+ * source.
+ *
+ * If a device has a wake IRQ attached we need to check the
+ * _S0W method to get the correct wake D-state. Otherwise we
+ * end up putting the device into D3Cold which will more than
+ * likely disable wake functionality.
+ */
+ wakeup = true;
}
/*
--
2.37.2.672.g94769d06f0-goog
On Tue, Aug 30, 2022 at 05:15:33PM -0600, Raul E Rangel wrote:
> Today, i2c drivers are making the assumption that their IRQs can also
> be used as wake IRQs. This isn't always the case and it can lead to
> spurious wakes. This has recently started to affect AMD Chromebooks.
> With the introduction of
> d62bd5ce12d7 ("pinctrl: amd: Implement irq_set_wake"), the AMD GPIO
> controller gained the capability to set the wake bit on each GPIO. The
> ACPI specification defines two ways to inform the system if a device is
> wake capable:
> 1) The _PRW object defines the GPE that can be used to wake the system.
> 2) Setting ExclusiveAndWake or SharedAndWake in the _CRS GpioInt.
>
> Currently only the first method is supported. The i2c drivers don't have
> any indication that the IRQ is wake capable, so they guess. This causes
> spurious interrupts, for example:
> * We have an ACPI HID device that has `_PR0` and `_PR3`. It doesn't have
> `_PRW` or `ExclusiveAndWake` so that means the device can't wake the
> system.
> * The IRQ line is active level low for this device and is pulled up by
> the power resource defined in `_PR0`/`_PR3`.
> * The i2c driver will (incorrectly) arm the GPIO for wake by calling
> `enable_irq_wake` as part of its suspend hook.
> * ACPI will power down the device since it doesn't have a wake GPE
> associated with it.
> * When the device is powered down, the IRQ line will drop, and it will
> trigger a wake event.
>
> See the following debug log:
> [ 42.335804] PM: Suspending system (s2idle)
> [ 42.340186] amd_gpio AMD0030:00: RX: Setting wake for pin 89 to enable
> [ 42.467736] power-0416 __acpi_power_off : Power resource [PR00] turned off
> [ 42.467739] device_pm-0280 device_set_power : Device [H05D] transitioned to D3cold
> [ 42.475210] PM: pm_system_irq_wakeup: 11 triggered pinctrl_amd
> [ 42.535293] PM: Wakeup unrelated to ACPI SCI
> [ 42.535294] PM: resume from suspend-to-idle
>
> In order to fix this, we need to take into account the wake capable bit
> defined on the GpioInt. This is accomplished by:
> * Migrating some of the i2c drivers over to using the PM subsystem to
> manage the wake IRQ. max8925-i2c, elants_i2c, and raydium_i2c_ts still
> need to be migrated, I can do that depending on the feedback to this
> patch series.
> * Expose the wake_capable bit from the ACPI GpioInt resource to the
> i2c core.
> * Use the wake_capable bit in the i2c core to call
> `dev_pm_set_wake_irq`. This reuses the existing device tree flow.
> * Make the i2c drivers stop calling `dev_pm_set_wake_irq` since it's now
> handled by the i2c core.
> * Make the ACPI device PM system aware of the wake_irq. This is
> necessary so the device doesn't incorrectly get powered down when a
> wake_irq is enabled.
>
> I've tested this code with various combinations of having _PRW,
> ExclusiveAndWake and power resources all defined or not defined, but it
> would be great if others could test this out on their hardware.
I have got only cover letter and a single patch (#3). What's going on?
Note: I'm also reviewer of I?C DesignWare driver, you really have to
fix your tools / submission process and try again. No review for this
series.
--
With Best Regards,
Andy Shevchenko
Interesting... The patch series is here:
https://patchwork.kernel.org/project/linux-input/cover/[email protected]/
I'll look into why you only got added to 2 of the emails.
On Wed, Aug 31, 2022 at 5:52 AM Andy Shevchenko
<[email protected]> wrote:
>
> On Tue, Aug 30, 2022 at 05:15:33PM -0600, Raul E Rangel wrote:
> > Today, i2c drivers are making the assumption that their IRQs can also
> > be used as wake IRQs. This isn't always the case and it can lead to
> > spurious wakes. This has recently started to affect AMD Chromebooks.
> > With the introduction of
> > d62bd5ce12d7 ("pinctrl: amd: Implement irq_set_wake"), the AMD GPIO
> > controller gained the capability to set the wake bit on each GPIO. The
> > ACPI specification defines two ways to inform the system if a device is
> > wake capable:
> > 1) The _PRW object defines the GPE that can be used to wake the system.
> > 2) Setting ExclusiveAndWake or SharedAndWake in the _CRS GpioInt.
> >
> > Currently only the first method is supported. The i2c drivers don't have
> > any indication that the IRQ is wake capable, so they guess. This causes
> > spurious interrupts, for example:
> > * We have an ACPI HID device that has `_PR0` and `_PR3`. It doesn't have
> > `_PRW` or `ExclusiveAndWake` so that means the device can't wake the
> > system.
> > * The IRQ line is active level low for this device and is pulled up by
> > the power resource defined in `_PR0`/`_PR3`.
> > * The i2c driver will (incorrectly) arm the GPIO for wake by calling
> > `enable_irq_wake` as part of its suspend hook.
> > * ACPI will power down the device since it doesn't have a wake GPE
> > associated with it.
> > * When the device is powered down, the IRQ line will drop, and it will
> > trigger a wake event.
> >
> > See the following debug log:
> > [ 42.335804] PM: Suspending system (s2idle)
> > [ 42.340186] amd_gpio AMD0030:00: RX: Setting wake for pin 89 to enable
> > [ 42.467736] power-0416 __acpi_power_off : Power resource [PR00] turned off
> > [ 42.467739] device_pm-0280 device_set_power : Device [H05D] transitioned to D3cold
> > [ 42.475210] PM: pm_system_irq_wakeup: 11 triggered pinctrl_amd
> > [ 42.535293] PM: Wakeup unrelated to ACPI SCI
> > [ 42.535294] PM: resume from suspend-to-idle
> >
> > In order to fix this, we need to take into account the wake capable bit
> > defined on the GpioInt. This is accomplished by:
> > * Migrating some of the i2c drivers over to using the PM subsystem to
> > manage the wake IRQ. max8925-i2c, elants_i2c, and raydium_i2c_ts still
> > need to be migrated, I can do that depending on the feedback to this
> > patch series.
> > * Expose the wake_capable bit from the ACPI GpioInt resource to the
> > i2c core.
> > * Use the wake_capable bit in the i2c core to call
> > `dev_pm_set_wake_irq`. This reuses the existing device tree flow.
> > * Make the i2c drivers stop calling `dev_pm_set_wake_irq` since it's now
> > handled by the i2c core.
> > * Make the ACPI device PM system aware of the wake_irq. This is
> > necessary so the device doesn't incorrectly get powered down when a
> > wake_irq is enabled.
> >
> > I've tested this code with various combinations of having _PRW,
> > ExclusiveAndWake and power resources all defined or not defined, but it
> > would be great if others could test this out on their hardware.
>
> I have got only cover letter and a single patch (#3). What's going on?
>
> Note: I'm also reviewer of I涎 DesignWare driver, you really have to
> fix your tools / submission process and try again. No review for this
> series.
>
> --
> With Best Regards,
> Andy Shevchenko
>
>
Hi,
On 8/31/22 16:37, Raul Rangel wrote:
> Interesting... The patch series is here:
> https://patchwork.kernel.org/project/linux-input/cover/[email protected]/
>
> I'll look into why you only got added to 2 of the emails.
FWIW I also received the full series without problems.
I'll try to reply to this soon-ish, but I have a bit of
a patch backlog to process and I'm trying to process
the backlog in FIFO order and this is one of the last
series in the backlog ...
Regards,
Hans
>
> On Wed, Aug 31, 2022 at 5:52 AM Andy Shevchenko
> <[email protected]> wrote:
>>
>> On Tue, Aug 30, 2022 at 05:15:33PM -0600, Raul E Rangel wrote:
>>> Today, i2c drivers are making the assumption that their IRQs can also
>>> be used as wake IRQs. This isn't always the case and it can lead to
>>> spurious wakes. This has recently started to affect AMD Chromebooks.
>>> With the introduction of
>>> d62bd5ce12d7 ("pinctrl: amd: Implement irq_set_wake"), the AMD GPIO
>>> controller gained the capability to set the wake bit on each GPIO. The
>>> ACPI specification defines two ways to inform the system if a device is
>>> wake capable:
>>> 1) The _PRW object defines the GPE that can be used to wake the system.
>>> 2) Setting ExclusiveAndWake or SharedAndWake in the _CRS GpioInt.
>>>
>>> Currently only the first method is supported. The i2c drivers don't have
>>> any indication that the IRQ is wake capable, so they guess. This causes
>>> spurious interrupts, for example:
>>> * We have an ACPI HID device that has `_PR0` and `_PR3`. It doesn't have
>>> `_PRW` or `ExclusiveAndWake` so that means the device can't wake the
>>> system.
>>> * The IRQ line is active level low for this device and is pulled up by
>>> the power resource defined in `_PR0`/`_PR3`.
>>> * The i2c driver will (incorrectly) arm the GPIO for wake by calling
>>> `enable_irq_wake` as part of its suspend hook.
>>> * ACPI will power down the device since it doesn't have a wake GPE
>>> associated with it.
>>> * When the device is powered down, the IRQ line will drop, and it will
>>> trigger a wake event.
>>>
>>> See the following debug log:
>>> [ 42.335804] PM: Suspending system (s2idle)
>>> [ 42.340186] amd_gpio AMD0030:00: RX: Setting wake for pin 89 to enable
>>> [ 42.467736] power-0416 __acpi_power_off : Power resource [PR00] turned off
>>> [ 42.467739] device_pm-0280 device_set_power : Device [H05D] transitioned to D3cold
>>> [ 42.475210] PM: pm_system_irq_wakeup: 11 triggered pinctrl_amd
>>> [ 42.535293] PM: Wakeup unrelated to ACPI SCI
>>> [ 42.535294] PM: resume from suspend-to-idle
>>>
>>> In order to fix this, we need to take into account the wake capable bit
>>> defined on the GpioInt. This is accomplished by:
>>> * Migrating some of the i2c drivers over to using the PM subsystem to
>>> manage the wake IRQ. max8925-i2c, elants_i2c, and raydium_i2c_ts still
>>> need to be migrated, I can do that depending on the feedback to this
>>> patch series.
>>> * Expose the wake_capable bit from the ACPI GpioInt resource to the
>>> i2c core.
>>> * Use the wake_capable bit in the i2c core to call
>>> `dev_pm_set_wake_irq`. This reuses the existing device tree flow.
>>> * Make the i2c drivers stop calling `dev_pm_set_wake_irq` since it's now
>>> handled by the i2c core.
>>> * Make the ACPI device PM system aware of the wake_irq. This is
>>> necessary so the device doesn't incorrectly get powered down when a
>>> wake_irq is enabled.
>>>
>>> I've tested this code with various combinations of having _PRW,
>>> ExclusiveAndWake and power resources all defined or not defined, but it
>>> would be great if others could test this out on their hardware.
>>
>> I have got only cover letter and a single patch (#3). What's going on?
>>
>> Note: I'm also reviewer of I涎 DesignWare driver, you really have to
>> fix your tools / submission process and try again. No review for this
>> series.
>>
>> --
>> With Best Regards,
>> Andy Shevchenko
>>
>>
>