2022-09-12 22:16:37

by Raul Rangel

[permalink] [raw]
Subject: [PATCH v2 07/13] i2c: acpi: Use ACPI wake capability bit to set wake_irq

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 the
ACPI interrupt 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 wakes the system. For this reason we should
respect the board designers wishes and honor the wake bit defined on the
interrupt.

Signed-off-by: Raul E Rangel <[email protected]>
---

Changes in v2:
- Look at wake_cabple bit for IRQ/Interrupt resources

drivers/i2c/i2c-core-acpi.c | 37 ++++++++++++++++++++++++++++---------
drivers/i2c/i2c-core-base.c | 6 +++++-
drivers/i2c/i2c-core.h | 4 ++--
3 files changed, 35 insertions(+), 12 deletions(-)

diff --git a/drivers/i2c/i2c-core-acpi.c b/drivers/i2c/i2c-core-acpi.c
index c762a879c4cc6b..c3d69b287df824 100644
--- a/drivers/i2c/i2c-core-acpi.c
+++ b/drivers/i2c/i2c-core-acpi.c
@@ -137,6 +137,11 @@ static const struct acpi_device_id i2c_acpi_ignored_device_ids[] = {
{}
};

+struct i2c_acpi_irq_context {
+ int irq;
+ int wake_capable;
+};
+
static int i2c_acpi_do_lookup(struct acpi_device *adev,
struct i2c_acpi_lookup *lookup)
{
@@ -170,11 +175,14 @@ static int i2c_acpi_do_lookup(struct acpi_device *adev,

static int i2c_acpi_add_resource(struct acpi_resource *ares, void *data)
{
- int *irq = data;
+ struct i2c_acpi_irq_context *irq_ctx = data;
struct resource r;

- if (*irq <= 0 && acpi_dev_resource_interrupt(ares, 0, &r))
- *irq = i2c_dev_irq_from_resources(&r, 1);
+ if (irq_ctx->irq <= 0 && acpi_dev_resource_interrupt(ares, 0, &r)) {
+ irq_ctx->irq = i2c_dev_irq_from_resources(&r, 1);
+ irq_ctx->wake_capable =
+ r.flags & IORESOURCE_IRQ_WAKECAPABLE ? 1 : 0;
+ }

return 1; /* No need to add resource to the list */
}
@@ -182,31 +190,42 @@ 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;
- int irq = -ENOENT;
+ struct i2c_acpi_irq_context irq_ctx = {
+ .irq = -ENOENT,
+ .wake_capable = 0,
+ };
int ret;

INIT_LIST_HEAD(&resource_list);

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

acpi_dev_free_resource_list(&resource_list);

- if (irq == -ENOENT)
- irq = acpi_dev_gpio_irq_get(adev, 0);
+ if (irq_ctx.irq == -ENOENT)
+ irq_ctx.irq = acpi_dev_gpio_irq_get_wake(
+ adev, 0, &irq_ctx.wake_capable);
+
+ if (wake_capable)
+ *wake_capable = irq_ctx.wake_capable;

- return irq;
+ return irq_ctx.irq;
}

static int i2c_acpi_get_info(struct acpi_device *adev,
diff --git a/drivers/i2c/i2c-core-base.c b/drivers/i2c/i2c-core-base.c
index 91007558bcb260..97315b41550213 100644
--- a/drivers/i2c/i2c-core-base.c
+++ b/drivers/i2c/i2c-core-base.c
@@ -468,6 +468,7 @@ static int i2c_device_probe(struct device *dev)
struct i2c_client *client = i2c_verify_client(dev);
struct i2c_driver *driver;
int status;
+ int acpi_wake_capable = 0;

if (!client)
return 0;
@@ -487,7 +488,10 @@ static int i2c_device_probe(struct device *dev)
if (irq == -EINVAL || irq == -ENODATA)
irq = of_irq_get(dev->of_node, 0);
} else if (ACPI_COMPANION(dev)) {
- irq = i2c_acpi_get_irq(client);
+ irq = i2c_acpi_get_irq(client, &acpi_wake_capable);
+
+ if (irq > 0 && acpi_wake_capable)
+ client->flags |= I2C_CLIENT_WAKE;
}
if (irq == -EPROBE_DEFER) {
status = irq;
diff --git a/drivers/i2c/i2c-core.h b/drivers/i2c/i2c-core.h
index 87e2c914f1c57b..8e336638a0cd2e 100644
--- a/drivers/i2c/i2c-core.h
+++ b/drivers/i2c/i2c-core.h
@@ -61,11 +61,11 @@ static inline int __i2c_check_suspended(struct i2c_adapter *adap)
#ifdef CONFIG_ACPI
void i2c_acpi_register_devices(struct i2c_adapter *adap);

-int i2c_acpi_get_irq(struct i2c_client *client);
+int i2c_acpi_get_irq(struct i2c_client *client, int *wake_capable);
#else /* CONFIG_ACPI */
static inline void i2c_acpi_register_devices(struct i2c_adapter *adap) { }

-static inline int i2c_acpi_get_irq(struct i2c_client *client)
+static inline int i2c_acpi_get_irq(struct i2c_client *client, int *wake_capable)
{
return 0;
}
--
2.37.2.789.g6183377224-goog


2022-09-13 07:40:53

by Wolfram Sang

[permalink] [raw]
Subject: Re: [PATCH v2 07/13] i2c: acpi: Use ACPI wake capability bit to set wake_irq

On Mon, Sep 12, 2022 at 04:13:11PM -0600, Raul E Rangel wrote:
> 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 the
> ACPI interrupt 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 wakes the system. For this reason we should
> respect the board designers wishes and honor the wake bit defined on the
> interrupt.

I'll let the I2C ACPI maintainers deal with the technical details
because they are the experts here, yet one minor thing hits my eye:

> + irq_ctx.irq = acpi_dev_gpio_irq_get_wake(
> + adev, 0, &irq_ctx.wake_capable);

That line split looks weird with the open parens at the end of line 1.


Attachments:
(No filename) (1.08 kB)
signature.asc (849.00 B)
Download all attachments

2022-09-13 17:52:16

by Raul Rangel

[permalink] [raw]
Subject: Re: [PATCH v2 07/13] i2c: acpi: Use ACPI wake capability bit to set wake_irq

On Tue, Sep 13, 2022 at 1:28 AM Wolfram Sang <[email protected]> wrote:
>
> On Mon, Sep 12, 2022 at 04:13:11PM -0600, Raul E Rangel wrote:
> > 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 the
> > ACPI interrupt 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 wakes the system. For this reason we should
> > respect the board designers wishes and honor the wake bit defined on the
> > interrupt.
>
> I'll let the I2C ACPI maintainers deal with the technical details
> because they are the experts here, yet one minor thing hits my eye:
>

> > + irq_ctx.irq = acpi_dev_gpio_irq_get_wake(
> > + adev, 0, &irq_ctx.wake_capable);
>
> That line split looks weird with the open parens at the end of line 1.
>
Ah, looks like I missed `clang-format` on that line. I can fix it in
the next revision.

Thanks

2022-09-13 18:45:58

by Andy Shevchenko

[permalink] [raw]
Subject: Re: [PATCH v2 07/13] i2c: acpi: Use ACPI wake capability bit to set wake_irq

On Mon, Sep 12, 2022 at 04:13:11PM -0600, Raul E Rangel wrote:
> 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 the
> ACPI interrupt 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 wakes the system. For this reason we should
> respect the board designers wishes and honor the wake bit defined on the
> interrupt.

...

> + if (irq > 0 && acpi_wake_capable)
> + client->flags |= I2C_CLIENT_WAKE;

Why do we need a parameter and can't simply set this flag inside the callee?

--
With Best Regards,
Andy Shevchenko


2022-09-13 19:03:37

by Raul Rangel

[permalink] [raw]
Subject: Re: [PATCH v2 07/13] i2c: acpi: Use ACPI wake capability bit to set wake_irq

On Tue, Sep 13, 2022 at 11:26 AM Andy Shevchenko
<[email protected]> wrote:
>
> On Mon, Sep 12, 2022 at 04:13:11PM -0600, Raul E Rangel wrote:
> > 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 the
> > ACPI interrupt 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 wakes the system. For this reason we should
> > respect the board designers wishes and honor the wake bit defined on the
> > interrupt.

>
> > + if (irq > 0 && acpi_wake_capable)
> > + client->flags |= I2C_CLIENT_WAKE;
>
> Why do we need a parameter and can't simply set this flag inside the callee?

Are you suggesting `i2c_acpi_get_irq` modify the `client->flags`? IMO
that's a little surprising since the I wouldn't expect a `get`
function to modify it's parameters. I'm fine implementing it if others
agree though.

2022-09-13 19:04:14

by Andy Shevchenko

[permalink] [raw]
Subject: Re: [PATCH v2 07/13] i2c: acpi: Use ACPI wake capability bit to set wake_irq

On Tue, Sep 13, 2022 at 12:07:53PM -0600, Raul Rangel wrote:
> On Tue, Sep 13, 2022 at 11:26 AM Andy Shevchenko
> <[email protected]> wrote:
> >
> > On Mon, Sep 12, 2022 at 04:13:11PM -0600, Raul E Rangel wrote:
> > > 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 the
> > > ACPI interrupt 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 wakes the system. For this reason we should
> > > respect the board designers wishes and honor the wake bit defined on the
> > > interrupt.
>
> >
> > > + if (irq > 0 && acpi_wake_capable)
> > > + client->flags |= I2C_CLIENT_WAKE;
> >
> > Why do we need a parameter and can't simply set this flag inside the callee?
>
> Are you suggesting `i2c_acpi_get_irq` modify the `client->flags`? IMO
> that's a little surprising since the I wouldn't expect a `get`
> function to modify it's parameters. I'm fine implementing it if others
> agree though.

This is similar to what of_i2c_get_board_info() does, no?
Note: _get_ there.


--
With Best Regards,
Andy Shevchenko


2022-09-13 19:29:50

by Raul Rangel

[permalink] [raw]
Subject: Re: [PATCH v2 07/13] i2c: acpi: Use ACPI wake capability bit to set wake_irq

On Tue, Sep 13, 2022 at 12:33 PM Andy Shevchenko
<[email protected]> wrote:
>
> On Tue, Sep 13, 2022 at 12:07:53PM -0600, Raul Rangel wrote:
> > On Tue, Sep 13, 2022 at 11:26 AM Andy Shevchenko
> > <[email protected]> wrote:
> > >
> > > On Mon, Sep 12, 2022 at 04:13:11PM -0600, Raul E Rangel wrote:
> > > > 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 the
> > > > ACPI interrupt 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 wakes the system. For this reason we should
> > > > respect the board designers wishes and honor the wake bit defined on the
> > > > interrupt.
> >
> > >
> > > > + if (irq > 0 && acpi_wake_capable)
> > > > + client->flags |= I2C_CLIENT_WAKE;
> > >
> > > Why do we need a parameter and can't simply set this flag inside the callee?
> >
> > Are you suggesting `i2c_acpi_get_irq` modify the `client->flags`? IMO
> > that's a little surprising since the I wouldn't expect a `get`
> > function to modify it's parameters. I'm fine implementing it if others
> > agree though.
>


> This is similar to what of_i2c_get_board_info() does, no?
> Note: _get_ there.
>

`*info` is an out parameter in that case. Ideally I would have
`i2c_acpi_get_irq`, `acpi_dev_gpio_irq_get_wake`,
`platform_get_irq_optional`, and `i2c_dev_irq_from_resources` all
return a `struct irq_info {int irq; bool wake_capable;}`. This would
be a larger change though.

2022-09-14 06:06:13

by Mika Westerberg

[permalink] [raw]
Subject: Re: [PATCH v2 07/13] i2c: acpi: Use ACPI wake capability bit to set wake_irq

Hi,

On Mon, Sep 12, 2022 at 04:13:11PM -0600, Raul E Rangel wrote:
> 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 the
> ACPI interrupt 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 wakes the system. For this reason we should
> respect the board designers wishes and honor the wake bit defined on the
> interrupt.
>
> Signed-off-by: Raul E Rangel <[email protected]>
> ---
>
> Changes in v2:
> - Look at wake_cabple bit for IRQ/Interrupt resources
>
> drivers/i2c/i2c-core-acpi.c | 37 ++++++++++++++++++++++++++++---------
> drivers/i2c/i2c-core-base.c | 6 +++++-
> drivers/i2c/i2c-core.h | 4 ++--
> 3 files changed, 35 insertions(+), 12 deletions(-)
>
> diff --git a/drivers/i2c/i2c-core-acpi.c b/drivers/i2c/i2c-core-acpi.c
> index c762a879c4cc6b..c3d69b287df824 100644
> --- a/drivers/i2c/i2c-core-acpi.c
> +++ b/drivers/i2c/i2c-core-acpi.c
> @@ -137,6 +137,11 @@ static const struct acpi_device_id i2c_acpi_ignored_device_ids[] = {
> {}
> };
>
> +struct i2c_acpi_irq_context {
> + int irq;
> + int wake_capable;

Why not bool?

Also perhaps 'wakeable'?

> +};
> +
> static int i2c_acpi_do_lookup(struct acpi_device *adev,
> struct i2c_acpi_lookup *lookup)
> {
> @@ -170,11 +175,14 @@ static int i2c_acpi_do_lookup(struct acpi_device *adev,
>
> static int i2c_acpi_add_resource(struct acpi_resource *ares, void *data)
> {
> - int *irq = data;
> + struct i2c_acpi_irq_context *irq_ctx = data;
> struct resource r;
>
> - if (*irq <= 0 && acpi_dev_resource_interrupt(ares, 0, &r))
> - *irq = i2c_dev_irq_from_resources(&r, 1);
> + if (irq_ctx->irq <= 0 && acpi_dev_resource_interrupt(ares, 0, &r)) {
> + irq_ctx->irq = i2c_dev_irq_from_resources(&r, 1);
> + irq_ctx->wake_capable =
> + r.flags & IORESOURCE_IRQ_WAKECAPABLE ? 1 : 0;

Then you can just do this:

irq_ctx->wakeable = r.flags & IORESOURCE_IRQ_WAKECAPABLE;

> + }
>
> return 1; /* No need to add resource to the list */
> }
> @@ -182,31 +190,42 @@ 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)

bool here too

> {
> struct acpi_device *adev = ACPI_COMPANION(&client->dev);
> struct list_head resource_list;
> - int irq = -ENOENT;
> + struct i2c_acpi_irq_context irq_ctx = {
> + .irq = -ENOENT,
> + .wake_capable = 0,
> + };
> int ret;
>
> INIT_LIST_HEAD(&resource_list);
>
> + if (wake_capable)
> + *wake_capable = 0;

I think it is better to touch this only after the function succeeds so..

> +
> ret = acpi_dev_get_resources(adev, &resource_list,
> - i2c_acpi_add_resource, &irq);
> + i2c_acpi_add_resource, &irq_ctx);
> if (ret < 0)
> return ret;
>
> acpi_dev_free_resource_list(&resource_list);
>
> - if (irq == -ENOENT)
> - irq = acpi_dev_gpio_irq_get(adev, 0);
> + if (irq_ctx.irq == -ENOENT)
> + irq_ctx.irq = acpi_dev_gpio_irq_get_wake(
> + adev, 0, &irq_ctx.wake_capable);
> +
> + if (wake_capable)
> + *wake_capable = irq_ctx.wake_capable;

... here only.

>
> - return irq;
> + return irq_ctx.irq;
> }
>
> static int i2c_acpi_get_info(struct acpi_device *adev,
> diff --git a/drivers/i2c/i2c-core-base.c b/drivers/i2c/i2c-core-base.c
> index 91007558bcb260..97315b41550213 100644
> --- a/drivers/i2c/i2c-core-base.c
> +++ b/drivers/i2c/i2c-core-base.c
> @@ -468,6 +468,7 @@ static int i2c_device_probe(struct device *dev)
> struct i2c_client *client = i2c_verify_client(dev);
> struct i2c_driver *driver;
> int status;
> + int acpi_wake_capable = 0;

You can declare this in the below block instead.

>
> if (!client)
> return 0;
> @@ -487,7 +488,10 @@ static int i2c_device_probe(struct device *dev)
> if (irq == -EINVAL || irq == -ENODATA)
> irq = of_irq_get(dev->of_node, 0);
> } else if (ACPI_COMPANION(dev)) {

bool wakeable;

> - irq = i2c_acpi_get_irq(client);
> + irq = i2c_acpi_get_irq(client, &acpi_wake_capable);
> +
if (irq > 0 && wakeable)
client->flags |= I2C_CLIENT_WAKE;
> }
> if (irq == -EPROBE_DEFER) {
> status = irq;
> diff --git a/drivers/i2c/i2c-core.h b/drivers/i2c/i2c-core.h
> index 87e2c914f1c57b..8e336638a0cd2e 100644
> --- a/drivers/i2c/i2c-core.h
> +++ b/drivers/i2c/i2c-core.h
> @@ -61,11 +61,11 @@ static inline int __i2c_check_suspended(struct i2c_adapter *adap)
> #ifdef CONFIG_ACPI
> void i2c_acpi_register_devices(struct i2c_adapter *adap);
>
> -int i2c_acpi_get_irq(struct i2c_client *client);
> +int i2c_acpi_get_irq(struct i2c_client *client, int *wake_capable);
> #else /* CONFIG_ACPI */
> static inline void i2c_acpi_register_devices(struct i2c_adapter *adap) { }
>
> -static inline int i2c_acpi_get_irq(struct i2c_client *client)
> +static inline int i2c_acpi_get_irq(struct i2c_client *client, int *wake_capable)
> {
> return 0;
> }
> --
> 2.37.2.789.g6183377224-goog

2022-09-14 10:22:22

by Andy Shevchenko

[permalink] [raw]
Subject: Re: [PATCH v2 07/13] i2c: acpi: Use ACPI wake capability bit to set wake_irq

On Tue, Sep 13, 2022 at 12:56:37PM -0600, Raul Rangel wrote:
> On Tue, Sep 13, 2022 at 12:33 PM Andy Shevchenko
> <[email protected]> wrote:
> > On Tue, Sep 13, 2022 at 12:07:53PM -0600, Raul Rangel wrote:

...

> > This is similar to what of_i2c_get_board_info() does, no?
> > Note: _get_ there.
>
> `*info` is an out parameter in that case. Ideally I would have
> `i2c_acpi_get_irq`, `acpi_dev_gpio_irq_get_wake`,
> `platform_get_irq_optional`, and `i2c_dev_irq_from_resources` all
> return a `struct irq_info {int irq; bool wake_capable;}`. This would
> be a larger change though.

Seems the ACPI analogue is i2c_acpi_fill_info(). Can we do it there?

--
With Best Regards,
Andy Shevchenko


2022-09-14 19:41:13

by Raul Rangel

[permalink] [raw]
Subject: Re: [PATCH v2 07/13] i2c: acpi: Use ACPI wake capability bit to set wake_irq

> > > This is similar to what of_i2c_get_board_info() does, no?
> > > Note: _get_ there.
> >
> > `*info` is an out parameter in that case. Ideally I would have
> > `i2c_acpi_get_irq`, `acpi_dev_gpio_irq_get_wake`,
> > `platform_get_irq_optional`, and `i2c_dev_irq_from_resources` all
> > return a `struct irq_info {int irq; bool wake_capable;}`. This would
> > be a larger change though.
>
> Seems the ACPI analogue is i2c_acpi_fill_info(). Can we do it there?
>

So I originally had that thought, but decided against it to avoid
changing too many things,
but since you brought it up, I thought I would try it.

So I moved the GPIO lookup into `i2c_acpi_do_lookup`, but it failed
spectacularly.
I've linked some logs of both cases. grep for `RX:` to see my logging messages.

* https://0paste.com/393416 - Logs with IRQ lookup happening in
`i2c_acpi_do_lookup`
* We can see that `i2c_acpi_do_lookup` gets called in three cases
1) Early on from i2c_acpi_notify when the I2C ACPI nodes are
first created
2) From `i2c_dw_adjust_bus_speed` as part of `dw_i2c_plat_probe`
3) From `i2c_register_adapter` as part of `i2c_dw_probe_master`.
* What happens is that all of these calls happen before the GPIO
chip has been registered.
This means that `acpi_dev_gpio_irq_get` will return `-EPROBE_DEFER`. This
messes something up in the i2c init sequence and the devices are never
probed again.
* You can see the `amd gpio driver loaded` message after all the
i2c probing.
* https://0paste.com/393420 - Logs of a normal boot
* Here we can see the GPIO controller registers early
* We can see the i2c devices being probed by `__driver_attach_async_helper`.
I'm guessing the device was enqueued as part of `i2c_acpi_register_device`
early on and it gets probed later.

