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

gpio: sysfs: fix memory leak in gpiod_sysfs_set_active_low

2015-03-06T00:39:18+00:00

commit 49d2ca84e433dab854c7a866bc6add09cfab682d upstream.

Fix memory leak in the gpio sysfs interface due to failure to drop
reference to device returned by class_find_device when setting the
gpio-line polarity.

Fixes: 0769746183ca ("gpiolib: add support for changing value polarity
in sysfs")
Signed-off-by: Johan Hovold 
Signed-off-by: Linus Walleij 
[bwh: Backported to 3.2: adjust filename]
Signed-off-by: Ben Hutchings

gpio: sysfs: fix memory leak in gpiod_export_link

2015-03-06T00:39:18+00:00

commit 0f303db08df0df9bd0966443ad6001e63960af16 upstream.

Fix memory leak in the gpio sysfs interface due to failure to drop
reference to device returned by class_find_device when creating a link.

Fixes: a4177ee7f1a8 ("gpiolib: allow exported GPIO nodes to be named
using sysfs links")
Signed-off-by: Johan Hovold 
Signed-off-by: Linus Walleij 
[bwh: Backported to 3.2: adjust filename]
Signed-off-by: Ben Hutchings

gpio: sysfs: fix gpio attribute-creation race

2015-02-20T00:49:38+00:00

commit ebbeba120ab2ec6ac5f3afc1425ec6ff0b77ad6f upstream.

Fix attribute-creation race with userspace by using the default group
to create also the contingent gpio device attributes.

Fixes: d8f388d8dc8d ("gpio: sysfs interface")
Signed-off-by: Johan Hovold 
Signed-off-by: Linus Walleij 
[bwh: Backported to 3.2:
 - Adjust filenames, context
 - Use gpio_to_desc(), not gpiod_to_desc(), in gpio_is_visible()
 - gpio_is_visible() must return mode_t]
Signed-off-by: Ben Hutchings

gpio: sysfs: fix gpio device-attribute leak

2015-02-20T00:49:38+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")
Signed-off-by: Johan Hovold 
Signed-off-by: Linus Walleij 
[bwh: Backported to 3.2: adjust filename, context]
Signed-off-by: Ben Hutchings

Fix circular locking dependency (3.3-rc2)

2015-02-20T00:49:37+00:00

commit 864533ceb6db336dead389577c102a8b792a121a upstream.

Hi,

On Wed, Feb 8, 2012 at 8:41 PM, Felipe Balbi  wrote:
> Hi guys,
>
> I have just triggered the folllowing:
>
> [   84.860321] ======================================================
> [   84.860321] [ INFO: possible circular locking dependency detected ]
> [   84.860321] 3.3.0-rc2-00026-ge4e8a39 #474 Not tainted
> [   84.860321] -------------------------------------------------------
> [   84.860321] bash/949 is trying to acquire lock:
> [   84.860321]  (sysfs_lock){+.+.+.}, at: [] gpio_value_store+0x24/0xcc
> [   84.860321]
> [   84.860321] but task is already holding lock:
> [   84.860321]  (s_active#22){++++.+}, at: [] sysfs_write_file+0xdc/0x184
> [   84.911468]
> [   84.911468] which lock already depends on the new lock.
> [   84.911468]
> [   84.920043]
> [   84.920043] the existing dependency chain (in reverse order) is:
> [   84.920043]
> [   84.927886] -> #1 (s_active#22){++++.+}:
> [   84.927886]        [] check_prevs_add+0xdc/0x150
> [   84.927886]        [] validate_chain.clone.24+0x564/0x694
> [   84.927886]        [] __lock_acquire+0x49c/0x980
> [   84.951660]        [] lock_acquire+0x98/0x100
> [   84.951660]        [] sysfs_deactivate+0xb0/0x100
> [   84.962982]        [] sysfs_addrm_finish+0x2c/0x6c
> [   84.962982]        [] sysfs_remove_dir+0x84/0x98
> [   84.962982]        [] kobject_del+0x10/0x78
> [   84.974670]        [] device_del+0x140/0x170
> [   84.974670]        [] device_unregister+0xc/0x18
> [   84.985382]        [] gpio_unexport+0xbc/0xdc
> [   84.985382]        [] gpio_free+0x14/0xfc
> [   85.001708]        [] unexport_store+0x78/0x8c
> [   85.001708]        [] class_attr_store+0x18/0x24
> [   85.007293]        [] sysfs_write_file+0x100/0x184
> [   85.018981]        [] vfs_write+0xb4/0x148
> [   85.018981]        [] sys_write+0x40/0x70
> [   85.018981]        [] ret_fast_syscall+0x0/0x3c
> [   85.035003]
> [   85.035003] -> #0 (sysfs_lock){+.+.+.}:
> [   85.035003]        [] check_prev_add+0x680/0x698
> [   85.035003]        [] check_prevs_add+0xdc/0x150
> [   85.052093]        [] validate_chain.clone.24+0x564/0x694
> [   85.052093]        [] __lock_acquire+0x49c/0x980
> [   85.052093]        [] lock_acquire+0x98/0x100
> [   85.069885]        [] mutex_lock_nested+0x3c/0x2f4
> [   85.069885]        [] gpio_value_store+0x24/0xcc
> [   85.069885]        [] dev_attr_store+0x18/0x24
> [   85.087158]        [] sysfs_write_file+0x100/0x184
> [   85.087158]        [] vfs_write+0xb4/0x148
> [   85.098297]        [] sys_write+0x40/0x70
> [   85.098297]        [] ret_fast_syscall+0x0/0x3c
> [   85.109069]
> [   85.109069] other info that might help us debug this:
> [   85.109069]
> [   85.117462]  Possible unsafe locking scenario:
> [   85.117462]
> [   85.117462]        CPU0                    CPU1
> [   85.128417]        ----                    ----
> [   85.128417]   lock(s_active#22);
> [   85.128417]                                lock(sysfs_lock);
> [   85.128417]                                lock(s_active#22);
> [   85.142486]   lock(sysfs_lock);
> [   85.151794]
> [   85.151794]  *** DEADLOCK ***
> [   85.151794]
> [   85.151794] 2 locks held by bash/949:
> [   85.158020]  #0:  (&buffer->mutex){+.+.+.}, at: [] sysfs_write_file+0x28/0x184
> [   85.170349]  #1:  (s_active#22){++++.+}, at: [] sysfs_write_file+0xdc/0x184
> [   85.170349]
> [   85.178588] stack backtrace:
> [   85.178588] [] (unwind_backtrace+0x0/0xf0) from [] (print_circular_bug+0x100/0x114)
> [   85.193023] [] (print_circular_bug+0x100/0x114) from [] (check_prev_add+0x680/0x698)
> [   85.193023] [] (check_prev_add+0x680/0x698) from [] (check_prevs_add+0xdc/0x150)
> [   85.212524] [] (check_prevs_add+0xdc/0x150) from [] (validate_chain.clone.24+0x564/0x694)
> [   85.212524] [] (validate_chain.clone.24+0x564/0x694) from [] (__lock_acquire+0x49c/0x980)
> [   85.233306] [] (__lock_acquire+0x49c/0x980) from [] (lock_acquire+0x98/0x100)
> [   85.233306] [] (lock_acquire+0x98/0x100) from [] (mutex_lock_nested+0x3c/0x2f4)
> [   85.242614] [] (mutex_lock_nested+0x3c/0x2f4) from [] (gpio_value_store+0x24/0xcc)
> [   85.261840] [] (gpio_value_store+0x24/0xcc) from [] (dev_attr_store+0x18/0x24)
> [   85.261840] [] (dev_attr_store+0x18/0x24) from [] (sysfs_write_file+0x100/0x184)
> [   85.271240] [] (sysfs_write_file+0x100/0x184) from [] (vfs_write+0xb4/0x148)
> [   85.290008] [] (vfs_write+0xb4/0x148) from [] (sys_write+0x40/0x70)
> [   85.298400] [] (sys_write+0x40/0x70) from [] (ret_fast_syscall+0x0/0x3c)
> -bash: echo: write error: Operation not permitted
>
> the way to trigger is:
>
> root@legolas:~# cd /sys/class/gpio/
> root@legolas:/sys/class/gpio# echo 2 > export
> root@legolas:/sys/class/gpio# echo 2 > unexport
> root@legolas:/sys/class/gpio# echo 2 > export
> root@legolas:/sys/class/gpio# cd gpio2/
> root@legolas:/sys/class/gpio/gpio2# echo 1 > value

Looks 'sysfs_lock' needn't to be held for unregister, so the patch below may
fix the problem.

Acked-by: Linus Walleij 
Signed-off-by: Grant Likely 
Signed-off-by: Ben Hutchings

gpiolib: Refactor gpio_export

2015-02-20T00:49:37+00:00

commit fc4e2514995d9cd7f3e1a67098ce65d72acf8ec7 upstream.

The gpio_export function uses nested if statements and the status
variable to handle the failure cases. This makes the function logic
difficult to follow. Refactor the code to abort immediately on failure
using goto. This makes the code slightly longer, but significantly
reduces the nesting and number of split lines and makes the code easier
to read.

Signed-off-by: Ryan Mallon 
Signed-off-by: Linus Walleij 
Signed-off-by: Ben Hutchings

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

2015-02-20T00:49:37+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 
[bwh: Backported to 3.2: adjust filename]
Signed-off-by: Ben Hutchings

gpio: fix memory and reference leaks in gpiochip_add error path

2015-02-20T00:49:37+00:00

commit 5539b3c938d64a60cb1fc442ac3ce9263d52de0c upstream.

Memory allocated and references taken by of_gpiochip_add and
acpi_gpiochip_add were never released on errors in gpiochip_add (e.g.
failure to find free gpio range).

Fixes: 391c970c0dd1 ("of/gpio: add default of_xlate function if device
has a node pointer")
Fixes: 664e3e5ac64c ("gpio / ACPI: register to ACPI events
automatically")

Signed-off-by: Johan Hovold 
Signed-off-by: Linus Walleij 
[bwh: Backported to 3.2:
 - Move call to of_gpiochip_add() into conditional section rather
   than rearranging gotos and labels which are in different places
   here
 - There's no ACPI support]
Signed-off-by: Ben Hutchings

gpio: mxs: Allow for recursive enable_irq_wake() call

2014-04-30T15:23:23+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: Ben Hutchings

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

2014-02-15T19:20:13+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: Ben Hutchings