[PATCH] gpiolib: iron out include ladder mistakes

[PATCH] gpiolib: iron out include ladder mistakes

[Linus Walleij]

From: Linus Walleij <linus.walleij@linaro.org>

The <*/gpio.h> includes are updated again: now we need to account
for the problem introduced by commit:
595679a8038584df7b9398bf34f61db3c038bfea
"gpiolib: fix up function prototypes etc"

Actually we need static inlines in include/asm-generic/gpio.h
as well since we may have GPIOLIB but not PINCTRL.

And we need to keep the static inlines in <linux/gpio.h>
but here for the !CONFIG_GENERIC_GPIO case, and then we
may as well throw in a few warnings like the other
prototypes there, if someone would have the bad taste
of compiling without GENERIC_GPIO even.

Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
---
 include/asm-generic/gpio.h | 13 +++++++++++++
 include/linux/gpio.h       |  7 +++----
 2 files changed, 16 insertions(+), 4 deletions(-)

diff --git a/include/asm-generic/gpio.h b/include/asm-generic/gpio.h
index 50d995e..b546edb 100644
--- a/include/asm-generic/gpio.h
+++ b/include/asm-generic/gpio.h
@@ -67,6 +67,19 @@ int gpiochip_add_pin_range(struct gpio_chip *chip, const char *pinctl_name,
 			   unsigned int pin_base, unsigned int npins);
 void gpiochip_remove_pin_ranges(struct gpio_chip *chip);
 
+#else
+
+static inline int
+gpiochip_add_pin_range(struct gpio_chip *chip, const char *pinctl_name,
+		       unsigned int pin_base, unsigned int npins)
+{
+}
+
+static inline void
+gpiochip_remove_pin_ranges(struct gpio_chip *chip)
+{
+}
+
 #endif
 
 /**
diff --git a/include/linux/gpio.h b/include/linux/gpio.h
index 81bbfe5..7ba2762 100644
--- a/include/linux/gpio.h
+++ b/include/linux/gpio.h
@@ -231,21 +231,20 @@ static inline int irq_to_gpio(unsigned irq)
 	return -EINVAL;
 }
 
-#ifdef CONFIG_PINCTRL
-
 static inline int
 gpiochip_add_pin_range(struct gpio_chip *chip, const char *pinctl_name,
 		       unsigned int pin_base, unsigned int npins)
 {
+	WARN_ON(1);
+	return -EINVAL;
 }
 
 static inline void
 gpiochip_remove_pin_ranges(struct gpio_chip *chip)
 {
+	WARN_ON(1);
 }
 
-#endif /* CONFIG_PINCTRL */
-
 #endif /* ! CONFIG_GENERIC_GPIO */
 
 #endif /* __LINUX_GPIO_H */
-- 
1.7.11.3

[PATCH] gpiolib: iron out include ladder mistakes

[Stephen Warren]

On 11/06/2012 09:21 AM, Linus Walleij wrote:
> From: Linus Walleij <linus.walleij@linaro.org>
> 
> The <*/gpio.h> includes are updated again: now we need to account
> for the problem introduced by commit:
> 595679a8038584df7b9398bf34f61db3c038bfea
> "gpiolib: fix up function prototypes etc"
> 
> Actually we need static inlines in include/asm-generic/gpio.h
> as well since we may have GPIOLIB but not PINCTRL.
> 
> And we need to keep the static inlines in <linux/gpio.h>
> but here for the !CONFIG_GENERIC_GPIO case, and then we
> may as well throw in a few warnings like the other
> prototypes there, if someone would have the bad taste
> of compiling without GENERIC_GPIO even.

Hmm. Is there way to avoid the duplication of the dummy implementations?
Having a prototype and a truly dummy implementation in one place, but a
WARNing/failing dummy implementation elsewhere, seems like it'll cause
issues.

Does this patch mean the previous series causes "git bisect" failures?

[PATCH] gpiolib: iron out include ladder mistakes

[Linus Walleij]

On Tue, Nov 6, 2012 at 10:40 PM, Stephen Warren <swarren@wwwdotorg.org> wrote:
> On 11/06/2012 09:21 AM, Linus Walleij wrote:

>> And we need to keep the static inlines in <linux/gpio.h>
>> but here for the !CONFIG_GENERIC_GPIO case, and then we
>> may as well throw in a few warnings like the other
>> prototypes there, if someone would have the bad taste
>> of compiling without GENERIC_GPIO even.
>
> Hmm. Is there way to avoid the duplication of the dummy implementations?
> Having a prototype and a truly dummy implementation in one place, but a
> WARNing/failing dummy implementation elsewhere, seems like it'll cause
> issues.

Yeah :-/

This is not exactly elegant and is some side effect of the split
between CONFIG_GENERIC_GPIO and CONFIG_GPIOLIB,
the real fix is to get rid of all GENERIC_GPIO implementations
in the kernel and switch everyone over to GPIOLIB.

Not that easy though :-( can't think of any nice fix.

> Does this patch mean the previous series causes "git bisect" failures?

Yeah once I have something that doesn't break x86 I might
just squash collapse all of this into the gpioranges patch.

Yours,
Linus Walleij