| Message ID | 1352218863-2037-1-git-send-email-linus.walleij@stericsson.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
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?
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
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 */