diff mbox series

[v6,06/13] ACPI: resources: Add wake_capable parameter to acpi_dev_irq_flags

Message ID 20220929093200.v6.6.I8092e417a8152475d13d8d638eb4c5d8ea12ac7b@changeid (mailing list archive)
State Mainlined
Commit 5ff811604f93bdd2650beed80b48c2ca16c6fba6
Headers show
Series acpi: i2c: Use SharedAndWake and ExclusiveAndWake to enable wake irq | expand

Commit Message

Raul Rangel Sept. 29, 2022, 4:19 p.m. UTC
ACPI IRQ/Interrupt resources contain a bit that describes if the
interrupt should wake the system. This change exposes that bit via
a new IORESOURCE_IRQ_WAKECAPABLE flag. Drivers should check this flag
before arming an IRQ to wake the system.

Signed-off-by: Raul E Rangel <rrangel@chromium.org>
Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>

---

(no changes since v5)

Changes in v5:
- Removed clang-format white space changes

Changes in v4:
- Added Reviewed-by
- Reformatted with 96 char limit

Changes in v3:
- Fixed bad indent

Changes in v2:
- Added ability to extract wake bit from Interrupt/IRQ resources

 drivers/acpi/irq.c             |  8 +++++---
 drivers/acpi/resource.c        | 16 +++++++++++-----
 drivers/pnp/pnpacpi/rsparser.c |  7 ++++---
 include/linux/acpi.h           |  2 +-
 include/linux/ioport.h         |  3 ++-
 5 files changed, 23 insertions(+), 13 deletions(-)

Comments

Rafael J. Wysocki Sept. 29, 2022, 7:17 p.m. UTC | #1
On Thu, Sep 29, 2022 at 6:19 PM Raul E Rangel <rrangel@chromium.org> wrote:
>
> ACPI IRQ/Interrupt resources contain a bit that describes if the
> interrupt should wake the system. This change exposes that bit via
> a new IORESOURCE_IRQ_WAKECAPABLE flag. Drivers should check this flag

I would call this IORESOURCE_IRQ_WAKE which is (a) simpler and easier
to read and (b) it sort of matches the "wakeirq" naming convention.

This is not a big deal if you insist on this name and for a good
reason, but just something I would do differently.

The patch LGTM otherwise.

