linux-toradex.git/drivers/gpio, branch v3.4.2

gpio: mpc8xxx: Prevent NULL pointer deref in demux handler

2012-06-01T07:18:25+00:00

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:53+00:00

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:50+00:00

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:15+00:00

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:45+00:00

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:39+00:00

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

gpio: Fix uninitialized variable bit in adp5588_irq_handler

2012-04-10T20:20:55+00:00

The variable 'bit' is uninitialized in the first iteration of for
loop. Fix it.

Signed-off-by: Axel Lin 
Signed-off-by: Grant Likely

gpio/sodaville: Convert sodaville driver to new irqdomain API

2012-04-10T20:20:55+00:00

The irqdomain api changed significantly in v3.4 which caused a build
failure for this driver.

Signed-off-by: Grant Likely 
Acked-by: Sebastian Andrzej Siewior 
Cc: Hans J. Koch 
Cc: Torben Hohn

gpio: tegra: Iterate over the correct number of banks

2012-04-04T19:13:18+00:00

When Tegra30 support was added to the Tegra GPIO driver, a few places
which iterated over all banks were not converted to use the variable
tegra_gpio_bank_count rather than hard-coding the bank count. Fix this.

Signed-off-by: Stephen Warren 
Acked-by: Olof Johansson

gpio: tegra: fix register address calculations for Tegra30

2012-04-04T19:13:13+00:00

Tegra20 and Tegra30 share the same register layout within registers, but
the addresses of the registers is a little different. Fix the driver to
cope with this.

Signed-off-by: Stephen Warren 
Acked-by: Olof Johansson