gpiolib: separation of pin concerns
The fact that of_gpiochip_add_pin_range() and
gpiochip_add_pin_range() share too much code is fragile and
will invariably mean that bugs need to be fixed in two places
instead of one.
So separate the concerns of gpiolib.c and gpiolib-of.c and
have the latter call the former as back-end. This is necessary
also when going forward with other device descriptions such
as ACPI.
This is done by:
- Adding a return code to gpiochip_add_pin_range() so we can
reliably check whether this succeeds.
- Get rid of the custom of_pinctrl_add_gpio_range() from
pinctrl. Instead create of_pinctrl_get() to just retrive the
pin controller per se from an OF node. This composite
function was just begging to be deleted, it was way to
purpose-specific.
- Use pinctrl_dev_get_name() to get the name of the retrieved
pin controller and use that to call back into the generic
gpiochip_add_pin_range().
Now the pin range is only allocated and tied to a pin
controller from the core implementation in gpiolib.c.
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
diff --git a/drivers/gpio/gpiolib.c b/drivers/gpio/gpiolib.c
index bcf9b99..c5f6500 100644
--- a/drivers/gpio/gpiolib.c
+++ b/drivers/gpio/gpiolib.c
@@ -1187,8 +1187,8 @@
#ifdef CONFIG_PINCTRL
-void gpiochip_add_pin_range(struct gpio_chip *chip, const char *pinctl_name,
- unsigned int pin_base, unsigned int npins)
+int gpiochip_add_pin_range(struct gpio_chip *chip, const char *pinctl_name,
+ unsigned int pin_base, unsigned int npins)
{
struct gpio_pin_range *pin_range;
@@ -1196,7 +1196,7 @@
if (!pin_range) {
pr_err("%s: GPIO chip: failed to allocate pin ranges\n",
chip->label);
- return;
+ return -ENOMEM;
}
pin_range->range.name = chip->label;
@@ -1207,6 +1207,8 @@
&pin_range->range);
list_add_tail(&pin_range->node, &chip->pin_ranges);
+
+ return 0;
}
EXPORT_SYMBOL_GPL(gpiochip_add_pin_range);