user/sven/linux.git/include/linux/gpio, branch v3.17

gpio: move varargs hack outside #ifdef GPIOLIB

2014-09-02T08:09:43Z

commit 39b2bbe3d715cf5013b5c48695ccdd25bd3bf120 "gpio: add flags argument to gpiod_get*() functions" added a dynamic flags argument to all the GPIOD getter functions, however this did not cover the stubs so when people used gpiod stubs to compile out descriptor code, compilation failed. Solve this by: - Also rename all the stub functions __gpiod_* - Moving the vararg hack outside of #ifdef CONFIG_GPIOLIB so these will always be available. Reviewed-by: Alexandre Courbot Signed-off-by: Linus Walleij

gpio: move GPIOD flags outside #ifdef

2014-08-21T12:44:36Z

The GPIOD flags are defined inside the #ifdef CONFIG_GPIOLIB switch, making the gpiolib stubs fail if these flags are used by a consumer. This is not correct: the stubs should compile fine without GPIOLIB. Reported-by: Ulf Hansson Reviewed-by: Alexandre Courbot Signed-off-by: Linus Walleij

gpio: add missing includes in machine.h

2014-08-07T09:54:51Z

linux/types.h and linux/list.h should be included so the typed used in the header file are always properly declared. Reported-by: Stephen Rothwell Reported-by: Thierry Reding Signed-off-by: Alexandre Courbot Signed-off-by: Linus Walleij

gpio: add flags argument to gpiod_get*() functions

2014-07-28T10:28:05Z

The huge majority of GPIOs have their direction and initial value set right after being obtained by one of the gpiod_get() functions. The integer GPIO API had gpio_request_one() that took a convenience flags parameter allowing to specify an direction and value applied to the returned GPIO. This feature greatly simplifies client code and ensures errors are always handled properly. A similar feature has been requested for the gpiod API. Since setting the direction of a GPIO is so often the very next action done after obtaining its descriptor, we prefer to extend the existing functions instead of introducing new functions that would raise the number of gpiod getters to 16 (!). The drawback of this approach is that all gpiod clients need to be updated. To limit the pain, temporary macros are introduced that allow gpiod_get*() to be called with or without the extra flags argument. They will be removed once all consumer code has been updated. Signed-off-by: Alexandre Courbot Reviewed-by: Mark Brown Signed-off-by: Linus Walleij

gpio: split gpiod board registration into machine header

2014-07-28T10:23:35Z

As per example from the regulator subsystem: put all defines and functions related to registering board info for GPIO descriptors into a separate header. Cc: Andrew Victor Cc: Nicolas Ferre Cc: Jean-Christophe Plagniol-Villard Cc: Ralf Baechle Cc: Thierry Reding Acked-by: Stephen Warren Reviewed-by: Alexandre Courbot Signed-off-by: Linus Walleij

gpiolib: Export gpiochip_request_own_desc and gpiochip_free_own_desc

2014-07-24T08:25:00Z

Both functions were introduced to let gpio drivers request their own gpio pins. Without exporting the functions, this can however only be used by gpio drivers built into the kernel. Secondary impact is that the functions can not currently be used by platform initialization code associated with the gpio-pca953x driver. This code permits auto-export of gpio pins through platform data, but if this functionality is used, the module can no longer be unloaded due to the problem solved with the introduction of gpiochip_request_own_desc and gpiochip_free_own_desc. Export both function so they can be used from modules and from platform initialization code. Reviewed-by: Alexandre Courbot Reviewed-by: Mika Westerberg Signed-off-by: Guenter Roeck Signed-off-by: Linus Walleij

gpio: remove gpiod_lock/unlock_as_irq()

2014-07-23T15:43:24Z

gpio_lock/unlock_as_irq() are working with (chip, offset) arguments and are thus not using the old integer namespace. Therefore, there is no reason to have gpiod variants of these functions working with descriptors, especially since the (chip, offset) tuple is more suitable to the users of these functions (GPIO drivers, whereas GPIO descriptors are targeted at GPIO consumers). Signed-off-by: Alexandre Courbot Signed-off-by: Linus Walleij

gpio: make gpiochip_get_desc() gpiolib-private

2014-07-23T15:41:12Z

As GPIO descriptors are not going to remain unique anymore, having this function public is not safe. Restrain its use to gpiolib since we have no user outside of it. Signed-off-by: Alexandre Courbot Signed-off-by: Linus Walleij

gpio: drop retval check enforcing from gpiochip_remove()

2014-07-23T08:47:49Z

As we start to decomission the return value from gpiochip_remove() the compilers emit warnings due to the function being tagged __must_check. So drop this until we remove the return value altogether. Cc: Abdoulaye Berthe Suggested-by: Stephen Rothwell Signed-off-by: Linus Walleij

gpio: include linux/bug.h in interface header

2014-05-16T15:52:36Z

Today's linux-next kernel started showing build errors for the use of WARN_ON in linux/gpio/consumer.h: In file included from drivers/video/backlight/pwm_bl.c:13:0: include/linux/gpio/consumer.h: In function 'gpiod_put': include/linux/gpio/consumer.h:81:2: error: implicit declaration of function 'WARN_ON' [-Werror=implicit-function-declaration] It's not clear why this never happened before, but this patch fixes it by including the header that contains the defintion of this macro. Signed-off-by: Arnd Bergmann Acked-by: Alexandre Courbot Signed-off-by: Linus Walleij