linux/drivers/gpio, branch v3.12.10

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

2014-01-09T20:25:15Z

commit 4cc629b7a20945ce35628179180329b6bc9e552b upstream. 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. Signed-off-by: Stephen Boyd Signed-off-by: Linus Walleij Signed-off-by: Greg Kroah-Hartman

gpio: twl4030: Fix regression for twl gpio LED output

2014-01-09T20:25:15Z

commit f5837ec11f8cfa6d53ebc5806582771b2c9988c6 upstream. 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(); Signed-off-by: Roger Quadros Acked-by: Tony Lindgren Signed-off-by: Linus Walleij Signed-off-by: Greg Kroah-Hartman

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

2013-12-12T06:37:54Z

commit 1aeef303b5d9e243c41d5b80f8bb059366514a10 upstream. 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. Acked-by: Scott Wood Acked-by: Anatolij Gustschin Signed-off-by: Liu Gang Signed-off-by: Linus Walleij Signed-off-by: Greg Kroah-Hartman

gpio: pl061: move irqdomain initialization

2013-12-04T19:06:27Z

commit 2ba3154d9cb13697b97723cce75633b48adfe826 upstream. The PL061 driver had the irqdomain initialization in an unfortunate place: when used with device tree (and thus passing the base IRQ 0) the driver would work, as this registers an irqdomain and waits for mappings to be done dynamically as the devices request their IRQs, whereas when booting using platform data the irqdomain core would attempt to allocate IRQ descriptors dynamically (which works fine) but also to associate the irq_domain_associate_many() on all IRQs, which in turn will call the mapping function which at this point will try to set the type of the IRQ and then tries to acquire a non-initialized spinlock yielding a backtrace like this: CPU: 0 PID: 1 Comm: swapper Not tainted 3.13.0-rc1+ #652 Backtrace: [] (dump_backtrace) from [] (show_stack+0x18/0x1c) r6:c798ace0 r5:00000000 r4:c78257e0 r3:00200140 [] (show_stack) from [] (dump_stack+0x20/0x28) [] (dump_stack) from [] (__lock_acquire+0x1c0/0x1b80) [] (__lock_acquire) from [] (lock_acquire+0x6c/0x80) r10:00000000 r9:c0455234 r8:00000060 r7:c047d798 r6:600000d3 r5:00000000 r4:c782c000 [] (lock_acquire) from [] (_raw_spin_lock_irqsave+0x60/0x74) r6:c01a1100 r5:800000d3 r4:c798acd0 [] (_raw_spin_lock_irqsave) from [] (pl061_irq_type+0x28/0x) r6:00000000 r5:00000000 r4:c798acd0 [] (pl061_irq_type) from [] (__irq_set_trigger+0x70/0x104) r6:00000000 r5:c01a10d8 r4:c046da1c r3:c01a10d8 [] (__irq_set_trigger) from [] (irq_set_irq_type+0x40/0x60) r10:c043240c r8:00000060 r7:00000000 r6:c046da1c r5:00000060 r4:00000000 [] (irq_set_irq_type) from [] (pl061_irq_map+0x40/0x54) r6:c79693c0 r5:c798acd0 r4:00000060 [] (pl061_irq_map) from [] (irq_domain_associate+0xc0/0x190) r5:00000060 r4:c046da1c [] (irq_domain_associate) from [] (irq_domain_associate_man) r8:00000008 r7:00000000 r6:c79693c0 r5:00000060 r4:00000000 [] (irq_domain_associate_many) from [] (irq_domain_add_simp) r8:c046578c r7:c035b72c r6:c79693c0 r5:00000060 r4:00000008 r3:00000008 [] (irq_domain_add_simple) from [] (pl061_probe+0xc4/0x22c) r6:00000060 r5:c0464380 r4:c798acd0 [] (pl061_probe) from [] (amba_probe+0x74/0xe0) r10:c043240c r9:c0455234 r8:00000000 r7:c047d7f8 r6:c047d744 r5:00000000 r4:c0464380 This moves the irqdomain initialization to a point where the spinlock and GPIO chip are both fully propulated, so the callbacks can be used without crashes. I had some problem reproducing the crash, as the devm_kzalloc():ed zeroed memory would seemingly mask the spinlock as something OK, but by poisoning the lock like this: u32 *dum; dum = (u32 *) &chip->lock; *dum = 0xaaaaaaaaU; I could reproduce, fix and test the patch. Reported-by: Russell King Cc: Rob Herring Cc: Haojian Zhuang Cc: Baruch Siach Signed-off-by: Linus Walleij Signed-off-by: Greg Kroah-Hartman

