Re: [PATCH 4/8] i2c: acpi: Use ACPI GPIO wake capability bit to set wake_irq

It looks like `i2c_acpi_get_irq` and `platform_get_irq_optional` are
doing pretty much the same thing. Can we replace `i2c_acpi_get_irq`
and switch over to `platform_get_irq_optional`? Is it possible to get
a `platform_device` from an `i2c_client`?

On Thu, Sep 8, 2022 at 9:23 AM Rafael J. Wysocki [off-list ref] wrote:

On Thu, Sep 8, 2022 at 4:40 PM Raul Rangel [off-list ref] wrote:

quoted

On Wed, Sep 7, 2022 at 2:12 AM Hans de Goede [off-list ref] wrote:

quoted

Hi,

On 9/7/22 04:00, Raul Rangel wrote:

quoted

On Tue, Sep 6, 2022 at 7:00 PM Dmitry Torokhov
[off-list ref] wrote:

quoted

On Tue, Aug 30, 2022 at 05:15:37PM -0600, Raul E Rangel wrote:

quoted

Device tree already has a mechanism to pass the wake_irq. It does this
by looking for the wakeup-source property and setting the
I2C_CLIENT_WAKE flag. This CL adds the ACPI equivalent. It uses at the
ACPI GpioInt wake flag to determine if the interrupt can be used to wake
the system. Previously the i2c drivers had to make assumptions and
blindly enable the wake IRQ. This can cause spurious wake events. e.g.,
If there is a device with an Active Low interrupt and the device gets
powered off while suspending, the interrupt line will go low since it's
no longer powered and wake the system. For this reason we should respect
the board designers wishes and honor the wake bit defined on the
GpioInt.

This change does not cover the ACPI Interrupt or IRQ resources.

Signed-off-by: Raul E Rangel <redacted>
---

 drivers/i2c/i2c-core-acpi.c |  8 ++++++--
 drivers/i2c/i2c-core-base.c | 17 +++++++++++------
 drivers/i2c/i2c-core.h      |  4 ++--
 3 files changed, 19 insertions(+), 10 deletions(-)

diff --git a/drivers/i2c/i2c-core-acpi.c b/drivers/i2c/i2c-core-acpi.c
index c762a879c4cc6b..cfe82a6ba3ef28 100644
--- a/drivers/i2c/i2c-core-acpi.c
+++ b/drivers/i2c/i2c-core-acpi.c

@@ -182,12 +182,13 @@ static int i2c_acpi_add_resource(struct acpi_resource *ares, void *data)
 /**
  * i2c_acpi_get_irq - get device IRQ number from ACPI
  * @client: Pointer to the I2C client device
+ * @wake_capable: Set to 1 if the IRQ is wake capable
  *
  * Find the IRQ number used by a specific client device.
  *
  * Return: The IRQ number or an error code.
  */
-int i2c_acpi_get_irq(struct i2c_client *client)
+int i2c_acpi_get_irq(struct i2c_client *client, int *wake_capable)
 {
      struct acpi_device *adev = ACPI_COMPANION(&client->dev);
      struct list_head resource_list;

@@ -196,6 +197,9 @@ int i2c_acpi_get_irq(struct i2c_client *client)

      INIT_LIST_HEAD(&resource_list);

+     if (wake_capable)
+             *wake_capable = 0;
+
      ret = acpi_dev_get_resources(adev, &resource_list,
                                   i2c_acpi_add_resource, &irq);

quoted

You also need to handle "Interrupt(..., ...AndWake)" case here. I would
look into maybe defining

#define IORESOURCE_IRQ_WAKECAPABLE      (1<<6)

in include/linux/ioport.h and plumbing it through from ACPI layer.

Thanks.

AFAIK the Intel (Not 100% certain) and AMD IO-APIC's can't actually
wake a system from suspend/suspend-to-idle.

That may be true for S3 suspend (it sounds about right) there
certainly is no way to "arm for wakeup" on the APIC, but with
s2idle all IRQs which are not explicitly disabled by the OS
still function normally so there any IRQ can be a wakeup
source (AFAIK).

That's true.

Moreover, even for S3 there are transitions into it and there may be
wakeup interrupts taking place during those transitions.  Those may be
any IRQs too.

quoted

quoted

And even with S3 suspend I think some IRQs can act as wakeup,
but that is configured by the BIOS then and not something which
linux can enable/disable. E.g IIRC the parent IRQ of the GPIO
controllers on x86 is an APIC IRQ ...

It's more about how the system is wired up AFAICS.  Basically, in
order to wake up the system from S3, the given IRQ needs to be
physically attached to an input that will trigger the platform wakeup
logic while in S3.

quoted

quoted

SGTM. I wanted to make sure there was interest before I invested the
time in adding the functionality. Hopefully I can push up a new patch
set tomorrow.

Sounds good. :-)