linux-stable.git/drivers/gpio, branch v3.12.35

gpio: mcp23s08: Bug fix of SPI device tree registration.

2014-06-20T15:34:13+00:00

commit 99e4b98dbe3ad1fe38a74d12c3b8d44a55930de4 upstream.

The chips variable needs to be incremented for each chip that is
found in the spi_present_mask when registering via device tree.
Without this and the checking a negative index is passed to the
data->chip array in a subsequent loop.

Signed-off-by: Michael Welling 
Acked-by: Peter Korsgaard 
Signed-off-by: Linus Walleij 
Signed-off-by: Jiri Slaby

gpio: mxs: Allow for recursive enable_irq_wake() call

2014-05-15T07:56:09+00:00

commit a585f87c863e4e1d496459d382b802bf5ebe3717 upstream.

The scenario here is that someone calls enable_irq_wake() from somewhere
in the code. This will result in the lockdep producing a backtrace as can
be seen below. In my case, this problem is triggered when using the wl1271
(TI WlCore) driver found in drivers/net/wireless/ti/ .

The problem cause is rather obvious from the backtrace, but let's outline
the dependency. enable_irq_wake() grabs the IRQ buslock in irq_set_irq_wake(),
which in turns calls mxs_gpio_set_wake_irq() . But mxs_gpio_set_wake_irq()
calls enable_irq_wake() again on the one-level-higher IRQ , thus it tries to
grab the IRQ buslock again in irq_set_irq_wake() . Because the spinlock in
irq_set_irq_wake()->irq_get_desc_buslock()->__irq_get_desc_lock() is not
marked as recursive, lockdep will spew the stuff below.

We know we can safely re-enter the lock, so use IRQ_GC_INIT_NESTED_LOCK to
fix the spew.

 =============================================
 [ INFO: possible recursive locking detected ]
 3.10.33-00012-gf06b763-dirty #61 Not tainted
 ---------------------------------------------
 kworker/0:1/18 is trying to acquire lock:
  (&irq_desc_lock_class){-.-...}, at: [] __irq_get_desc_lock+0x48/0x88

 but task is already holding lock:
  (&irq_desc_lock_class){-.-...}, at: [] __irq_get_desc_lock+0x48/0x88

 other info that might help us debug this:
  Possible unsafe locking scenario:

        CPU0
        ----
   lock(&irq_desc_lock_class);
   lock(&irq_desc_lock_class);

  *** DEADLOCK ***

  May be due to missing lock nesting notation

 3 locks held by kworker/0:1/18:
  #0:  (events){.+.+.+}, at: [] process_one_work+0x134/0x4a4
  #1:  ((&fw_work->work)){+.+.+.}, at: [] process_one_work+0x134/0x4a4
  #2:  (&irq_desc_lock_class){-.-...}, at: [] __irq_get_desc_lock+0x48/0x88

 stack backtrace:
 CPU: 0 PID: 18 Comm: kworker/0:1 Not tainted 3.10.33-00012-gf06b763-dirty #61
 Workqueue: events request_firmware_work_func
 [] (unwind_backtrace+0x0/0xf0) from [] (show_stack+0x10/0x14)
 [] (show_stack+0x10/0x14) from [] (__lock_acquire+0x140c/0x1a64)
 [] (__lock_acquire+0x140c/0x1a64) from [] (lock_acquire+0x9c/0x104)
 [] (lock_acquire+0x9c/0x104) from [] (_raw_spin_lock_irqsave+0x44/0x58)
 [] (_raw_spin_lock_irqsave+0x44/0x58) from [] (__irq_get_desc_lock+0x48/0x88)
 [] (__irq_get_desc_lock+0x48/0x88) from [] (irq_set_irq_wake+0x20/0xf4)
 [] (irq_set_irq_wake+0x20/0xf4) from [] (mxs_gpio_set_wake_irq+0x1c/0x24)
 [] (mxs_gpio_set_wake_irq+0x1c/0x24) from [] (set_irq_wake_real+0x30/0x44)
 [] (set_irq_wake_real+0x30/0x44) from [] (irq_set_irq_wake+0x8c/0xf4)
 [] (irq_set_irq_wake+0x8c/0xf4) from [] (wlcore_nvs_cb+0x10c/0x97c)
 [] (wlcore_nvs_cb+0x10c/0x97c) from [] (request_firmware_work_func+0x38/0x58)
 [] (request_firmware_work_func+0x38/0x58) from [] (process_one_work+0x1c0/0x4a4)
 [] (process_one_work+0x1c0/0x4a4) from [] (worker_thread+0x138/0x394)
 [] (worker_thread+0x138/0x394) from [] (kthread+0xa4/0xb0)
 [] (kthread+0xa4/0xb0) from [] (ret_from_fork+0x14/0x34)
 wlcore: loaded

Signed-off-by: Marek Vasut 
Acked-by: Shawn Guo 
Signed-off-by: Linus Walleij 
Signed-off-by: Jiri Slaby

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

2014-01-09T20:25:15+00:00

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

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

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

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

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

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

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

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