- 28 May, 2014 1 commit
-
-
Linus Walleij authored
Commit 3e3bed91 "gpio: mcp23s08: fixed count variable for devicetree probing" introduced a loop check to see if the number of chips were unconsistent and going below zero counting downwards, but this requires the counting variable to be able to be negative, so switch the variable from unsigned to int. Cc: Michael Stickel <ms@mycable.de> Signed-off-by:
Linus Walleij <linus.walleij@linaro.org>
-
- 27 May, 2014 5 commits
-
-
Sebastian Andrzej Siewior authored
Right new have one irq chip running always in level mode. It would nicer to have two irq chips where one is handling level type interrupts and the other one is doing edge interrupts. So we can have at runtime two users where one is using edge and the other level. Acked-by:
Alan Tull <delicious.quinoa@gmail.com> Acked-by:
Jamie Iles <jamie@jamieiles.com> Signed-off-by:
Sebastian Andrzej Siewior <bigeasy@linutronix.de> Signed-off-by:
-
Jingoo Han authored
Use devm_ioremap_resource() because devm_request_and_ioremap() is obsoleted by devm_ioremap_resource(). Signed-off-by:
Jingoo Han <jg1.han@samsung.com> Signed-off-by:
-
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:
-
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 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:
-
- 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:
-
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:
Alexandre Courbot <acourbot@nvidia.com> Signed-off-by:
-
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:
-
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:
-
- 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:
-
- 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:
-
abdoulaye berthe authored
This uses dem function for mem allocation Signed-off-by:
-
abdoulaye berthe authored
This eases memory allocation and provides appropriate logging. Signed-off-by:
-
abdoulaye berthe authored
Signed-off-by:
-
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:
-
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:
-
- 13 May, 2014 1 commit
-
-
Linus Walleij authored
Linux 3.15-rc4
-
- 09 May, 2014 22 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:
-
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:
-
Toby Smith authored
The irq handler should return IRQ_NONE or IRQ_HANDLED to report if we have handled the interrupt. Signed-off-by:
-
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:
Jason Cooper <jason@lakedaemon.net> Signed-off-by:
-
Jingoo Han authored
Make of_device_id array const, because all OF functions handle it as const. Signed-off-by:
-
Jingoo Han authored
Make of_device_id array const, because all OF functions handle it as const. Signed-off-by:
Michal Simek <monstr@monstr.eu> Signed-off-by:
-
Jingoo Han authored
Make of_device_id array const, because all OF functions handle it as const. Signed-off-by:
-
Jingoo Han authored
Make of_device_id array const, because all OF functions handle it as const. Signed-off-by:
-
Jingoo Han authored
Make of_device_id array const, because all OF functions handle it as const. Signed-off-by:
-
Jingoo Han authored
Make of_device_id array const, because all OF functions handle it as const. Signed-off-by:
-
Jingoo Han authored
Make of_device_id array const, because all OF functions handle it as const. Signed-off-by:
Andreas Larsson <andreas@gaisler.com> Signed-off-by:
-
Jingoo Han authored
The site-specific OOM messages are unnecessary, because they duplicate the MM subsystem generic OOM message. Signed-off-by:
-
Jingoo Han authored
The site-specific OOM messages are unnecessary, because they duplicate the MM subsystem generic OOM message. Signed-off-by:
-
Jingoo Han authored
The site-specific OOM messages are unnecessary, because they duplicate the MM subsystem generic OOM message. Signed-off-by:
-
Jingoo Han authored
The site-specific OOM messages are unnecessary, because they duplicate the MM subsystem generic OOM message. Signed-off-by:
-
Jingoo Han authored
The site-specific OOM messages are unnecessary, because they duplicate the MM subsystem generic OOM message. Signed-off-by:
Viresh Kumar <viresh.kumar@linaro.org> Reviewed-by:
-
Jingoo Han authored
The site-specific OOM messages are unnecessary, because they duplicate the MM subsystem generic OOM message. Signed-off-by:
-
Jingoo Han authored
The site-specific OOM messages are unnecessary, because they duplicate the MM subsystem generic OOM message. Signed-off-by:
Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by:
-
Jingoo Han authored
The site-specific OOM messages are unnecessary, because they duplicate the MM subsystem generic OOM message. Signed-off-by:
-
Jingoo Han authored
The site-specific OOM messages are unnecessary, because they duplicate the MM subsystem generic OOM message. Signed-off-by:
-
Jingoo Han authored
The site-specific OOM messages are unnecessary, because they duplicate the MM subsystem generic OOM message. Signed-off-by:
-
Jingoo Han authored
The site-specific OOM messages are unnecessary, because they duplicate the MM subsystem generic OOM message. Signed-off-by:
-