gpio: rcar: NULL dereference on error in probe()

2013-12-04T19:05:12Z

commit 0c8aab8e65e450f2bfea494c1b6a86ded653f88c upstream. It's not obvious from the label name but "err1" tries to release "p->irq_domain" which leads to a NULL dereference. Fixes: 119f5e448d32 ('gpio: Renesas R-Car GPIO driver V3') Signed-off-by: Dan Carpenter Acked-by: Magnus Damm Signed-off-by: Linus Walleij Signed-off-by: Greg Kroah-Hartman

gpio: msm: make msm_gpio.summary_irq signed for error handling

2013-12-04T19:05:12Z

commit bfea603bc54c0a736d45bc60b188a8cdae9aaaa3 upstream. There is a bug in msm_gpio_probe() where we do: msm_gpio.summary_irq = platform_get_irq(pdev, 0); if (msm_gpio.summary_irq < 0) { The problem is that "msm_gpio.summary_irq" is unsigned so the error handling doesn't work. I've fixed it by making it signed. Fixes: 43f68444bce7 ('gpio: msm: Add device tree and irqdomain support for gpio-msm-v2') Signed-off-by: Dan Carpenter Signed-off-by: Linus Walleij Signed-off-by: Greg Kroah-Hartman

gpio: mvebu: make mvchip->irqbase signed for error handling

2013-12-04T19:05:12Z

commit d535922691fc026479fcc03e78ac3d931a54e75a upstream. There is a bug in mvebu_gpio_probe() where we do: mvchip->irqbase = irq_alloc_descs(-1, 0, ngpios, -1); if (mvchip->irqbase < 0) { The problem is that mvchip->irqbase is unsigned so the error handling doesn't work. I have changed it to be a regular int. Signed-off-by: Dan Carpenter Signed-off-by: Linus Walleij Signed-off-by: Greg Kroah-Hartman

gpio: twl4030: Fix regression for twl gpio output

2013-12-04T19:05:12Z

commit 0b2aa8bed3e13892fcac77e4f50ec6e80125469d upstream. Commit c111feabe2e2 (gpio: twl4030: Cache the direction and output states in private data) improved things in general, but caused a regression for setting the GPIO output direction. The change reorganized twl_direction_out() and twl_set() and swapped the function names around in the process. While doing that, a bug got introduced that's not obvious while reading the patch as it appears as no change to the code. The bug is we now call function twl4030_set_gpio_dataout() twice in both twl_direction_out() and twl_set(). Instead, we should first call twl_direction_out() in twl_direction_out() followed by twl4030_set_gpio_dataout() in twl_set(). This regression probably has gone unnoticed for a long time as the bootloader may have set the GPIO direction properly in many cases. This fixes at least the LCD panel not turning on omap3 LDP for example. Cc: linux-gpio@vger.kernel.org Reviewed-by: Peter Ujfalusi Acked-by: Linus Walleij Signed-off-by: Tony Lindgren Signed-off-by: Greg Kroah-Hartman

gpiolib: let gpiod_request() return -EPROBE_DEFER

2013-10-11T14:31:54Z

Patch be1a4b brought some improvements to the GPIO error handling code, but also changed the return value of gpiod_request() when called on a not yet initialized GPIO descriptor: it now returns -EINVAL instead of -EPROBE_DEFER, and this affects some drivers. This patch restores the original behavior for gpiod_request(). It is safe to do so now that desc_to_gpio() does not rely on the GPIO descriptor to be initialized. Other functions changed by patch be1a4b do not see their return value affected, so these are not reverted. Signed-off-by: Alexandre Courbot Reported-by: Dr. H. Nikolaus Schaller Signed-off-by: Linus Walleij

gpiolib: safer implementation of desc_to_gpio()

2013-10-11T14:31:53Z

The current implementation of desc_to_gpio() relies on the chip pointer to be set to a valid value in order to compute the GPIO number. This was done in the hope that we can get rid of the gpio_desc global array, but this is not happening anytime soon. This patch reimplements desc_to_gpio() in a fashion similar to that of gpio_to_desc(). As a result, desc_to_gpio(gpio_to_desc(gpio)) == gpio is now always true. This allows to call desc_to_gpio() on non-initialized descriptors as some error-handling code currently does. Signed-off-by: Alexandre Courbot Reported-by: Dr. H. Nikolaus Schaller Signed-off-by: Linus Walleij