user/sven/linux.git/drivers/gpio, branch v3.4.46

gpiolib: Don't return -EPROBE_DEFER to sysfs, or for invalid gpios

2012-11-05T08:50:41Z

commit ad2fab36d7922401c4576fb7ea9b21a47a29a17f upstream. gpios requested with invalid numbers, or gpios requested from userspace via sysfs should not try to be deferred on failure. Signed-off-by: Mathias Nyman Signed-off-by: Linus Walleij Signed-off-by: Greg Kroah-Hartman

gpio-timberdale: fix a potential wrapping issue

2012-11-05T08:50:41Z

commit d79550a7bc35c16476ebdc27c78378d8093390ec upstream. ->last_ier is an unsigned long but the high bits can't be used int the original code because the shift wraps. Signed-off-by: Dan Carpenter Signed-off-by: Linus Walleij Signed-off-by: Greg Kroah-Hartman

gpio-lpc32xx: Fix value handling of gpio_direction_output()

2012-10-02T17:30:48Z

commit b1268d3737c6316016026245eef276eda6b0a621 upstream. For GPIOs of gpio-lpc32xx, gpio_direction_output() ignores the value argument (initial value of output). This patch fixes this by setting the level accordingly. Signed-off-by: Roland Stigge Acked-by: Alexandre Pereira da Silva Signed-off-by: Linus Walleij Signed-off-by: Greg Kroah-Hartman

gpiolib: wm8994: Pay attention to the value set when enabling as output

2012-07-16T16:04:09Z

commit 8cd578b6e28693f357867a77598a88ef3deb6b39 upstream. Not paying attention to the value being set is a bad thing because it means that we'll not set the hardware up to reflect what was requested. Not setting the hardware up to reflect what was requested means that the caller won't get the results they wanted. Signed-off-by: Mark Brown Signed-off-by: Linus Walleij Signed-off-by: Greg Kroah-Hartman

gpio: mpc8xxx: Prevent NULL pointer deref in demux handler

2012-06-01T07:18:25Z

commit d6de85e85edcc38c9edcde45a0a568818fcddc13 upstream. commit cfadd838(powerpc/8xxx: Fix interrupt handling in MPC8xxx GPIO driver) added an unconditional call of chip->irq_eoi() to the demux handler. This leads to a NULL pointer derefernce on MPC512x platforms which use this driver as well. Make it conditional. Reported-by: Thomas Wucher Signed-off-by: Thomas Gleixner Cc: Felix Radensky Cc: Kumar Gala Cc: Grant Likely Signed-off-by: Grant Likely Signed-off-by: Greg Kroah-Hartman

gpio/exynos: Fix compiler warnings when non-exynos machines are selected

2012-05-12T00:25:53Z

Fixes the following compiler warnings: drivers/gpio/gpio-samsung.c: In function ‘samsung_gpiolib_init’: drivers/gpio/gpio-samsung.c:2980:1: warning: label ‘err_ioremap1’ defined but not used [-Wunused-label] drivers/gpio/gpio-samsung.c:2978:1: warning: label ‘err_ioremap2’ defined but not used [-Wunused-label] drivers/gpio/gpio-samsung.c:2976:1: warning: label ‘err_ioremap3’ defined but not used [-Wunused-label] drivers/gpio/gpio-samsung.c:2974:1: warning: label ‘err_ioremap4’ defined but not used [-Wunused-label] drivers/gpio/gpio-samsung.c:2722:55: warning: unused variable ‘gpio_base4’ [-Wunused-variable] drivers/gpio/gpio-samsung.c:455:32: warning: ‘exynos_gpio_cfg’ defined but not used [-Wunused-variable] drivers/gpio/gpio-samsung.c:2126:33: warning: ‘exynos4_gpios_1’ defined but not used [-Wunused-variable] drivers/gpio/gpio-samsung.c:2228:33: warning: ‘exynos4_gpios_2’ defined but not used [-Wunused-variable] drivers/gpio/gpio-samsung.c:2373:33: warning: ‘exynos4_gpios_3’ defined but not used [-Wunused-variable] Signed-off-by: Sachin Kamat Signed-off-by: Grant Likely

gpio: pch9: Use proper flow type handlers

