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

gpio: squelch a compiler warning

2015-02-06T06:35:40+00:00

drivers/gpio/gpiolib-of.c: In function 'of_gpiochip_find_and_xlate':
drivers/gpio/gpiolib-of.c:51:21: warning: assignment makes integer from
pointer without a cast [enabled by default]
   gg_data->out_gpio = ERR_PTR(ret);
                     ^
this was introduced in d1c3449160df60fac4abb56f0ba0a3784305e43e

the upstream kernel changed the type of out_gpio from int to struct gpio_desc *
as part of a larger refactoring that wasn't backported

Signed-off-by: Martin Kaiser 
Signed-off-by: Greg Kroah-Hartman

gpio: sysfs: fix gpio device-attribute leak

2015-01-30T01:40:55+00:00

commit 0915e6feb38de8d3601819992a5bd050201a56fa upstream.

The gpio device attributes were never destroyed when the gpio was
unexported (or on export failures).

Use device_create_with_groups() to create the default device attributes
of the gpio class device. Note that this also fixes the
attribute-creation race with userspace for these attributes.

Remove contingent attributes in export error path and on unexport.

Fixes: d8f388d8dc8d ("gpio: sysfs interface")
Cc: stable 	# v2.6.27+
Signed-off-by: Johan Hovold 
Signed-off-by: Linus Walleij 
Signed-off-by: Greg Kroah-Hartman

gpio: sysfs: fix gpio-chip device-attribute leak

2015-01-30T01:40:55+00:00

commit 121b6a79955a3a3fd7bbb9b8cb88d5b9dad6283d upstream.

The gpio-chip device attributes were never destroyed when the device was
removed.

Fix by using device_create_with_groups() to create the device attributes
of the chip class device.

Note that this also fixes the attribute-creation race with userspace.

Fixes: d8f388d8dc8d ("gpio: sysfs interface")
Signed-off-by: Johan Hovold 
Signed-off-by: Linus Walleij 
Signed-off-by: Greg Kroah-Hartman

gpiolib: of: Correct error handling in of_get_named_gpiod_flags

2015-01-27T15:52:32+00:00

commit 7b8792bbdffdff3abda704f89c6a45ea97afdc62 upstream.

of_get_named_gpiod_flags fails with -EPROBE_DEFER in cases
where the gpio chip is available and the GPIO translation fails.

This causes drivers to be re-probed erroneusly, and hides the
real problem(i.e. the GPIO number being out of range).

Signed-off-by: Hans Holmberg 
Reviewed-by: Alexandre Courbot 
Signed-off-by: Linus Walleij 
Signed-off-by: Greg Kroah-Hartman

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