- 27 May, 2014 3 commits
-
-
Michael Stickel authored
Fixed missing increase of count variable for devicetree path in driver probing. The gpio-mcp23s08 driver has two paths for getting the platform registration information. One for the classic platform initialization and one for openfirmware devicetree based initialization. The devicetree based path is missing the increase of the count variable, which results in the count variable to become negative in the later use, where it is decreased. The count variable is used as an index into a vector. This results in accessing invalid memory space and can result in an exception. Tested this with an AM3352 SoC with two mcp23s17 on two chip selects as well as on a shared chip select. Signed-off-by: Michael Stickel <ms@mycable.de> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
-
Jean Delvare authored
The Renesas R-Car GPIO driver is only useful on shmobile unless build testing. Signed-off-by: Jean Delvare <jdelvare@suse.de> Cc: Magnus Damm <damm@opensource.se> Cc: Alexandre Courbot <gnurou@gmail.com> Acked-by: Simon Horman <horms+renesas@verge.net.au> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
-
Linus Walleij authored
After change 3ff35cbc "gpio-pch: Fix Kconfig dependencies" which enabled COMPILE_TEST as an alternative for the PCH driver, we get build failures like this: drivers/gpio/gpio-pch.c: In function 'pch_gpio_probe': drivers/gpio/gpio-pch.c:359:2: error: implicit declaration of function 'kzalloc' [-Werror=implicit-function-declaration] drivers/gpio/gpio-pch.c:359:7: warning: assignment makes pointer from integer without a cast [enabled by default] drivers/gpio/gpio-pch.c:442:2: error: implicit declaration of function 'kfree' [-Werror=implicit-function-declaration] Fix this by including <linux/slab.h> explicitly. Cc: Jean Delvare <jdelvare@suse.de> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
-
- 23 May, 2014 4 commits
-
-
Jarkko Nikula authored
Commit fd8e198c ("Documentation: gpiolib: document new interface") moved Documentation/gpio.txt to Documentation/gpio/gpio-legacy.txt and added new documents for descriptor-based interface so fix the the location here to point Documentation/gpio/ since that what commit ccb6fbb9 ("Documentation / ACPI: update to GPIO descriptor API") was looking for. Signed-off-by: Jarkko Nikula <jarkko.nikula@linux.intel.com> Acked-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
-
Aaron Lu authored
The GPIO operation region handler should be called where sleep is allowed, so we should use the *_cansleep version of gpiod_get/set APIs or we will get a warning message complaining invalid context if the GPIO chip has the cansleep flag set. Signed-off-by: Aaron Lu <aaron.lu@intel.com> Acked-by: Mika Westerberg <mika.westerberg@linux.intel.com> Acked-by: Alexandre Courbot <acourbot@nvidia.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
-
Anthony Fee authored
gpiolib will require all gpio drivers to expicitly set the request function pointer in the future. To encourage gpio driver developers to adhere to this standard gpio-generic.c now sets this function pointer. Signed-off-by: Anthony Fee <anthony.fee@emutex.com> Acked-by: Alexandre Courbot <acourbot@nvidia.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
-
Jean Delvare authored
The gpio-pch driver is for a companion chip to the Intel Atom E600 series processors. These are 32-bit x86 processors so the driver is only needed on X86_32. Add COMPILE_TEST as an alternative, so that the driver can still be build-tested elsewhere. Signed-off-by: Jean Delvare <jdelvare@suse.de> Cc: Linus Walleij <linus.walleij@linaro.org> Cc: Alexandre Courbot <gnurou@gmail.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
-
- 21 May, 2014 1 commit
-
-
Alexandre Courbot authored
of_get_named_gpiod_flags() is visible and directly usable by GPIO consumers, but it really should not as the gpiod interface relies on the simpler gpiod_get() to provide properly-configured GPIOs. of_get_named_gpiod_flags() is just used internally by gpiolib to implement gpiod_get(), and by the old of_get_named_gpio_flags() function, therefore it makes sense to make it gpiolib-private. As a side-effect, the unused (and unneeded) of_get_gpiod_flags() inline function is also removed, and of_get_named_gpio_flags() is moved from a static inline function to a regular one in gpiolib-of.c This results in all references to gpiod_* functions in of_gpio.h being gone, which is the way it should be since this file is part of the old integer GPIO interface. Changes since v1: - Fixed compilation error when CONFIG_OF_GPIO is not defined - Fixed warning due to of_gpio_flags enum not being declared in private gpiolib.h header Signed-off-by: Alexandre Courbot <acourbot@nvidia.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
-
- 16 May, 2014 6 commits
-
-
abdoulaye berthe authored
This uses devm functions for mem allocation Signed-off-by: abdoulaye berthe <berthe.ab@gmail.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
-
abdoulaye berthe authored
This uses dem function for mem allocation Signed-off-by: abdoulaye berthe <berthe.ab@gmail.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
-
abdoulaye berthe authored
This eases memory allocation and provides appropriate logging. Signed-off-by: abdoulaye berthe <berthe.ab@gmail.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
-
abdoulaye berthe authored
Signed-off-by: abdoulaye berthe <berthe.ab@gmail.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
-
Arnd Bergmann authored
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 <arnd@arnd.de> Acked-by: Alexandre Courbot <acourbot@nvidia.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
-
Rajendra Nayak authored
Replace the clk_enable()s with a clk_prepare_enable() and the clk_disables()s with a clk_disable_unprepare() This never showed issues due to the OMAP platform code (hwmod) leaving these clocks in clk_prepare()ed state by default. Reported-by: Kishon Vijay Abraham I <kishon@ti.com> Signed-off-by: Rajendra Nayak <rnayak@ti.com> Acked-by: Javier Martinez Canillas <javier@dowhile0.org> Acked-by: Santosh Shilimkar <santosh.shilimkar@ti.com> Cc: Kevin Hilman <khilman@deeprootsystems.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
-
- 13 May, 2014 1 commit
-
-
Linus Walleij authored
Linux 3.15-rc4
-
- 09 May, 2014 25 commits
-
-
Thierry Reding authored
Introduce gpiod_get_optional() and gpiod_get_index_optional() helpers that make it easier for drivers to handle optional GPIOs. Currently in order to handle optional GPIOs, a driver needs to special case error handling for -ENOENT, such as this: gpio = gpiod_get(dev, "foo"); if (IS_ERR(gpio)) { if (PTR_ERR(gpio) != -ENOENT) return PTR_ERR(gpio); gpio = NULL; } if (gpio) { /* set up GPIO */ } With these new helpers the above is reduced to: gpio = gpiod_get_optional(dev, "foo"); if (IS_ERR(gpio)) return PTR_ERR(gpio); if (gpio) { /* set up GPIO */ } While at it, device-managed variants of these functions are also provided. Signed-off-by: Thierry Reding <treding@nvidia.com> Reviewed-by: Alexandre Courbot <acourbot@nvidia.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
-
Toby Smith authored
Request a shared interrupt when requesting a pca953x GPIO interrupt Signed-off-by: Toby Smith <toby@tismith.id.au> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
-
Toby Smith authored
The irq handler should return IRQ_NONE or IRQ_HANDLED to report if we have handled the interrupt. Signed-off-by: Toby Smith <toby@tismith.id.au> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
-
Ezequiel Garcia authored
There's no reason to use an initcall to initialize this driver, and regular module_platform_driver() can be used instead. Signed-off-by: Ezequiel Garcia <ezequiel.garcia@free-electrons.com> Reviewed-by: Javier Martinez Canillas <javier@dowhile0.org> Acked-by: Jason Cooper <jason@lakedaemon.net> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
-
Jingoo Han authored
Make of_device_id array const, because all OF functions handle it as const. Signed-off-by: Jingoo Han <jg1.han@samsung.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
-
Jingoo Han authored
Make of_device_id array const, because all OF functions handle it as const. Signed-off-by: Jingoo Han <jg1.han@samsung.com> Reviewed-by: Michal Simek <monstr@monstr.eu> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
-
Jingoo Han authored
Make of_device_id array const, because all OF functions handle it as const. Signed-off-by: Jingoo Han <jg1.han@samsung.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
-
Jingoo Han authored
Make of_device_id array const, because all OF functions handle it as const. Signed-off-by: Jingoo Han <jg1.han@samsung.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
-
Jingoo Han authored
Make of_device_id array const, because all OF functions handle it as const. Signed-off-by: Jingoo Han <jg1.han@samsung.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
-
Jingoo Han authored
Make of_device_id array const, because all OF functions handle it as const. Signed-off-by: Jingoo Han <jg1.han@samsung.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
-
Jingoo Han authored
Make of_device_id array const, because all OF functions handle it as const. Signed-off-by: Jingoo Han <jg1.han@samsung.com> Acked-by: Andreas Larsson <andreas@gaisler.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
-
Jingoo Han authored
The site-specific OOM messages are unnecessary, because they duplicate the MM subsystem generic OOM message. Signed-off-by: Jingoo Han <jg1.han@samsung.com> Reviewed-by: Javier Martinez Canillas <javier@dowhile0.org> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
-
Jingoo Han authored
The site-specific OOM messages are unnecessary, because they duplicate the MM subsystem generic OOM message. Signed-off-by: Jingoo Han <jg1.han@samsung.com> Reviewed-by: Javier Martinez Canillas <javier@dowhile0.org> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
-
Jingoo Han authored
The site-specific OOM messages are unnecessary, because they duplicate the MM subsystem generic OOM message. Signed-off-by: Jingoo Han <jg1.han@samsung.com> Reviewed-by: Javier Martinez Canillas <javier@dowhile0.org> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
-
Jingoo Han authored
The site-specific OOM messages are unnecessary, because they duplicate the MM subsystem generic OOM message. Signed-off-by: Jingoo Han <jg1.han@samsung.com> Reviewed-by: Javier Martinez Canillas <javier@dowhile0.org> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
-
Jingoo Han authored
The site-specific OOM messages are unnecessary, because they duplicate the MM subsystem generic OOM message. Signed-off-by: Jingoo Han <jg1.han@samsung.com> Acked-by: Viresh Kumar <viresh.kumar@linaro.org> Reviewed-by: Javier Martinez Canillas <javier@dowhile0.org> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
-
Jingoo Han authored
The site-specific OOM messages are unnecessary, because they duplicate the MM subsystem generic OOM message. Signed-off-by: Jingoo Han <jg1.han@samsung.com> Reviewed-by: Javier Martinez Canillas <javier@dowhile0.org> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
-
Jingoo Han authored
The site-specific OOM messages are unnecessary, because they duplicate the MM subsystem generic OOM message. Signed-off-by: Jingoo Han <jg1.han@samsung.com> Acked-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Javier Martinez Canillas <javier@dowhile0.org> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
-
Jingoo Han authored
The site-specific OOM messages are unnecessary, because they duplicate the MM subsystem generic OOM message. Signed-off-by: Jingoo Han <jg1.han@samsung.com> Reviewed-by: Javier Martinez Canillas <javier@dowhile0.org> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
-
Jingoo Han authored
The site-specific OOM messages are unnecessary, because they duplicate the MM subsystem generic OOM message. Signed-off-by: Jingoo Han <jg1.han@samsung.com> Reviewed-by: Javier Martinez Canillas <javier@dowhile0.org> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
-
Jingoo Han authored
The site-specific OOM messages are unnecessary, because they duplicate the MM subsystem generic OOM message. Signed-off-by: Jingoo Han <jg1.han@samsung.com> Acked-by: Jason Cooper <jason@lakedaemon.net> Reviewed-by: Javier Martinez Canillas <javier@dowhile0.org> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
-
Jingoo Han authored
The site-specific OOM messages are unnecessary, because they duplicate the MM subsystem generic OOM message. Signed-off-by: Jingoo Han <jg1.han@samsung.com> Reviewed-by: Javier Martinez Canillas <javier@dowhile0.org> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
-
Jingoo Han authored
The site-specific OOM messages are unnecessary, because they duplicate the MM subsystem generic OOM message. Signed-off-by: Jingoo Han <jg1.han@samsung.com> Reviewed-by: Javier Martinez Canillas <javier@dowhile0.org> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
-
Jingoo Han authored
The site-specific OOM messages are unnecessary, because they duplicate the MM subsystem generic OOM message. Signed-off-by: Jingoo Han <jg1.han@samsung.com> Reviewed-by: Javier Martinez Canillas <javier@dowhile0.org> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
-
Jingoo Han authored
The site-specific OOM messages are unnecessary, because they duplicate the MM subsystem generic OOM message. Signed-off-by: Jingoo Han <jg1.han@samsung.com> Reviewed-by: Javier Martinez Canillas <javier@dowhile0.org> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
-