| Message ID | 20191105203557.78562-4-andriy.shevchenko@linux.intel.com |
|---|---|
| State | New |
| Headers | show |
| Series | gpiolib: fix GPIO <-> pin mapping registration | expand |
On Tue, Nov 05, 2019 at 10:35:53PM +0200, Andy Shevchenko wrote: > When IRQ chip is being added by GPIO library, the ACPI based platform expects > GPIO <-> pin mapping ranges to be initialized in order to correctly initialize > ACPI event mechanism on affected platforms. Unfortunately this step is missed. > > Introduce ->add_pin_ranges() callback to fill the above mentioned gap. > > Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com>
On Tue, Nov 5, 2019 at 9:36 PM Andy Shevchenko <andriy.shevchenko@linux.intel.com> wrote: > When IRQ chip is being added by GPIO library, the ACPI based platform expects > GPIO <-> pin mapping ranges to be initialized in order to correctly initialize > ACPI event mechanism on affected platforms. Unfortunately this step is missed. > > Introduce ->add_pin_ranges() callback to fill the above mentioned gap. > > Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> I also think DT drivers can benefit from this. I expect this in a big pull request :) Yours, Linus Walleij
On Wed, Nov 13, 2019 at 10:46:24AM +0100, Linus Walleij wrote: > On Tue, Nov 5, 2019 at 9:36 PM Andy Shevchenko > <andriy.shevchenko@linux.intel.com> wrote: > > > When IRQ chip is being added by GPIO library, the ACPI based platform expects > > GPIO <-> pin mapping ranges to be initialized in order to correctly initialize > > ACPI event mechanism on affected platforms. Unfortunately this step is missed. > > > > Introduce ->add_pin_ranges() callback to fill the above mentioned gap. > > > > Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> > > Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Thank you. > I also think DT drivers can benefit from this. > I expect this in a big pull request :) You mean GPIO library one? Pin control is the other one and it seems that part of Intel pin control (despite Lynxpoint case) will be split between v5.5 and v5.6 due to this very patch as dependency.
On Wed, Nov 13, 2019 at 2:22 PM Andy Shevchenko <andriy.shevchenko@linux.intel.com> wrote: > On Wed, Nov 13, 2019 at 10:46:24AM +0100, Linus Walleij wrote: > > On Tue, Nov 5, 2019 at 9:36 PM Andy Shevchenko > > <andriy.shevchenko@linux.intel.com> wrote: > > > > > When IRQ chip is being added by GPIO library, the ACPI based platform expects > > > GPIO <-> pin mapping ranges to be initialized in order to correctly initialize > > > ACPI event mechanism on affected platforms. Unfortunately this step is missed. > > > > > > Introduce ->add_pin_ranges() callback to fill the above mentioned gap. > > > > > > Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> > > > > Reviewed-by: Linus Walleij <linus.walleij@linaro.org> > > Thank you. > > > I also think DT drivers can benefit from this. > > I expect this in a big pull request :) > > You mean GPIO library one? Pin control is the other one and it seems that part > of Intel pin control (despite Lynxpoint case) will be split between v5.5 and > v5.6 due to this very patch as dependency. No need for that I think, we can just create some shared baseline and pull that into both trees? (If it doesn't get too messy...) Yours, Linus Walleij
On Wed, Nov 13, 2019 at 06:25:25PM +0100, Linus Walleij wrote: > On Wed, Nov 13, 2019 at 2:22 PM Andy Shevchenko > <andriy.shevchenko@linux.intel.com> wrote: > > On Wed, Nov 13, 2019 at 10:46:24AM +0100, Linus Walleij wrote: > > > On Tue, Nov 5, 2019 at 9:36 PM Andy Shevchenko > > > <andriy.shevchenko@linux.intel.com> wrote: > > > > > > > When IRQ chip is being added by GPIO library, the ACPI based platform expects > > > > GPIO <-> pin mapping ranges to be initialized in order to correctly initialize > > > > ACPI event mechanism on affected platforms. Unfortunately this step is missed. > > > > > > > > Introduce ->add_pin_ranges() callback to fill the above mentioned gap. > > > > > > > > Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> > > > > > > Reviewed-by: Linus Walleij <linus.walleij@linaro.org> > > > > Thank you. > > > > > I also think DT drivers can benefit from this. > > > I expect this in a big pull request :) > > > > You mean GPIO library one? Pin control is the other one and it seems that part > > of Intel pin control (despite Lynxpoint case) will be split between v5.5 and > > v5.6 due to this very patch as dependency. > > No need for that I think, we can just create some shared baseline > and pull that into both trees? (If it doesn't get too messy...) Anyway, I sent two PRs, and looking forward for them being accepted. Then we can continue based on updated repositories.
diff --git a/drivers/gpio/gpiolib.c b/drivers/gpio/gpiolib.c index aaf9c0a74c38..f888e46f0e93 100644 --- a/drivers/gpio/gpiolib.c +++ b/drivers/gpio/gpiolib.c @@ -390,6 +390,14 @@ static void gpiochip_free_valid_mask(struct gpio_chip *gpiochip) gpiochip->valid_mask = NULL; } +static int gpiochip_add_pin_ranges(struct gpio_chip *gc) +{ + if (gc->add_pin_ranges) + return gc->add_pin_ranges(gc); + + return 0; +} + bool gpiochip_line_is_valid(const struct gpio_chip *gpiochip, unsigned int offset) { @@ -1407,6 +1415,10 @@ int gpiochip_add_data_with_key(struct gpio_chip *chip, void *data, } } + ret = gpiochip_add_pin_ranges(chip); + if (ret) + goto err_remove_of_chip; + acpi_gpiochip_add(chip); machine_gpiochip_add(chip); diff --git a/include/linux/gpio/driver.h b/include/linux/gpio/driver.h index fd860c553ff4..424d03770b26 100644 --- a/include/linux/gpio/driver.h +++ b/include/linux/gpio/driver.h @@ -287,6 +287,9 @@ struct gpio_irq_chip { * state (such as pullup/pulldown configuration). * @init_valid_mask: optional routine to initialize @valid_mask, to be used if * not all GPIOs are valid. + * @add_pin_ranges: optional routine to initialize pin ranges, to be used when + * requires special mapping of the pins that provides GPIO functionality. + * It is called after adding GPIO chip and before adding IRQ chip. * @base: identifies the first GPIO number handled by this chip; * or, if negative during registration, requests dynamic ID allocation. * DEPRECATION: providing anything non-negative and nailing the base @@ -377,6 +380,8 @@ struct gpio_chip { unsigned long *valid_mask, unsigned int ngpios); + int (*add_pin_ranges)(struct gpio_chip *chip); + int base; u16 ngpio; const char *const *names;
When IRQ chip is being added by GPIO library, the ACPI based platform expects GPIO <-> pin mapping ranges to be initialized in order to correctly initialize ACPI event mechanism on affected platforms. Unfortunately this step is missed. Introduce ->add_pin_ranges() callback to fill the above mentioned gap. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> --- drivers/gpio/gpiolib.c | 12 ++++++++++++ include/linux/gpio/driver.h | 5 +++++ 2 files changed, 17 insertions(+)