linux/drivers/gpio, branch v3.13

Merge tag 'gpio-v3.13-4' of git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-gpio

2013-12-17T19:47:40Z

Pull GPIO fixes from Linus Walleij: "All but one are long-standing bug fixes that are also tagged for stable - Driver bug fixes for SH PFC, TWL4030, MSM and RCAR. - Update the MAINTAINERS" * tag 'gpio-v3.13-4' of git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-gpio: gpio: rcar: Fix level interrupt handling gpio: msm: Fix irq mask/unmask by writing bits instead of numbers gpio: twl4030: Fix regression for twl gpio LED output sh-pfc: Fix PINMUX_GPIO macro MAINTAINERS: update GPIO maintainers entry

gpio: rcar: Fix level interrupt handling

2013-12-12T19:53:05Z

According to the manual, if a port is set for level detection using the corresponding bit in the edge/level select register and an external level interrupt signal is asserted, the corresponding bit in INTDT does not use the FF to hold the input. Thus, writing 1 to the corresponding bits in INTCLR cannot clear the corresponding bits in the INTDT register. Instead, when an external input signal is stopped, the corresponding bit in INTDT is cleared automatically. Since the INTDT bit cannot be cleared for the level interrupts until the interrupt signal is stopped, we end up with the infinite loop when using deferred (threaded) IRQ handling. Since a deferred interrupt is disabled by the low-level handler and re-enabled only when the deferred handler is completed, Fix the issue by dropping disabled interrupts from the pending mask as suggested by Laurent Pinchart Changes in V2: * Drop disabled interrupts from pending mask altogether instead of dropping level interrupts one by one once they get handled. Signed-off-by: Valentine Barshak Acked-by: Laurent Pinchart Acked-by: Magnus Damm Signed-off-by: Linus Walleij

gpio: msm: Fix irq mask/unmask by writing bits instead of numbers

2013-12-12T18:59:57Z

We should be writing bits here but instead we're writing the numbers that correspond to the bits we want to write. Fix it by wrapping the numbers in the BIT() macro. This fixes gpios acting as interrupts. Cc: stable@vger.kernel.org Signed-off-by: Stephen Boyd Signed-off-by: Linus Walleij

gpio: twl4030: Fix regression for twl gpio LED output

2013-12-10T12:17:27Z

Commit 0b2aa8be introduced a regression that causes failure in setting LED GPO direction to OUT. This causes USB host probe failures for Beagleboard C4. platform usb_phy_gen_xceiv.2: Driver usb_phy_gen_xceiv requests probe deferral hsusb2_vcc: Failed to request enable GPIO510: -22 reg-fixed-voltage reg-fixed-voltage.0.auto: Failed to register regulator: -22 reg-fixed-voltage: probe of reg-fixed-voltage.0.auto failed with error -22 direction_out/direction_in must return 0 if the operation succeeded. Also, don't update direction flag and output data if twl4030_set_gpio_direction() failed inside twl_direction_out(); Cc: stable@vger.kernel.org Signed-off-by: Roger Quadros Acked-by: Tony Lindgren Signed-off-by: Linus Walleij

Merge tag 'omap-for-v3.13/yet-more-dt-regressions-take2' of git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap into fixes

2013-12-09T23:38:41Z

A rather big fix for a regression where we have dropped omap4 hwmod data earlier but are not initializing it from device tree. In addition to this fix we eventually also be fix the issues in the .dts files and drivers, but that's too intrusive for the -rc cycle and must be done later on. Also a fix for a regression where we now are wrongly trying to initialize devices on secure omaps like n900 and n9* when booted using device tree. We need to set aes, sham and timer12 to disabled mode for secure devices as they are claimed by the firmware running in the secure mode. And two more legacy booting vs device tree based booting fixes for am3517 that I did not notice earlier until Nishant Menon reported these to me few days ago. With these we're good to go having v3.13 working both for legacy booting and device tree based booting, and we can then go ahed and drop the legacy booting for mach-omap2 for v3.14. * tag 'omap-for-v3.13/yet-more-dt-regressions-take2' of git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap: (494 commits) ARM: dts: Fix booting for secure omaps ARM: OMAP2+: Fix the machine entry for am3517 ARM: dts: Fix missing entries for am3517 ARM: OMAP2+: Fix overwriting hwmod data with data from device tree +Linux 3.13-rc3

Merge tag 'davinci-fixes-for-v3.13-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/nsekhar/linux-davinci into fixes

2013-12-04T20:18:50Z

From Sekhar Nori: This pull request contains a fixe for broken unbanked GPIO IRQ support and a fix for some random memory corruption. The bugs were introduced during v3.13 merge window. * tag 'davinci-fixes-for-v3.13-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/nsekhar/linux-davinci: ARM: davinci: fix number of resources passed to davinci_gpio_register() gpio: davinci: fix check for unbanked gpio

gpiolib: change a warning to debug message when failing to get gpio

2013-12-03T12:10:48Z

It's the drivers responsibility to react on failure to get the gpio descriptors and not the frameworks. Since there are some common peripherals that may or may not have certain pins connected to gpio lines, depending on the platform, printing the warning there may end up generating useless bug reports. Signed-off-by: Heikki Krogerus Signed-off-by: Linus Walleij

powerpc/gpio: Fix the wrong GPIO input data on MPC8572/MPC8536

2013-12-03T12:10:48Z

For MPC8572/MPC8536, the status of GPIOs defined as output cannot be determined by reading GPDAT register, so the code use shadow data register instead. But the code may give the wrong status of GPIOs defined as input under some scenarios: 1. If some pins were configured as inputs and were asserted high before booting the kernel, the shadow data has been initialized with those pin values. 2. Some pins have been configured as output first and have been set to the high value, then reconfigured as input. The above cases will make the shadow data for those input pins to be set to high. Then reading the pin status will always return high even if the actual pin status is low. The code should eliminate the effects of the shadow data to the input pins, and the status of those pins should be read directly from GPDAT. Cc: stable@vger.kernel.org Acked-by: Scott Wood Acked-by: Anatolij Gustschin Signed-off-by: Liu Gang Signed-off-by: Linus Walleij

gpiolib: use platform GPIO mappings as fallback

2013-12-03T12:10:48Z

For platforms that use device tree or ACPI as the standard way to look GPIOs up, allow the platform-defined GPIO mappings to be used as a fallback. This may be useful for platforms that need extra GPIOs mappings not defined by the firmware. Signed-off-by: Alexandre Courbot Signed-off-by: Linus Walleij

gpiolib: fix lookup of platform-mapped GPIOs

2013-12-03T12:10:48Z

A typo resulted in GPIO lookup failing unconditionally. Signed-off-by: Alexandre Courbot Reported-by: Stephen Warren Reviewed-by: Mika Westerberg Signed-off-by: Linus Walleij