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

gpio: mxs: Allow for recursive enable_irq_wake() call

2014-05-13T11:59:45+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: Greg Kroah-Hartman

gpio-rcar: R-Car GPIO IRQ share interrupt

2014-01-15T23:28:45+00:00

commit c234962b808f289237a40e4ce5fc1c8066d1c9d0 upstream.

R-Car H1 or Gen2 GPIO interrupts are assigned per each GPIO domain,
but, Gen1 E1/M1 GPIO interrupts are shared for all GPIO domain.
gpio-rcar driver needs IRQF_SHARED flags for these.
This patch was tested on Bock-W board

Signed-off-by: Kuninori Morimoto 
Signed-off-by: Simon Horman 
Signed-off-by: Greg Kroah-Hartman

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

2014-01-09T20:24:24+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:24:24+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:36:27+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-04T18:57:20+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-04T18:55:51+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: mvebu: make mvchip->irqbase signed for error handling

2013-12-04T18:55:50+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-04T18:55:50+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

gpio/lynxpoint: check if the interrupt is enabled in IRQ handler

2013-11-04T12:31:06+00:00

commit 03d152d5582abc8a1c19cb107164c3724bbd4be4 upstream.

Checking LP_INT_STAT is not enough in the interrupt handler because its
contents get updated regardless of whether the pin has interrupt enabled or
not. This causes the driver to loop forever for GPIOs that are pulled up.

Fix this by checking the interrupt enable bit for the pin as well.

Signed-off-by: Mika Westerberg 
Acked-by: Mathias Nyman 
Signed-off-by: Linus Walleij 
Signed-off-by: Greg Kroah-Hartman