> before arming an IRQ to wake the system.
>
> Signed-off-by: Raul E Rangel <rrangel@chromium.org>
> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
>
> ---
>
> (no changes since v5)
>
> Changes in v5:
> - Removed clang-format white space changes
>
> Changes in v4:
> - Added Reviewed-by
> - Reformatted with 96 char limit
>
> Changes in v3:
> - Fixed bad indent
>
> Changes in v2:
> - Added ability to extract wake bit from Interrupt/IRQ resources
>
>  drivers/acpi/irq.c             |  8 +++++---
>  drivers/acpi/resource.c        | 16 +++++++++++-----
>  drivers/pnp/pnpacpi/rsparser.c |  7 ++++---
>  include/linux/acpi.h           |  2 +-
>  include/linux/ioport.h         |  3 ++-
>  5 files changed, 23 insertions(+), 13 deletions(-)
>
> diff --git a/drivers/acpi/irq.c b/drivers/acpi/irq.c
> index dabe45eba055d1f..4bb5ab33a5ceb10 100644
> --- a/drivers/acpi/irq.c
> +++ b/drivers/acpi/irq.c
> @@ -147,6 +147,7 @@ struct acpi_irq_parse_one_ctx {
>   * @polarity: polarity attributes of hwirq
>   * @polarity: polarity attributes of hwirq
>   * @shareable: shareable attributes of hwirq
> + * @wake_capable: wake capable attribute of hwirq
>   * @ctx: acpi_irq_parse_one_ctx updated by this function
>   *
>   * Description:
> @@ -156,12 +157,13 @@ struct acpi_irq_parse_one_ctx {
>  static inline void acpi_irq_parse_one_match(struct fwnode_handle *fwnode,
>                                             u32 hwirq, u8 triggering,
>                                             u8 polarity, u8 shareable,
> +                                           u8 wake_capable,
>                                             struct acpi_irq_parse_one_ctx *ctx)
>  {
>         if (!fwnode)
>                 return;
>         ctx->rc = 0;
> -       *ctx->res_flags = acpi_dev_irq_flags(triggering, polarity, shareable);
> +       *ctx->res_flags = acpi_dev_irq_flags(triggering, polarity, shareable, wake_capable);
>         ctx->fwspec->fwnode = fwnode;
>         ctx->fwspec->param[0] = hwirq;
>         ctx->fwspec->param[1] = acpi_dev_get_irq_type(triggering, polarity);
> @@ -204,7 +206,7 @@ static acpi_status acpi_irq_parse_one_cb(struct acpi_resource *ares,
>                 fwnode = acpi_get_gsi_domain_id(irq->interrupts[ctx->index]);
>                 acpi_irq_parse_one_match(fwnode, irq->interrupts[ctx->index],
>                                          irq->triggering, irq->polarity,
> -                                        irq->shareable, ctx);
> +                                        irq->shareable, irq->wake_capable, ctx);
>                 return AE_CTRL_TERMINATE;
>         case ACPI_RESOURCE_TYPE_EXTENDED_IRQ:
>                 eirq = &ares->data.extended_irq;
> @@ -218,7 +220,7 @@ static acpi_status acpi_irq_parse_one_cb(struct acpi_resource *ares,
>                                                       eirq->interrupts[ctx->index]);
>                 acpi_irq_parse_one_match(fwnode, eirq->interrupts[ctx->index],
>                                          eirq->triggering, eirq->polarity,
> -                                        eirq->shareable, ctx);
> +                                        eirq->shareable, eirq->wake_capable, ctx);
>                 return AE_CTRL_TERMINATE;
>         }
>
> diff --git a/drivers/acpi/resource.c b/drivers/acpi/resource.c
> index 510cdec375c4d88..81733369f4c1de0 100644
> --- a/drivers/acpi/resource.c
> +++ b/drivers/acpi/resource.c
> @@ -336,8 +336,9 @@ EXPORT_SYMBOL_GPL(acpi_dev_resource_ext_address_space);
>   * @triggering: Triggering type as provided by ACPI.
>   * @polarity: Interrupt polarity as provided by ACPI.
>   * @shareable: Whether or not the interrupt is shareable.
> + * @wake_capable: Wake capability as provided by ACPI.
>   */
> -unsigned long acpi_dev_irq_flags(u8 triggering, u8 polarity, u8 shareable)
> +unsigned long acpi_dev_irq_flags(u8 triggering, u8 polarity, u8 shareable, u8 wake_capable)
>  {
>         unsigned long flags;
>
> @@ -351,6 +352,9 @@ unsigned long acpi_dev_irq_flags(u8 triggering, u8 polarity, u8 shareable)
>         if (shareable == ACPI_SHARED)
>                 flags |= IORESOURCE_IRQ_SHAREABLE;
>
> +       if (wake_capable == ACPI_WAKE_CAPABLE)
> +               flags |= IORESOURCE_IRQ_WAKECAPABLE;
> +
>         return flags | IORESOURCE_IRQ;
>  }
>  EXPORT_SYMBOL_GPL(acpi_dev_irq_flags);
> @@ -442,7 +446,7 @@ static bool acpi_dev_irq_override(u32 gsi, u8 triggering, u8 polarity,
>
>  static void acpi_dev_get_irqresource(struct resource *res, u32 gsi,
>                                      u8 triggering, u8 polarity, u8 shareable,
> -                                    bool check_override)
> +                                    u8 wake_capable, bool check_override)
>  {
>         int irq, p, t;
>
> @@ -475,7 +479,7 @@ static void acpi_dev_get_irqresource(struct resource *res, u32 gsi,
>                 }
>         }
>
> -       res->flags = acpi_dev_irq_flags(triggering, polarity, shareable);
> +       res->flags = acpi_dev_irq_flags(triggering, polarity, shareable, wake_capable);
>         irq = acpi_register_gsi(NULL, gsi, triggering, polarity);
>         if (irq >= 0) {
>                 res->start = irq;
> @@ -523,7 +527,8 @@ bool acpi_dev_resource_interrupt(struct acpi_resource *ares, int index,
>                 }
>                 acpi_dev_get_irqresource(res, irq->interrupts[index],
>                                          irq->triggering, irq->polarity,
> -                                        irq->shareable, true);
> +                                        irq->shareable, irq->wake_capable,
> +                                        true);
>                 break;
>         case ACPI_RESOURCE_TYPE_EXTENDED_IRQ:
>                 ext_irq = &ares->data.extended_irq;
> @@ -534,7 +539,8 @@ bool acpi_dev_resource_interrupt(struct acpi_resource *ares, int index,
>                 if (is_gsi(ext_irq))
>                         acpi_dev_get_irqresource(res, ext_irq->interrupts[index],
>                                          ext_irq->triggering, ext_irq->polarity,
> -                                        ext_irq->shareable, false);
> +                                        ext_irq->shareable, ext_irq->wake_capable,
> +                                        false);
>                 else
>                         irqresource_disabled(res, 0);
>                 break;
> diff --git a/drivers/pnp/pnpacpi/rsparser.c b/drivers/pnp/pnpacpi/rsparser.c
> index da78dc77aed32e4..4f05f610391b006 100644
> --- a/drivers/pnp/pnpacpi/rsparser.c
> +++ b/drivers/pnp/pnpacpi/rsparser.c
> @@ -206,7 +206,8 @@ static acpi_status pnpacpi_allocated_resource(struct acpi_resource *res,
>                 if (i >= 0) {
>                         flags = acpi_dev_irq_flags(gpio->triggering,
>                                                    gpio->polarity,
> -                                                  gpio->shareable);
> +                                                  gpio->shareable,
> +                                                  gpio->wake_capable);
>                 } else {
>                         flags = IORESOURCE_DISABLED;
>                 }
> @@ -315,7 +316,7 @@ static __init void pnpacpi_parse_irq_option(struct pnp_dev *dev,
>                 if (p->interrupts[i])
>                         __set_bit(p->interrupts[i], map.bits);
>
> -       flags = acpi_dev_irq_flags(p->triggering, p->polarity, p->shareable);
> +       flags = acpi_dev_irq_flags(p->triggering, p->polarity, p->shareable, p->wake_capable);
>         pnp_register_irq_resource(dev, option_flags, &map, flags);
>  }
>
> @@ -339,7 +340,7 @@ static __init void pnpacpi_parse_ext_irq_option(struct pnp_dev *dev,
>                 }
>         }
>
> -       flags = acpi_dev_irq_flags(p->triggering, p->polarity, p->shareable);
> +       flags = acpi_dev_irq_flags(p->triggering, p->polarity, p->shareable, p->wake_capable);
>         pnp_register_irq_resource(dev, option_flags, &map, flags);
>  }
>
> diff --git a/include/linux/acpi.h b/include/linux/acpi.h
> index cd7371a5f2839bd..ea2efbdbeee5116 100644
> --- a/include/linux/acpi.h
> +++ b/include/linux/acpi.h
> @@ -495,7 +495,7 @@ bool acpi_dev_resource_address_space(struct acpi_resource *ares,
>                                      struct resource_win *win);
>  bool acpi_dev_resource_ext_address_space(struct acpi_resource *ares,
>                                          struct resource_win *win);
> -unsigned long acpi_dev_irq_flags(u8 triggering, u8 polarity, u8 shareable);
> +unsigned long acpi_dev_irq_flags(u8 triggering, u8 polarity, u8 shareable, u8 wake_capable);
>  unsigned int acpi_dev_get_irq_type(int triggering, int polarity);
>  bool acpi_dev_resource_interrupt(struct acpi_resource *ares, int index,
>                                  struct resource *res);
> diff --git a/include/linux/ioport.h b/include/linux/ioport.h
> index 616b683563a9704..3baeea4d903bfd1 100644
> --- a/include/linux/ioport.h
> +++ b/include/linux/ioport.h
> @@ -79,7 +79,8 @@ struct resource {
>  #define IORESOURCE_IRQ_HIGHLEVEL       (1<<2)
>  #define IORESOURCE_IRQ_LOWLEVEL                (1<<3)
>  #define IORESOURCE_IRQ_SHAREABLE       (1<<4)
> -#define IORESOURCE_IRQ_OPTIONAL        (1<<5)
> +#define IORESOURCE_IRQ_OPTIONAL                (1<<5)
> +#define IORESOURCE_IRQ_WAKECAPABLE     (1<<6)
>
>  /* PnP DMA specific bits (IORESOURCE_BITS) */
>  #define IORESOURCE_DMA_TYPE_MASK       (3<<0)
> --
> 2.37.3.998.g577e59143f-goog
>
Raul Rangel Sept. 29, 2022, 7:27 p.m. UTC | #2
On Thu, Sep 29, 2022 at 1:18 PM Rafael J. Wysocki <rafael@kernel.org> wrote:
>
> On Thu, Sep 29, 2022 at 6:19 PM Raul E Rangel <rrangel@chromium.org> wrote:
> >
> > ACPI IRQ/Interrupt resources contain a bit that describes if the
> > interrupt should wake the system. This change exposes that bit via
> > a new IORESOURCE_IRQ_WAKECAPABLE flag. Drivers should check this flag
>
> I would call this IORESOURCE_IRQ_WAKE which is (a) simpler and easier
> to read and (b) it sort of matches the "wakeirq" naming convention.

It was Dmitry who originally suggested the name. I personally like the
CAPABLE in the name. It makes it clear that it's capable of acting as
a wake source, not to be confused with being enabled as a wake source.

>
> This is not a big deal if you insist on this name and for a good
> reason, but just something I would do differently.
>
> The patch LGTM otherwise.
>
Rafael J. Wysocki Sept. 29, 2022, 7:38 p.m. UTC | #3
On Thu, Sep 29, 2022 at 9:27 PM Raul Rangel <rrangel@chromium.org> wrote:
>
> On Thu, Sep 29, 2022 at 1:18 PM Rafael J. Wysocki <rafael@kernel.org> wrote:
> >
> > On Thu, Sep 29, 2022 at 6:19 PM Raul E Rangel <rrangel@chromium.org> wrote:
> > >
> > > ACPI IRQ/Interrupt resources contain a bit that describes if the
> > > interrupt should wake the system. This change exposes that bit via
> > > a new IORESOURCE_IRQ_WAKECAPABLE flag. Drivers should check this flag
> >
> > I would call this IORESOURCE_IRQ_WAKE which is (a) simpler and easier
> > to read and (b) it sort of matches the "wakeirq" naming convention.
>
> It was Dmitry who originally suggested the name. I personally like the
> CAPABLE in the name. It makes it clear that it's capable of acting as
> a wake source, not to be confused with being enabled as a wake source.

Well, so be it then.

As I said elsewhere, I can apply this patch too if that's useful at this point.

> >
> > This is not a big deal if you insist on this name and for a good
> > reason, but just something I would do differently.
> >
> > The patch LGTM otherwise.
> >
Raul Rangel Sept. 29, 2022, 9:20 p.m. UTC | #4
On Thu, Sep 29, 2022 at 1:38 PM Rafael J. Wysocki <rafael@kernel.org> wrote:
>
> On Thu, Sep 29, 2022 at 9:27 PM Raul Rangel <rrangel@chromium.org> wrote:
> >
> > On Thu, Sep 29, 2022 at 1:18 PM Rafael J. Wysocki <rafael@kernel.org> wrote:
> > >
> > > On Thu, Sep 29, 2022 at 6:19 PM Raul E Rangel <rrangel@chromium.org> wrote:
> > > >
> > > > ACPI IRQ/Interrupt resources contain a bit that describes if the
> > > > interrupt should wake the system. This change exposes that bit via
> > > > a new IORESOURCE_IRQ_WAKECAPABLE flag. Drivers should check this flag
> > >
> > > I would call this IORESOURCE_IRQ_WAKE which is (a) simpler and easier
> > > to read and (b) it sort of matches the "wakeirq" naming convention.
> >
> > It was Dmitry who originally suggested the name. I personally like the
> > CAPABLE in the name. It makes it clear that it's capable of acting as
> > a wake source, not to be confused with being enabled as a wake source.
>
> Well, so be it then.
>
> As I said elsewhere, I can apply this patch too if that's useful at this point.
>

We just need to make sure the ACPI patches 5-8 land before the i2c
patches 9-13. The i2c patches 1-4 can land before or after the ACPI
changes. I'm not sure how things get coordinated across subsystems.

> > >
> > > This is not a big deal if you insist on this name and for a good
> > > reason, but just something I would do differently.
> > >
> > > The patch LGTM otherwise.
> > >
Dmitry Torokhov Sept. 29, 2022, 11:22 p.m. UTC | #5
On Thu, Sep 29, 2022 at 03:20:12PM -0600, Raul Rangel wrote:
> On Thu, Sep 29, 2022 at 1:38 PM Rafael J. Wysocki <rafael@kernel.org> wrote:
> >
> > On Thu, Sep 29, 2022 at 9:27 PM Raul Rangel <rrangel@chromium.org> wrote:
> > >
> > > On Thu, Sep 29, 2022 at 1:18 PM Rafael J. Wysocki <rafael@kernel.org> wrote:
> > > >
> > > > On Thu, Sep 29, 2022 at 6:19 PM Raul E Rangel <rrangel@chromium.org> wrote:
> > > > >
> > > > > ACPI IRQ/Interrupt resources contain a bit that describes if the
> > > > > interrupt should wake the system. This change exposes that bit via
> > > > > a new IORESOURCE_IRQ_WAKECAPABLE flag. Drivers should check this flag
> > > >
> > > > I would call this IORESOURCE_IRQ_WAKE which is (a) simpler and easier
> > > > to read and (b) it sort of matches the "wakeirq" naming convention.
> > >
> > > It was Dmitry who originally suggested the name. I personally like the
> > > CAPABLE in the name. It makes it clear that it's capable of acting as
> > > a wake source, not to be confused with being enabled as a wake source.
> >
> > Well, so be it then.
> >
> > As I said elsewhere, I can apply this patch too if that's useful at this point.
> >
> 
> We just need to make sure the ACPI patches 5-8 land before the i2c
> patches 9-13. The i2c patches 1-4 can land before or after the ACPI
> changes. I'm not sure how things get coordinated across subsystems.

I am fine with all input stuff going through ACPI tree to ease landing.
Or I can pick up everything if Rafael and Jiri/Benjamin agree.
Rafael J. Wysocki Sept. 30, 2022, 5:13 p.m. UTC | #6
On Fri, Sep 30, 2022 at 1:22 AM Dmitry Torokhov
<dmitry.torokhov@gmail.com> wrote:
>
> On Thu, Sep 29, 2022 at 03:20:12PM -0600, Raul Rangel wrote:
> > On Thu, Sep 29, 2022 at 1:38 PM Rafael J. Wysocki <rafael@kernel.org> wrote:
> > >
> > > On Thu, Sep 29, 2022 at 9:27 PM Raul Rangel <rrangel@chromium.org> wrote:
> > > >
> > > > On Thu, Sep 29, 2022 at 1:18 PM Rafael J. Wysocki <rafael@kernel.org> wrote:
> > > > >
> > > > > On Thu, Sep 29, 2022 at 6:19 PM Raul E Rangel <rrangel@chromium.org> wrote:
> > > > > >
> > > > > > ACPI IRQ/Interrupt resources contain a bit that describes if the
> > > > > > interrupt should wake the system. This change exposes that bit via
> > > > > > a new IORESOURCE_IRQ_WAKECAPABLE flag. Drivers should check this flag
> > > > >
> > > > > I would call this IORESOURCE_IRQ_WAKE which is (a) simpler and easier
> > > > > to read and (b) it sort of matches the "wakeirq" naming convention.
> > > >
> > > > It was Dmitry who originally suggested the name. I personally like the
> > > > CAPABLE in the name. It makes it clear that it's capable of acting as
> > > > a wake source, not to be confused with being enabled as a wake source.
> > >
> > > Well, so be it then.
> > >
> > > As I said elsewhere, I can apply this patch too if that's useful at this point.
> > >
> >
> > We just need to make sure the ACPI patches 5-8 land before the i2c
> > patches 9-13. The i2c patches 1-4 can land before or after the ACPI
> > changes. I'm not sure how things get coordinated across subsystems.
>
> I am fine with all input stuff going through ACPI tree to ease landing.
> Or I can pick up everything if Rafael and Jiri/Benjamin agree.

I think that patches [5-8/13] from this series are significant
framework changes, so it would make sense to route them via the ACPI
tree.

If this is fine with everybody, I will queue them up for merging into
6.1 (probably in the second half of the upcoming merge window).
Andy Shevchenko Sept. 30, 2022, 5:42 p.m. UTC | #7
On Fri, Sep 30, 2022 at 07:13:37PM +0200, Rafael J. Wysocki wrote:
> On Fri, Sep 30, 2022 at 1:22 AM Dmitry Torokhov
> <dmitry.torokhov@gmail.com> wrote:

...

> I think that patches [5-8/13] from this series are significant
> framework changes, so it would make sense to route them via the ACPI
> tree.
> 
> If this is fine with everybody, I will queue them up for merging into
> 6.1 (probably in the second half of the upcoming merge window).

I believe it's fine from GPIO ACPI perspective (there shouldn't be conflict,
but if you wish you always may take this PR [1] to your tree (it's already in
GPIO tree pending v6.1), it may be considered as immutable tag.

[1]: https://lore.kernel.org/linux-gpio/Yym%2Fj+Y9MBOIhWtK@black.fi.intel.com/
Rafael J. Wysocki Sept. 30, 2022, 5:54 p.m. UTC | #8
On Fri, Sep 30, 2022 at 7:42 PM Andy Shevchenko
<andriy.shevchenko@linux.intel.com> wrote:
>
> On Fri, Sep 30, 2022 at 07:13:37PM +0200, Rafael J. Wysocki wrote:
> > On Fri, Sep 30, 2022 at 1:22 AM Dmitry Torokhov
> > <dmitry.torokhov@gmail.com> wrote:
>
> ...
>
> > I think that patches [5-8/13] from this series are significant
> > framework changes, so it would make sense to route them via the ACPI
> > tree.
> >
> > If this is fine with everybody, I will queue them up for merging into
> > 6.1 (probably in the second half of the upcoming merge window).
>
> I believe it's fine from GPIO ACPI perspective (there shouldn't be conflict,
> but if you wish you always may take this PR [1] to your tree (it's already in
> GPIO tree pending v6.1), it may be considered as immutable tag.
>
> [1]: https://lore.kernel.org/linux-gpio/Yym%2Fj+Y9MBOIhWtK@black.fi.intel.com/

Thanks for the pointer!
Dmitry Torokhov Sept. 30, 2022, 5:55 p.m. UTC | #9
On Fri, Sep 30, 2022 at 08:42:13PM +0300, Andy Shevchenko wrote:
> On Fri, Sep 30, 2022 at 07:13:37PM +0200, Rafael J. Wysocki wrote:
> > On Fri, Sep 30, 2022 at 1:22 AM Dmitry Torokhov
> > <dmitry.torokhov@gmail.com> wrote:
> 
> ...
> 
> > I think that patches [5-8/13] from this series are significant
> > framework changes, so it would make sense to route them via the ACPI
> > tree.
> > 
> > If this is fine with everybody, I will queue them up for merging into
> > 6.1 (probably in the second half of the upcoming merge window).
> 
> I believe it's fine from GPIO ACPI perspective (there shouldn't be conflict,
> but if you wish you always may take this PR [1] to your tree (it's already in
> GPIO tree pending v6.1), it may be considered as immutable tag.
> 
> [1]: https://lore.kernel.org/linux-gpio/Yym%2Fj+Y9MBOIhWtK@black.fi.intel.com/

Yeah, having an immutable branch hanging off 6.0-rcN would be awesome -
I could pull it and this would avoid any potential conflicts later.

Thanks.
Rafael J. Wysocki Oct. 15, 2022, 4:56 p.m. UTC | #10
On Fri, Sep 30, 2022 at 7:55 PM Dmitry Torokhov
<dmitry.torokhov@gmail.com> wrote:
>
> On Fri, Sep 30, 2022 at 08:42:13PM +0300, Andy Shevchenko wrote:
> > On Fri, Sep 30, 2022 at 07:13:37PM +0200, Rafael J. Wysocki wrote:
> > > On Fri, Sep 30, 2022 at 1:22 AM Dmitry Torokhov
> > > <dmitry.torokhov@gmail.com> wrote:
> >
> > ...
> >
> > > I think that patches [5-8/13] from this series are significant
> > > framework changes, so it would make sense to route them via the ACPI
> > > tree.
> > >
> > > If this is fine with everybody, I will queue them up for merging into
> > > 6.1 (probably in the second half of the upcoming merge window).
> >
> > I believe it's fine from GPIO ACPI perspective (there shouldn't be conflict,
> > but if you wish you always may take this PR [1] to your tree (it's already in
> > GPIO tree pending v6.1), it may be considered as immutable tag.
> >
> > [1]: https://lore.kernel.org/linux-gpio/Yym%2Fj+Y9MBOIhWtK@black.fi.intel.com/
>
> Yeah, having an immutable branch hanging off 6.0-rcN would be awesome -
> I could pull it and this would avoid any potential conflicts later.

This material is in the mainline now, but the branch is still there in
case you need it:

 git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm.git \
 acpi-wakeup

It won't be necessary any more after 6.1-rc1 is out, though, I suppose.
Raul Rangel Oct. 17, 2022, 2:53 p.m. UTC | #11
On Sat, Oct 15, 2022 at 10:56 AM Rafael J. Wysocki <rafael@kernel.org> wrote:
>
> On Fri, Sep 30, 2022 at 7:55 PM Dmitry Torokhov
> <dmitry.torokhov@gmail.com> wrote:
> >
> > On Fri, Sep 30, 2022 at 08:42:13PM +0300, Andy Shevchenko wrote:
> > > On Fri, Sep 30, 2022 at 07:13:37PM +0200, Rafael J. Wysocki wrote:
> > > > On Fri, Sep 30, 2022 at 1:22 AM Dmitry Torokhov
> > > > <dmitry.torokhov@gmail.com> wrote:
> > >
> > > ...
> > >
> > > > I think that patches [5-8/13] from this series are significant
> > > > framework changes, so it would make sense to route them via the ACPI
> > > > tree.
> > > >
> > > > If this is fine with everybody, I will queue them up for merging into
> > > > 6.1 (probably in the second half of the upcoming merge window).
> > >
> > > I believe it's fine from GPIO ACPI perspective (there shouldn't be conflict,
> > > but if you wish you always may take this PR [1] to your tree (it's already in
> > > GPIO tree pending v6.1), it may be considered as immutable tag.
> > >
> > > [1]: https://lore.kernel.org/linux-gpio/Yym%2Fj+Y9MBOIhWtK@black.fi.intel.com/
> >
> > Yeah, having an immutable branch hanging off 6.0-rcN would be awesome -
> > I could pull it and this would avoid any potential conflicts later.
>
> This material is in the mainline now, but the branch is still there in
> case you need it:
>
>  git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm.git \
>  acpi-wakeup
>
> It won't be necessary any more after 6.1-rc1 is out, though, I suppose.

Awesome, thanks for merging in the ACPI patches!
Raul Rangel Nov. 7, 2022, 6:36 p.m. UTC | #12
On Mon, Oct 17, 2022 at 8:53 AM Raul Rangel <rrangel@chromium.org> wrote:
>
> On Sat, Oct 15, 2022 at 10:56 AM Rafael J. Wysocki <rafael@kernel.org> wrote:
> >
> > On Fri, Sep 30, 2022 at 7:55 PM Dmitry Torokhov
> > <dmitry.torokhov@gmail.com> wrote:
> > >
> > > On Fri, Sep 30, 2022 at 08:42:13PM +0300, Andy Shevchenko wrote:
> > > > On Fri, Sep 30, 2022 at 07:13:37PM +0200, Rafael J. Wysocki wrote:
> > > > > On Fri, Sep 30, 2022 at 1:22 AM Dmitry Torokhov
> > > > > <dmitry.torokhov@gmail.com> wrote:
> > > >
> > > > ...
> > > >
> > > > > I think that patches [5-8/13] from this series are significant
> > > > > framework changes, so it would make sense to route them via the ACPI
> > > > > tree.
> > > > >
> > > > > If this is fine with everybody, I will queue them up for merging into
> > > > > 6.1 (probably in the second half of the upcoming merge window).
> > > >
> > > > I believe it's fine from GPIO ACPI perspective (there shouldn't be conflict,
> > > > but if you wish you always may take this PR [1] to your tree (it's already in
> > > > GPIO tree pending v6.1), it may be considered as immutable tag.
> > > >
> > > > [1]: https://lore.kernel.org/linux-gpio/Yym%2Fj+Y9MBOIhWtK@black.fi.intel.com/
> > >
> > > Yeah, having an immutable branch hanging off 6.0-rcN would be awesome -
> > > I could pull it and this would avoid any potential conflicts later.
> >
> > This material is in the mainline now, but the branch is still there in
> > case you need it:
> >
> >  git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm.git \
> >  acpi-wakeup
> >
> > It won't be necessary any more after 6.1-rc1 is out, though, I suppose.
>

>
> Awesome, thanks for merging in the ACPI patches!

Dmitry,
 What are the next steps to getting the I2C patches landed? Should I
push out a new series that's rebased on 6.1-rc1?
Dmitry Torokhov Nov. 22, 2022, 10:13 p.m. UTC | #13
On Mon, Nov 07, 2022 at 11:36:07AM -0700, Raul Rangel wrote:
> On Mon, Oct 17, 2022 at 8:53 AM Raul Rangel <rrangel@chromium.org> wrote:
> >
> > On Sat, Oct 15, 2022 at 10:56 AM Rafael J. Wysocki <rafael@kernel.org> wrote:
> > >
> > > On Fri, Sep 30, 2022 at 7:55 PM Dmitry Torokhov
> > > <dmitry.torokhov@gmail.com> wrote:
> > > >
> > > > On Fri, Sep 30, 2022 at 08:42:13PM +0300, Andy Shevchenko wrote:
> > > > > On Fri, Sep 30, 2022 at 07:13:37PM +0200, Rafael J. Wysocki wrote:
> > > > > > On Fri, Sep 30, 2022 at 1:22 AM Dmitry Torokhov
> > > > > > <dmitry.torokhov@gmail.com> wrote:
> > > > >
> > > > > ...
> > > > >
> > > > > > I think that patches [5-8/13] from this series are significant
> > > > > > framework changes, so it would make sense to route them via the ACPI
> > > > > > tree.
> > > > > >
> > > > > > If this is fine with everybody, I will queue them up for merging into
> > > > > > 6.1 (probably in the second half of the upcoming merge window).
> > > > >
> > > > > I believe it's fine from GPIO ACPI perspective (there shouldn't be conflict,
> > > > > but if you wish you always may take this PR [1] to your tree (it's already in
> > > > > GPIO tree pending v6.1), it may be considered as immutable tag.
> > > > >
> > > > > [1]: https://lore.kernel.org/linux-gpio/Yym%2Fj+Y9MBOIhWtK@black.fi.intel.com/
> > > >
> > > > Yeah, having an immutable branch hanging off 6.0-rcN would be awesome -
> > > > I could pull it and this would avoid any potential conflicts later.
> > >
> > > This material is in the mainline now, but the branch is still there in
> > > case you need it:
> > >
> > >  git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm.git \
> > >  acpi-wakeup
> > >
> > > It won't be necessary any more after 6.1-rc1 is out, though, I suppose.
> >
> 
> >
> > Awesome, thanks for merging in the ACPI patches!
> 
> Dmitry,
>  What are the next steps to getting the I2C patches landed? Should I
> push out a new series that's rebased on 6.1-rc1?

Everything should be applied now and will be in 6.2.

Thanks.
diff mbox series

Patch

diff --git a/drivers/acpi/irq.c b/drivers/acpi/irq.c
index dabe45eba055d1f..4bb5ab33a5ceb10 100644
--- a/drivers/acpi/irq.c
+++ b/drivers/acpi/irq.c
@@ -147,6 +147,7 @@  struct acpi_irq_parse_one_ctx {
  * @polarity: polarity attributes of hwirq
  * @polarity: polarity attributes of hwirq
  * @shareable: shareable attributes of hwirq
+ * @wake_capable: wake capable attribute of hwirq
  * @ctx: acpi_irq_parse_one_ctx updated by this function
  *
  * Description:
@@ -156,12 +157,13 @@  struct acpi_irq_parse_one_ctx {
 static inline void acpi_irq_parse_one_match(struct fwnode_handle *fwnode,
 					    u32 hwirq, u8 triggering,
 					    u8 polarity, u8 shareable,
+					    u8 wake_capable,
 					    struct acpi_irq_parse_one_ctx *ctx)
 {
 	if (!fwnode)
 		return;
 	ctx->rc = 0;
-	*ctx->res_flags = acpi_dev_irq_flags(triggering, polarity, shareable);
+	*ctx->res_flags = acpi_dev_irq_flags(triggering, polarity, shareable, wake_capable);
 	ctx->fwspec->fwnode = fwnode;
 	ctx->fwspec->param[0] = hwirq;
 	ctx->fwspec->param[1] = acpi_dev_get_irq_type(triggering, polarity);
@@ -204,7 +206,7 @@  static acpi_status acpi_irq_parse_one_cb(struct acpi_resource *ares,
 		fwnode = acpi_get_gsi_domain_id(irq->interrupts[ctx->index]);
 		acpi_irq_parse_one_match(fwnode, irq->interrupts[ctx->index],
 					 irq->triggering, irq->polarity,
-					 irq->shareable, ctx);
+					 irq->shareable, irq->wake_capable, ctx);
 		return AE_CTRL_TERMINATE;
 	case ACPI_RESOURCE_TYPE_EXTENDED_IRQ:
 		eirq = &ares->data.extended_irq;
@@ -218,7 +220,7 @@  static acpi_status acpi_irq_parse_one_cb(struct acpi_resource *ares,
 						      eirq->interrupts[ctx->index]);
 		acpi_irq_parse_one_match(fwnode, eirq->interrupts[ctx->index],
 					 eirq->triggering, eirq->polarity,
-					 eirq->shareable, ctx);
+					 eirq->shareable, eirq->wake_capable, ctx);
 		return AE_CTRL_TERMINATE;
 	}
 
diff --git a/drivers/acpi/resource.c b/drivers/acpi/resource.c
index 510cdec375c4d88..81733369f4c1de0 100644
--- a/drivers/acpi/resource.c
+++ b/drivers/acpi/resource.c
@@ -336,8 +336,9 @@  EXPORT_SYMBOL_GPL(acpi_dev_resource_ext_address_space);
  * @triggering: Triggering type as provided by ACPI.
  * @polarity: Interrupt polarity as provided by ACPI.
  * @shareable: Whether or not the interrupt is shareable.
+ * @wake_capable: Wake capability as provided by ACPI.
  */
-unsigned long acpi_dev_irq_flags(u8 triggering, u8 polarity, u8 shareable)
+unsigned long acpi_dev_irq_flags(u8 triggering, u8 polarity, u8 shareable, u8 wake_capable)
 {
 	unsigned long flags;
 
@@ -351,6 +352,9 @@  unsigned long acpi_dev_irq_flags(u8 triggering, u8 polarity, u8 shareable)
 	if (shareable == ACPI_SHARED)
 		flags |= IORESOURCE_IRQ_SHAREABLE;
 
+	if (wake_capable == ACPI_WAKE_CAPABLE)
+		flags |= IORESOURCE_IRQ_WAKECAPABLE;
+
 	return flags | IORESOURCE_IRQ;
 }
 EXPORT_SYMBOL_GPL(acpi_dev_irq_flags);
@@ -442,7 +446,7 @@  static bool acpi_dev_irq_override(u32 gsi, u8 triggering, u8 polarity,
 
 static void acpi_dev_get_irqresource(struct resource *res, u32 gsi,
 				     u8 triggering, u8 polarity, u8 shareable,
-				     bool check_override)
+				     u8 wake_capable, bool check_override)
 {
 	int irq, p, t;
 
@@ -475,7 +479,7 @@  static void acpi_dev_get_irqresource(struct resource *res, u32 gsi,
 		}
 	}
 
-	res->flags = acpi_dev_irq_flags(triggering, polarity, shareable);
+	res->flags = acpi_dev_irq_flags(triggering, polarity, shareable, wake_capable);
 	irq = acpi_register_gsi(NULL, gsi, triggering, polarity);
 	if (irq >= 0) {
 		res->start = irq;
@@ -523,7 +527,8 @@  bool acpi_dev_resource_interrupt(struct acpi_resource *ares, int index,
 		}
 		acpi_dev_get_irqresource(res, irq->interrupts[index],
 					 irq->triggering, irq->polarity,
-					 irq->shareable, true);
+					 irq->shareable, irq->wake_capable,
+					 true);
 		break;
 	case ACPI_RESOURCE_TYPE_EXTENDED_IRQ:
 		ext_irq = &ares->data.extended_irq;
@@ -534,7 +539,8 @@  bool acpi_dev_resource_interrupt(struct acpi_resource *ares, int index,
 		if (is_gsi(ext_irq))
 			acpi_dev_get_irqresource(res, ext_irq->interrupts[index],
 					 ext_irq->triggering, ext_irq->polarity,
-					 ext_irq->shareable, false);
+					 ext_irq->shareable, ext_irq->wake_capable,
+					 false);
 		else
 			irqresource_disabled(res, 0);
 		break;
diff --git a/drivers/pnp/pnpacpi/rsparser.c b/drivers/pnp/pnpacpi/rsparser.c
index da78dc77aed32e4..4f05f610391b006 100644
--- a/drivers/pnp/pnpacpi/rsparser.c
+++ b/drivers/pnp/pnpacpi/rsparser.c
@@ -206,7 +206,8 @@  static acpi_status pnpacpi_allocated_resource(struct acpi_resource *res,
 		if (i >= 0) {
 			flags = acpi_dev_irq_flags(gpio->triggering,
 						   gpio->polarity,
-						   gpio->shareable);
+						   gpio->shareable,
+						   gpio->wake_capable);
 		} else {
 			flags = IORESOURCE_DISABLED;
 		}
@@ -315,7 +316,7 @@  static __init void pnpacpi_parse_irq_option(struct pnp_dev *dev,
 		if (p->interrupts[i])
 			__set_bit(p->interrupts[i], map.bits);
 
-	flags = acpi_dev_irq_flags(p->triggering, p->polarity, p->shareable);
+	flags = acpi_dev_irq_flags(p->triggering, p->polarity, p->shareable, p->wake_capable);
 	pnp_register_irq_resource(dev, option_flags, &map, flags);
 }
 
@@ -339,7 +340,7 @@  static __init void pnpacpi_parse_ext_irq_option(struct pnp_dev *dev,
 		}
 	}
 
-	flags = acpi_dev_irq_flags(p->triggering, p->polarity, p->shareable);
+	flags = acpi_dev_irq_flags(p->triggering, p->polarity, p->shareable, p->wake_capable);
 	pnp_register_irq_resource(dev, option_flags, &map, flags);
 }
 
