user/sven/linux.git/drivers/gpio, branch v3.2.60

gpio: mxs: Allow for recursive enable_irq_wake() call

2014-04-30T15:23:23Z

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:13Z

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

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

2014-01-03T04:33:28Z

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: Ben Hutchings

gpio-timberdale: fix a potential wrapping issue

2012-11-16T16:46:52Z

commit d79550a7bc35c16476ebdc27c78378d8093390ec upstream. ->last_ier is an unsigned long but the high bits can't be used int the original code because the shift wraps. Signed-off-by: Dan Carpenter Signed-off-by: Linus Walleij Signed-off-by: Ben Hutchings

gpio-lpc32xx: Fix value handling of gpio_direction_output()

2012-10-10T02:31:04Z

commit b1268d3737c6316016026245eef276eda6b0a621 upstream. For GPIOs of gpio-lpc32xx, gpio_direction_output() ignores the value argument (initial value of output). This patch fixes this by setting the level accordingly. Signed-off-by: Roland Stigge Acked-by: Alexandre Pereira da Silva Signed-off-by: Linus Walleij Signed-off-by: Ben Hutchings

gpiolib: wm8994: Pay attention to the value set when enabling as output

2012-07-25T03:11:08Z

commit 8cd578b6e28693f357867a77598a88ef3deb6b39 upstream. Not paying attention to the value being set is a bad thing because it means that we'll not set the hardware up to reflect what was requested. Not setting the hardware up to reflect what was requested means that the caller won't get the results they wanted. Signed-off-by: Mark Brown Signed-off-by: Linus Walleij Signed-off-by: Ben Hutchings

gpio: mpc8xxx: Prevent NULL pointer deref in demux handler

2012-05-30T23:43:59Z

commit d6de85e85edcc38c9edcde45a0a568818fcddc13 upstream. commit cfadd838(powerpc/8xxx: Fix interrupt handling in MPC8xxx GPIO driver) added an unconditional call of chip->irq_eoi() to the demux handler. This leads to a NULL pointer derefernce on MPC512x platforms which use this driver as well. Make it conditional. Reported-by: Thomas Wucher Signed-off-by: Thomas Gleixner Cc: Felix Radensky Cc: Kumar Gala Cc: Grant Likely Signed-off-by: Grant Likely Signed-off-by: Ben Hutchings

gpio: Add missing spin_lock_init in gpio-ml-ioh driver

2012-05-20T21:56:43Z

commit 7e3a70fb7bccada029c188c89bfbf3c0a63c1500 upstream. This bug was introduced by commit 54be5663 "gpio-ml-ioh: Support interrupt function" which adds a spinlock to struct ioh_gpio but never init the spinlock. Signed-off-by: Axel Lin Signed-off-by: Grant Likely Signed-off-by: Ben Hutchings

gpio: Add missing spin_lock_init in gpio-pch driver

2012-04-22T22:31:12Z

commit d166370ad86b33b1111af3a0cdd7de94e03789a6 upstream. This bug was introduced by commit d568a681 "gpio-pch: add spinlock in suspend/resume processing" which adds a spinlock to struct pch_gpio but never init the spinlock. Reported-by: Tomoya MORINAGA Signed-off-by: Axel Lin Acked-by: Linus Walleij Signed-off-by: Grant Likely Signed-off-by: Greg Kroah-Hartman

pch_gpio: Support new device LAPIS Semiconductor ML7831 IOH

2012-04-22T22:31:12Z

commit 868fea0507308b6548bba7debe5f5c2d5ca47fca upstream. ML7831 is companion chip for Intel Atom E6xx series. Signed-off-by: Tomoya MORINAGA Signed-off-by: Grant Likely Signed-off-by: Greg Kroah-Hartman