I could try moving the gpio lookup into `i2c_acpi_get_info`, but I
think that suffers from the
same problem, the stack can't handle a PROBE_DEFER. So I think we need to keep
the lookup in `i2c_device_probe` for the PROBE_DEFER logic to work correctly.

2022-09-14 21:10:47

by Raul Rangel

[permalink] [raw]
Subject: Re: [PATCH v2 07/13] i2c: acpi: Use ACPI wake capability bit to set wake_irq

On Tue, Sep 13, 2022 at 11:54 PM Mika Westerberg
<[email protected]> wrote:
>
> Hi,
>
> On Mon, Sep 12, 2022 at 04:13:11PM -0600, Raul E Rangel wrote:
> > 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 the
> > ACPI interrupt 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 wakes the system. For this reason we should
> > respect the board designers wishes and honor the wake bit defined on the
> > interrupt.
> >
> > Signed-off-by: Raul E Rangel <[email protected]>
> > ---
> >
> > Changes in v2:
> > - Look at wake_cabple bit for IRQ/Interrupt resources
> >
> > drivers/i2c/i2c-core-acpi.c | 37 ++++++++++++++++++++++++++++---------
> > drivers/i2c/i2c-core-base.c | 6 +++++-
> > drivers/i2c/i2c-core.h | 4 ++--
> > 3 files changed, 35 insertions(+), 12 deletions(-)
> >
> > diff --git a/drivers/i2c/i2c-core-acpi.c b/drivers/i2c/i2c-core-acpi.c
> > index c762a879c4cc6b..c3d69b287df824 100644
> > --- a/drivers/i2c/i2c-core-acpi.c
> > +++ b/drivers/i2c/i2c-core-acpi.c
> > @@ -137,6 +137,11 @@ static const struct acpi_device_id i2c_acpi_ignored_device_ids[] = {
> > {}
> > };
> >

