| Message ID | 20210304201253.14652-1-andriy.shevchenko@linux.intel.com |
|---|---|
| Headers | show |
| Series | gpiolib: switch to fwnode in the core | expand |
On Thu, Mar 4, 2021 at 9:13 PM Andy Shevchenko <andriy.shevchenko@linux.intel.com> wrote: > > Linus Walleij pointed out that ird_domain_add_simple() gained > additional functionality and can't be anymore replaced with > a simple conditional. In preparation to upgrade GPIO library > to use fwnode, introduce irq_domain_create_simple() API which is > functional equivalent to the existing irq_domain_add_simple(), > but takes a pointer to the struct fwnode_handle as a parameter. > > While at it, amend documentation to mention irq_domain_create_*() > functions where it makes sense. > > Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> This requires an ACK from Marc or Thomas so I can apply it. > --- > Documentation/core-api/irq/irq-domain.rst | 22 ++++++++++++---------- > include/linux/irqdomain.h | 19 ++++++++++++++----- > kernel/irq/irqdomain.c | 20 ++++++++++---------- > 3 files changed, 36 insertions(+), 25 deletions(-) > > diff --git a/Documentation/core-api/irq/irq-domain.rst b/Documentation/core-api/irq/irq-domain.rst > index a77c24c27f7b..8214e215a8bf 100644 > --- a/Documentation/core-api/irq/irq-domain.rst > +++ b/Documentation/core-api/irq/irq-domain.rst > @@ -42,10 +42,10 @@ irq_domain usage > ================ > > An interrupt controller driver creates and registers an irq_domain by > -calling one of the irq_domain_add_*() functions (each mapping method > -has a different allocator function, more on that later). The function > -will return a pointer to the irq_domain on success. The caller must > -provide the allocator function with an irq_domain_ops structure. > +calling one of the irq_domain_add_*() or irq_domain_create_*() functions > +(each mapping method has a different allocator function, more on that later). > +The function will return a pointer to the irq_domain on success. The caller > +must provide the allocator function with an irq_domain_ops structure. > > In most cases, the irq_domain will begin empty without any mappings > between hwirq and IRQ numbers. Mappings are added to the irq_domain > @@ -147,6 +147,7 @@ Legacy > irq_domain_add_simple() > irq_domain_add_legacy() > irq_domain_add_legacy_isa() > + irq_domain_create_simple() > irq_domain_create_legacy() > > The Legacy mapping is a special case for drivers that already have a > @@ -169,13 +170,13 @@ supported. For example, ISA controllers would use the legacy map for > mapping Linux IRQs 0-15 so that existing ISA drivers get the correct IRQ > numbers. > > -Most users of legacy mappings should use irq_domain_add_simple() which > -will use a legacy domain only if an IRQ range is supplied by the > -system and will otherwise use a linear domain mapping. The semantics > -of this call are such that if an IRQ range is specified then > +Most users of legacy mappings should use irq_domain_add_simple() or > +irq_domain_create_simple() which will use a legacy domain only if an IRQ range > +is supplied by the system and will otherwise use a linear domain mapping. > +The semantics of this call are such that if an IRQ range is specified then > descriptors will be allocated on-the-fly for it, and if no range is > -specified it will fall through to irq_domain_add_linear() which means > -*no* irq descriptors will be allocated. > +specified it will fall through to irq_domain_add_linear() or > +irq_domain_create_linear() which means *no* irq descriptors will be allocated. > > A typical use case for simple domains is where an irqchip provider > is supporting both dynamic and static IRQ assignments. > @@ -186,6 +187,7 @@ that the driver using the simple domain call irq_create_mapping() > before any irq_find_mapping() since the latter will actually work > for the static IRQ assignment case. > > +irq_domain_add_simple() and irq_domain_create_simple() as well as > irq_domain_add_legacy() and irq_domain_create_legacy() are functionally > equivalent, except for the first argument is different - the former > accepts an Open Firmware specific 'struct device_node', while the latter > diff --git a/include/linux/irqdomain.h b/include/linux/irqdomain.h > index 42d196805f58..6e78f5909723 100644 > --- a/include/linux/irqdomain.h > +++ b/include/linux/irqdomain.h > @@ -260,11 +260,11 @@ struct irq_domain *__irq_domain_add(struct fwnode_handle *fwnode, int size, > irq_hw_number_t hwirq_max, int direct_max, > const struct irq_domain_ops *ops, > void *host_data); > -struct irq_domain *irq_domain_add_simple(struct device_node *of_node, > - unsigned int size, > - unsigned int first_irq, > - const struct irq_domain_ops *ops, > - void *host_data); > +struct irq_domain *irq_domain_create_simple(struct fwnode_handle *fwnode, > + unsigned int size, > + unsigned int first_irq, > + const struct irq_domain_ops *ops, > + void *host_data); > struct irq_domain *irq_domain_add_legacy(struct device_node *of_node, > unsigned int size, > unsigned int first_irq, > @@ -329,6 +329,15 @@ static inline struct irq_domain *irq_find_host(struct device_node *node) > return d; > } > > +static inline struct irq_domain *irq_domain_add_simple(struct device_node *of_node, > + unsigned int size, > + unsigned int first_irq, > + const struct irq_domain_ops *ops, > + void *host_data) > +{ > + return irq_domain_create_simple(of_node_to_fwnode(of_node), size, first_irq, ops, host_data); > +} > + > /** > * irq_domain_add_linear() - Allocate and register a linear revmap irq_domain. > * @of_node: pointer to interrupt controller's device tree node. > diff --git a/kernel/irq/irqdomain.c b/kernel/irq/irqdomain.c > index 288151393a06..a7f4028971e4 100644 > --- a/kernel/irq/irqdomain.c > +++ b/kernel/irq/irqdomain.c > @@ -295,8 +295,8 @@ void irq_domain_update_bus_token(struct irq_domain *domain, > EXPORT_SYMBOL_GPL(irq_domain_update_bus_token); > > /** > - * irq_domain_add_simple() - Register an irq_domain and optionally map a range of irqs > - * @of_node: pointer to interrupt controller's device tree node. > + * irq_domain_create_simple() - Register an irq_domain and optionally map a range of irqs > + * @fwnode: firmware node for the interrupt controller > * @size: total number of irqs in mapping > * @first_irq: first number of irq block assigned to the domain, > * pass zero to assign irqs on-the-fly. If first_irq is non-zero, then > @@ -312,15 +312,15 @@ EXPORT_SYMBOL_GPL(irq_domain_update_bus_token); > * irqs get mapped dynamically on the fly. However, if the controller requires > * static virq assignments (non-DT boot) then it will set that up correctly. > */ > -struct irq_domain *irq_domain_add_simple(struct device_node *of_node, > - unsigned int size, > - unsigned int first_irq, > - const struct irq_domain_ops *ops, > - void *host_data) > +struct irq_domain *irq_domain_create_simple(struct fwnode_handle *fwnode, > + unsigned int size, > + unsigned int first_irq, > + const struct irq_domain_ops *ops, > + void *host_data) > { > struct irq_domain *domain; > > - domain = __irq_domain_add(of_node_to_fwnode(of_node), size, size, 0, ops, host_data); > + domain = __irq_domain_add(fwnode, size, size, 0, ops, host_data); > if (!domain) > return NULL; > > @@ -328,7 +328,7 @@ struct irq_domain *irq_domain_add_simple(struct device_node *of_node, > if (IS_ENABLED(CONFIG_SPARSE_IRQ)) { > /* attempt to allocated irq_descs */ > int rc = irq_alloc_descs(first_irq, first_irq, size, > - of_node_to_nid(of_node)); > + of_node_to_nid(to_of_node(fwnode))); > if (rc < 0) > pr_info("Cannot allocate irq_descs @ IRQ%d, assuming pre-allocated\n", > first_irq); > @@ -338,7 +338,7 @@ struct irq_domain *irq_domain_add_simple(struct device_node *of_node, > > return domain; > } > -EXPORT_SYMBOL_GPL(irq_domain_add_simple); > +EXPORT_SYMBOL_GPL(irq_domain_create_simple); > > /** > * irq_domain_add_legacy() - Allocate and register a legacy revmap irq_domain. > -- > 2.30.1 >
On Thu, 04 Mar 2021 20:12:49 +0000, Andy Shevchenko <andriy.shevchenko@linux.intel.com> wrote: > > Linus Walleij pointed out that ird_domain_add_simple() gained > additional functionality and can't be anymore replaced with > a simple conditional. In preparation to upgrade GPIO library > to use fwnode, introduce irq_domain_create_simple() API which is > functional equivalent to the existing irq_domain_add_simple(), > but takes a pointer to the struct fwnode_handle as a parameter. > > While at it, amend documentation to mention irq_domain_create_*() > functions where it makes sense. > > Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> > --- > Documentation/core-api/irq/irq-domain.rst | 22 ++++++++++++---------- > include/linux/irqdomain.h | 19 ++++++++++++++----- > kernel/irq/irqdomain.c | 20 ++++++++++---------- > 3 files changed, 36 insertions(+), 25 deletions(-) Acked-by: Marc Zyngier <maz@kernel.org> Thanks, M.
On Thu, Mar 4, 2021 at 9:13 PM Andy Shevchenko <andriy.shevchenko@linux.intel.com> wrote: > > GPIO library uses of_node and fwnode in the core in non-unified way. > The series cleans this up and improves IRQ domain creation for non-OF cases > where currently the names of the domain are 'unknown'. > > This has been tested on Intel Galileo Gen 2. > > In v3: > - fix subtle bug in gpiod_count > - make irq_domain_add_simple() static inline (Marc) > > In v2: > - added a new patch due to functionality in irq_comain_add_simple() (Linus) > - tagged patches 2-4 (Linus) > - Cc'ed to Rafael > > Andy Shevchenko (5): > irqdomain: Introduce irq_domain_create_simple() API > gpiolib: Unify the checks on fwnode type > gpiolib: Move of_node operations to gpiolib-of and correct fwnode use > gpiolib: Introduce acpi_gpio_dev_init() and call it from core > gpiolib: Reuse device's fwnode to create IRQ domain [1-4/5] applied as 5.13 material and I have a minor comment regarding the last patch (will send separately). Thanks!
On Mon, Mar 8, 2021 at 7:22 PM Rafael J. Wysocki <rafael@kernel.org> wrote: > > On Thu, Mar 4, 2021 at 9:13 PM Andy Shevchenko > <andriy.shevchenko@linux.intel.com> wrote: > > > > GPIO library uses of_node and fwnode in the core in non-unified way. > > The series cleans this up and improves IRQ domain creation for non-OF cases > > where currently the names of the domain are 'unknown'. > > > > This has been tested on Intel Galileo Gen 2. > > > > In v3: > > - fix subtle bug in gpiod_count > > - make irq_domain_add_simple() static inline (Marc) > > > > In v2: > > - added a new patch due to functionality in irq_comain_add_simple() (Linus) > > - tagged patches 2-4 (Linus) > > - Cc'ed to Rafael > > > > Andy Shevchenko (5): > > irqdomain: Introduce irq_domain_create_simple() API > > gpiolib: Unify the checks on fwnode type > > gpiolib: Move of_node operations to gpiolib-of and correct fwnode use > > gpiolib: Introduce acpi_gpio_dev_init() and call it from core > > gpiolib: Reuse device's fwnode to create IRQ domain > > [1-4/5] applied as 5.13 material and I have a minor comment regarding > the last patch (will send separately). > > Thanks! Hi Rafael! AFAICT this should go through the GPIO tree as usual. Any reason for you to pick these patches this time? Bartosz
On Mon, Mar 8, 2021 at 8:23 PM Bartosz Golaszewski <bgolaszewski@baylibre.com> wrote: > > On Mon, Mar 8, 2021 at 7:22 PM Rafael J. Wysocki <rafael@kernel.org> wrote: > > > > On Thu, Mar 4, 2021 at 9:13 PM Andy Shevchenko > > <andriy.shevchenko@linux.intel.com> wrote: > > > > > > GPIO library uses of_node and fwnode in the core in non-unified way. > > > The series cleans this up and improves IRQ domain creation for non-OF cases > > > where currently the names of the domain are 'unknown'. > > > > > > This has been tested on Intel Galileo Gen 2. > > > > > > In v3: > > > - fix subtle bug in gpiod_count > > > - make irq_domain_add_simple() static inline (Marc) > > > > > > In v2: > > > - added a new patch due to functionality in irq_comain_add_simple() (Linus) > > > - tagged patches 2-4 (Linus) > > > - Cc'ed to Rafael > > > > > > Andy Shevchenko (5): > > > irqdomain: Introduce irq_domain_create_simple() API > > > gpiolib: Unify the checks on fwnode type > > > gpiolib: Move of_node operations to gpiolib-of and correct fwnode use > > > gpiolib: Introduce acpi_gpio_dev_init() and call it from core > > > gpiolib: Reuse device's fwnode to create IRQ domain > > > > [1-4/5] applied as 5.13 material and I have a minor comment regarding > > the last patch (will send separately). > > > > Thanks! > > Hi Rafael! > > AFAICT this should go through the GPIO tree as usual. Any reason for > you to pick these patches this time? My impression was that Andy wanted me to take them. However, if you'd rather take care of them yourself, there you go! I'll drop them now and assume that they will be routed through the GPIO tree. Thanks!
On Mon, Mar 8, 2021 at 8:26 PM Rafael J. Wysocki <rafael@kernel.org> wrote: > > On Mon, Mar 8, 2021 at 8:23 PM Bartosz Golaszewski > <bgolaszewski@baylibre.com> wrote: > > > > On Mon, Mar 8, 2021 at 7:22 PM Rafael J. Wysocki <rafael@kernel.org> wrote: > > > > > > On Thu, Mar 4, 2021 at 9:13 PM Andy Shevchenko > > > <andriy.shevchenko@linux.intel.com> wrote: > > > > > > > > GPIO library uses of_node and fwnode in the core in non-unified way. > > > > The series cleans this up and improves IRQ domain creation for non-OF cases > > > > where currently the names of the domain are 'unknown'. > > > > > > > > This has been tested on Intel Galileo Gen 2. > > > > > > > > In v3: > > > > - fix subtle bug in gpiod_count > > > > - make irq_domain_add_simple() static inline (Marc) > > > > > > > > In v2: > > > > - added a new patch due to functionality in irq_comain_add_simple() (Linus) > > > > - tagged patches 2-4 (Linus) > > > > - Cc'ed to Rafael > > > > > > > > Andy Shevchenko (5): > > > > irqdomain: Introduce irq_domain_create_simple() API > > > > gpiolib: Unify the checks on fwnode type > > > > gpiolib: Move of_node operations to gpiolib-of and correct fwnode use > > > > gpiolib: Introduce acpi_gpio_dev_init() and call it from core > > > > gpiolib: Reuse device's fwnode to create IRQ domain > > > > > > [1-4/5] applied as 5.13 material and I have a minor comment regarding > > > the last patch (will send separately). > > > > > > Thanks! > > > > Hi Rafael! > > > > AFAICT this should go through the GPIO tree as usual. Any reason for > > you to pick these patches this time? > > My impression was that Andy wanted me to take them. > > However, if you'd rather take care of them yourself, there you go! > > I'll drop them now and assume that they will be routed through the GPIO tree. > > Thanks! They touch a lot of core GPIO code and are likely to conflict if any other changes show up this release cycle. I'd rather take them through the usual channel. Thanks! Bartosz
On Mon, Mar 08, 2021 at 08:26:39PM +0100, Rafael J. Wysocki wrote: > On Mon, Mar 8, 2021 at 8:23 PM Bartosz Golaszewski > <bgolaszewski@baylibre.com> wrote: > > On Mon, Mar 8, 2021 at 7:22 PM Rafael J. Wysocki <rafael@kernel.org> wrote: > > > On Thu, Mar 4, 2021 at 9:13 PM Andy Shevchenko > > > <andriy.shevchenko@linux.intel.com> wrote: > > AFAICT this should go through the GPIO tree as usual. Any reason for > > you to pick these patches this time? > > My impression was that Andy wanted me to take them. Hmm... I guess the MAINTAINERS pointed to your name due to changes in GPIO ACPI library, but most of them indeed are GPIO core ones. Perhaps I have to clarify that in the cover letter. > However, if you'd rather take care of them yourself, there you go! > > I'll drop them now and assume that they will be routed through the GPIO tree. Anyway, thank you for the review, it is useful! -- With Best Regards, Andy Shevchenko
On Mon, Mar 08, 2021 at 08:29:27PM +0100, Bartosz Golaszewski wrote: > On Mon, Mar 8, 2021 at 8:26 PM Rafael J. Wysocki <rafael@kernel.org> wrote: > > On Mon, Mar 8, 2021 at 8:23 PM Bartosz Golaszewski > > <bgolaszewski@baylibre.com> wrote: ... > > My impression was that Andy wanted me to take them. > > > > However, if you'd rather take care of them yourself, there you go! > > > > I'll drop them now and assume that they will be routed through the GPIO tree. > > > > Thanks! > > They touch a lot of core GPIO code and are likely to conflict if any > other changes show up this release cycle. I'd rather take them through > the usual channel. Thanks! Since now we have v4 based on Rafael's bleeding-edge, what do you want me to do? Resend a v5 with all patches included? -- With Best Regards, Andy Shevchenko
On Mon, Mar 08, 2021 at 09:36:52PM +0200, Andy Shevchenko wrote: > On Mon, Mar 08, 2021 at 08:29:27PM +0100, Bartosz Golaszewski wrote: > > On Mon, Mar 8, 2021 at 8:26 PM Rafael J. Wysocki <rafael@kernel.org> wrote: > > > On Mon, Mar 8, 2021 at 8:23 PM Bartosz Golaszewski > > > <bgolaszewski@baylibre.com> wrote: > > ... > > > > My impression was that Andy wanted me to take them. > > > > > > However, if you'd rather take care of them yourself, there you go! > > > > > > I'll drop them now and assume that they will be routed through the GPIO tree. > > > > > > Thanks! > > > > They touch a lot of core GPIO code and are likely to conflict if any > > other changes show up this release cycle. I'd rather take them through > > the usual channel. Thanks! > > Since now we have v4 based on Rafael's bleeding-edge, what do you want me to > do? Resend a v5 with all patches included? I have decided to resend as usually it's better for maintainers. But it appears I was too quick to miss Rafael's review tag / comments. So, I will send v6 with those included.
On Mon, Mar 8, 2021 at 8:52 PM Andy Shevchenko <andriy.shevchenko@linux.intel.com> wrote: > > On Mon, Mar 08, 2021 at 09:36:52PM +0200, Andy Shevchenko wrote: > > On Mon, Mar 08, 2021 at 08:29:27PM +0100, Bartosz Golaszewski wrote: > > > On Mon, Mar 8, 2021 at 8:26 PM Rafael J. Wysocki <rafael@kernel.org> wrote: > > > > On Mon, Mar 8, 2021 at 8:23 PM Bartosz Golaszewski > > > > <bgolaszewski@baylibre.com> wrote: > > > > ... > > > > > > My impression was that Andy wanted me to take them. > > > > > > > > However, if you'd rather take care of them yourself, there you go! > > > > > > > > I'll drop them now and assume that they will be routed through the GPIO tree. > > > > > > > > Thanks! > > > > > > They touch a lot of core GPIO code and are likely to conflict if any > > > other changes show up this release cycle. I'd rather take them through > > > the usual channel. Thanks! > > > > Since now we have v4 based on Rafael's bleeding-edge, what do you want me to > > do? Resend a v5 with all patches included? > > I have decided to resend as usually it's better for maintainers. > > But it appears I was too quick to miss Rafael's review tag / comments. > > So, I will send v6 with those included. > > -- > With Best Regards, > Andy Shevchenko > > Does this series depend on patches already in Rafael's tree? If so, maybe Rafael can provide me with an immutable tag to merge in? Bartosz
On Tue, Mar 09, 2021 at 09:19:19AM +0100, Bartosz Golaszewski wrote: > On Mon, Mar 8, 2021 at 8:52 PM Andy Shevchenko > <andriy.shevchenko@linux.intel.com> wrote: > > On Mon, Mar 08, 2021 at 09:36:52PM +0200, Andy Shevchenko wrote: ... > > So, I will send v6 with those included. > > Does this series depend on patches already in Rafael's tree? If so, > maybe Rafael can provide me with an immutable tag to merge in? Not anymore since v5.12-rc2 has a necessary fix. In any case I have sent a v6. It should be clean to apply on top of your for-next. -- With Best Regards, Andy Shevchenko
On Thu, Mar 4, 2021 at 9:13 PM Andy Shevchenko <andriy.shevchenko@linux.intel.com> wrote: > Linus Walleij pointed out that ird_domain_add_simple() gained > additional functionality and can't be anymore replaced with > a simple conditional. In preparation to upgrade GPIO library > to use fwnode, introduce irq_domain_create_simple() API which is > functional equivalent to the existing irq_domain_add_simple(), > but takes a pointer to the struct fwnode_handle as a parameter. > > While at it, amend documentation to mention irq_domain_create_*() > functions where it makes sense. > > Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Yours, Linus Walleij
On Thu, Mar 11, 2021 at 12:15:29AM +0100, Linus Walleij wrote: > On Thu, Mar 4, 2021 at 9:13 PM Andy Shevchenko > <andriy.shevchenko@linux.intel.com> wrote: > > > Linus Walleij pointed out that ird_domain_add_simple() gained > > additional functionality and can't be anymore replaced with > > a simple conditional. In preparation to upgrade GPIO library > > to use fwnode, introduce irq_domain_create_simple() API which is > > functional equivalent to the existing irq_domain_add_simple(), > > but takes a pointer to the struct fwnode_handle as a parameter. > > > > While at it, amend documentation to mention irq_domain_create_*() > > functions where it makes sense. > > > > Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> > > Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Thanks! It's v6 now :-)