diff --git a/include/linux/acpi.h b/include/linux/acpi.h
index cd7371a5f2839bd..ea2efbdbeee5116 100644
--- a/include/linux/acpi.h
+++ b/include/linux/acpi.h
@@ -495,7 +495,7 @@  bool acpi_dev_resource_address_space(struct acpi_resource *ares,
 				     struct resource_win *win);
 bool acpi_dev_resource_ext_address_space(struct acpi_resource *ares,
 					 struct resource_win *win);
-unsigned long acpi_dev_irq_flags(u8 triggering, u8 polarity, u8 shareable);
+unsigned long acpi_dev_irq_flags(u8 triggering, u8 polarity, u8 shareable, u8 wake_capable);
 unsigned int acpi_dev_get_irq_type(int triggering, int polarity);
 bool acpi_dev_resource_interrupt(struct acpi_resource *ares, int index,
 				 struct resource *res);
diff --git a/include/linux/ioport.h b/include/linux/ioport.h
index 616b683563a9704..3baeea4d903bfd1 100644
--- a/include/linux/ioport.h
+++ b/include/linux/ioport.h
@@ -79,7 +79,8 @@  struct resource {
 #define IORESOURCE_IRQ_HIGHLEVEL	(1<<2)
 #define IORESOURCE_IRQ_LOWLEVEL		(1<<3)
 #define IORESOURCE_IRQ_SHAREABLE	(1<<4)
-#define IORESOURCE_IRQ_OPTIONAL 	(1<<5)
+#define IORESOURCE_IRQ_OPTIONAL		(1<<5)
+#define IORESOURCE_IRQ_WAKECAPABLE	(1<<6)
 
 /* PnP DMA specific bits (IORESOURCE_BITS) */
 #define IORESOURCE_DMA_TYPE_MASK	(3<<0)