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(-)
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-googOn 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
>
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. >
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. > >
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. > > >
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. -- Dmitry
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).
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/ -- With Best Regards, Andy Shevchenko
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. -- Dmitry
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.
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!
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?
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. -- Dmitry
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!
© 2016 - 2026 Red Hat, Inc.