| Message ID | 20220929093200.v6.6.I8092e417a8152475d13d8d638eb4c5d8ea12ac7b@changeid |
|---|---|
| State | Accepted |
| Commit | 5ff811604f93bdd2650beed80b48c2ca16c6fba6 |
| Headers | show |
| Series | acpi: i2c: Use SharedAndWake and ExclusiveAndWake to enable wake irq | expand |
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 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.
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/
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.
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.
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)