| 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: > > 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!
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?
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.