> > +struct i2c_acpi_irq_context {
> > + int irq;
> > + int wake_capable;
>
> Why not bool?
>
SGTM


> Also perhaps 'wakeable'?
>

I kept it as wake_capable since I want to keep some consistency with
the ACPI nodes.

> > +};
> > +
> > static int i2c_acpi_do_lookup(struct acpi_device *adev,
> > struct i2c_acpi_lookup *lookup)
> > {
> > @@ -170,11 +175,14 @@ static int i2c_acpi_do_lookup(struct acpi_device *adev,
> >
> > static int i2c_acpi_add_resource(struct acpi_resource *ares, void *data)
> > {
> > - int *irq = data;
> > + struct i2c_acpi_irq_context *irq_ctx = data;
> > struct resource r;
> >
> > - if (*irq <= 0 && acpi_dev_resource_interrupt(ares, 0, &r))
> > - *irq = i2c_dev_irq_from_resources(&r, 1);
> > + if (irq_ctx->irq <= 0 && acpi_dev_resource_interrupt(ares, 0, &r)) {
> > + irq_ctx->irq = i2c_dev_irq_from_resources(&r, 1);
> > + irq_ctx->wake_capable =
> > + r.flags & IORESOURCE_IRQ_WAKECAPABLE ? 1 : 0;
>
> Then you can just do this:
>
> irq_ctx->wakeable = r.flags & IORESOURCE_IRQ_WAKECAPABLE;
>
> > + }
> >
> > return 1; /* No need to add resource to the list */
> > }
> > @@ -182,31 +190,42 @@ 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)
>
> bool here too
>
> > {
> > struct acpi_device *adev = ACPI_COMPANION(&client->dev);
> > struct list_head resource_list;
> > - int irq = -ENOENT;
> > + struct i2c_acpi_irq_context irq_ctx = {
> > + .irq = -ENOENT,
> > + .wake_capable = 0,
> > + };
> > int ret;
> >
> > INIT_LIST_HEAD(&resource_list);
> >
> > + if (wake_capable)
> > + *wake_capable = 0;
>
> I think it is better to touch this only after the function succeeds so..
>
> > +
> > ret = acpi_dev_get_resources(adev, &resource_list,
> > - i2c_acpi_add_resource, &irq);
> > + i2c_acpi_add_resource, &irq_ctx);
> > if (ret < 0)
> > return ret;
> >
> > acpi_dev_free_resource_list(&resource_list);
> >
> > - if (irq == -ENOENT)
> > - irq = acpi_dev_gpio_irq_get(adev, 0);
> > + if (irq_ctx.irq == -ENOENT)
> > + irq_ctx.irq = acpi_dev_gpio_irq_get_wake(
> > + adev, 0, &irq_ctx.wake_capable);
> > +
> > + if (wake_capable)
> > + *wake_capable = irq_ctx.wake_capable;
>
> ... here only.
>
> >
> > - return irq;
> > + return irq_ctx.irq;
> > }
> >
> > static int i2c_acpi_get_info(struct acpi_device *adev,
> > diff --git a/drivers/i2c/i2c-core-base.c b/drivers/i2c/i2c-core-base.c
> > index 91007558bcb260..97315b41550213 100644
> > --- a/drivers/i2c/i2c-core-base.c
> > +++ b/drivers/i2c/i2c-core-base.c
> > @@ -468,6 +468,7 @@ static int i2c_device_probe(struct device *dev)
> > struct i2c_client *client = i2c_verify_client(dev);
> > struct i2c_driver *driver;
> > int status;
> > + int acpi_wake_capable = 0;
>
> You can declare this in the below block instead.
>
> >
> > if (!client)
> > return 0;
> > @@ -487,7 +488,10 @@ static int i2c_device_probe(struct device *dev)
> > if (irq == -EINVAL || irq == -ENODATA)
> > irq = of_irq_get(dev->of_node, 0);
> > } else if (ACPI_COMPANION(dev)) {
>
> bool wakeable;
>
> > - irq = i2c_acpi_get_irq(client);
> > + irq = i2c_acpi_get_irq(client, &acpi_wake_capable);
> > +
> if (irq > 0 && wakeable)
> client->flags |= I2C_CLIENT_WAKE;
> > }
> > if (irq == -EPROBE_DEFER) {
> > status = irq;
> > diff --git a/drivers/i2c/i2c-core.h b/drivers/i2c/i2c-core.h
> > index 87e2c914f1c57b..8e336638a0cd2e 100644
> > --- a/drivers/i2c/i2c-core.h
> > +++ b/drivers/i2c/i2c-core.h
> > @@ -61,11 +61,11 @@ static inline int __i2c_check_suspended(struct i2c_adapter *adap)
> > #ifdef CONFIG_ACPI
> > void i2c_acpi_register_devices(struct i2c_adapter *adap);
> >
> > -int i2c_acpi_get_irq(struct i2c_client *client);
> > +int i2c_acpi_get_irq(struct i2c_client *client, int *wake_capable);
> > #else /* CONFIG_ACPI */
> > static inline void i2c_acpi_register_devices(struct i2c_adapter *adap) { }
> >
> > -static inline int i2c_acpi_get_irq(struct i2c_client *client)
> > +static inline int i2c_acpi_get_irq(struct i2c_client *client, int *wake_capable)
> > {
> > return 0;
> > }
> > --
> > 2.37.2.789.g6183377224-goog

I'll push out another patch series with all the latest changes.

Thanks for the reviews everyone.