[v2,3/7] gpiolib: Introduce ->add_pin_ranges() callback
diff mbox series

Message ID 20191105203557.78562-4-andriy.shevchenko@linux.intel.com
State New
Headers show
Series
  • gpiolib: fix GPIO <-> pin mapping registration
Related show

Commit Message

andriy.shevchenko@linux.intel.com Nov. 5, 2019, 8:35 p.m. UTC
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(+)

Comments

Mika Westerberg Nov. 6, 2019, 1:51 p.m. UTC | #1
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>
Linus Walleij Nov. 13, 2019, 9:46 a.m. UTC | #2
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
andriy.shevchenko@linux.intel.com Nov. 13, 2019, 1:22 p.m. UTC | #3
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.
Linus Walleij Nov. 13, 2019, 5:25 p.m. UTC | #4
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
andriy.shevchenko@linux.intel.com Nov. 13, 2019, 5:47 p.m. UTC | #5
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.

Patch
diff mbox series

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;