2012-05-12T00:18:50Z

Jean-Francois Dagenais reported: Configuring a gpio pin with the gpio-pch driver with "IRQF_TRIGGER_LOW | IRQF_ONESHOT" generates an interrupt storm for threaded ISR until the ISR thread actually gets to physically clear the interrupt on the triggering chip!! The immediate observable symptom is the high CPU usage for my ISR thread task and the interrupt count in /proc/interrupts incrementing radically. The driver is wrong in several ways: 1) Using handle_simple_irq() does not provide proper flow control handling. In the case of oneshot threaded handlers for the demultiplexed interrupts this results in an interrupt storm because the simple handler does not deal with masking/unmasking. Even without threaded oneshot handlers an interrupt storm for level type interrupts can easily be triggered when the interrupt is disabled and the interrupt line is activated from the device. 2) Acknowlegding the demultiplexed interrupt before calling the handler is wrong for level type interrupts. 3) The set_type function unconditionally enables the interrupt. It's supposed to set the type and nothing else. The unmasking is done by the core code. Move the acknowledge code into a separate function and add it to the demux irqchip callbacks. Remove the unconditional enabling from the set_type() callback and set the proper flow handlers depending on the selected type (level/edge). Reported-and-tested-by: Jean-Francois Dagenais Signed-off-by: Thomas Gleixner Signed-off-by: Grant Likely

gpio/omap: fix incorrect initialization of omap_gpio_mod_init

2012-05-10T14:16:15Z

Initialization of irqenable, irqstatus registers is the common operation done in this function for all OMAP platforms, viz. OMAP1, OMAP2+. The latter _gpio_rmw()'s which supposedly got introduced wrongly to take care of OMAP2+ platforms were overwriting initially programmed OMAP1 value breaking functionality on OMAP1. Somehow incorrect assumption was made that each _gpio_rmw()'s were mutually exclusive. On close observation it is found that the first _gpio_rmw() which is supposedly done to take care of OMAP1 platform is generic enough and takes care of OMAP2+ platform as well. Therefore remove the latter _gpio_rmw() to irqenable as they are redundant now. Writing to ctrl and debounce_en registers for OMAP2+ platforms are modified to match the original(pre-cleanup) code where the registers are initialized with 0. In the cleanup series since we are using _gpio_rmw(reg, 0, 1), instead of __raw_writel(), we are just reading and writing the same values to ctrl and debounce_en. This is not an issue for debounce_en register because it has 0x0 as the default value. But in the case of ctrl register the default value is 0x2 (GATINGRATIO = 0x1) so that we end up writing 0x2 instead of intended 0 value. Therefore changing back to __raw_writel() as this is sufficient for this case besides simpler to understand. Also, change irqstatus initalization logic that avoids comparison with bool, besides making it fit in a single line. Cc: stable@vger.kernel.org Cc: Tony Lindgren Cc: Kevin Hilman Cc: Santosh Shilimkar Cc: Grant Likely Reported-by: Janusz Krzysztofik Tested-by: Janusz Krzysztofik Signed-off-by: Tarun Kanti DebBarma Signed-off-by: Kevin Hilman

ARM: pxa: fix gpio wakeup setting

2012-04-27T02:46:45Z

In 3.3, gpio wakeup setting was broken. The call enable_irq_wake() didn't set up the PXA gpio registers (PWER, ...) anymore. Fix it at least for pxa27x. The driver doesn't seem to be used in pxa25x (weird ...), and the fix doesn't extend to pxa3xx and pxa95x (which don't have a gpio_set_wake() available). Signed-off-by: Robert Jarzmik Signed-off-by: Haojian Zhuang

gpio/exynos: Fix compiler warning in gpio-samsung.c file

2012-04-11T04:15:39Z

Fixes the following warning when "SAMSUNG EXYNOS5" is not selected: warning: ‘exynos5_gpios_1’ defined but not used [-Wunused-variable] warning: ‘exynos5_gpios_2’ defined but not used [-Wunused-variable] warning: ‘exynos5_gpios_3’ defined but not used [-Wunused-variable] warning: ‘exynos5_gpios_4’ defined but not used [-Wunused-variable] Signed-off-by: Sachin Kamat Signed-off-by: Grant Likely