user/sven/linux.git/drivers/pinctrl, branch v3.12.59

pinctrl: Don't just pretend to protect pinctrl_maps, do it for real

2015-05-20T09:15:42Z

commit c5272a28566b00cce79127ad382406e0a8650690 upstream. Way back, when the world was a simpler place and there was no war, no evil, and no kernel bugs, there was just a single pinctrl lock. That was how the world was when (57291ce pinctrl: core device tree mapping table parsing support) was written. In that case, there were instances where the pinctrl mutex was already held when pinctrl_register_map() was called, hence a "locked" parameter was passed to the function to indicate that the mutex was already locked (so we shouldn't lock it again). A few years ago in (42fed7b pinctrl: move subsystem mutex to pinctrl_dev struct), we switched to a separate pinctrl_maps_mutex. ...but (oops) we forgot to re-think about the whole "locked" parameter for pinctrl_register_map(). Basically the "locked" parameter appears to still refer to whether the bigger pinctrl_dev mutex is locked, but we're using it to skip locks of our (now separate) pinctrl_maps_mutex. That's kind of a bad thing(TM). Probably nobody noticed because most of the calls to pinctrl_register_map happen at boot time and we've got synchronous device probing. ...and even cases where we're asynchronous don't end up actually hitting the race too often. ...but after banging my head against the wall for a bug that reproduced 1 out of 1000 reboots and lots of looking through kgdb, I finally noticed this. Anyway, we can now safely remove the "locked" parameter and go back to a war-free, evil-free, and kernel-bug-free world. Fixes: 42fed7ba44e4 ("pinctrl: move subsystem mutex to pinctrl_dev struct") Signed-off-by: Doug Anderson Signed-off-by: Linus Walleij Signed-off-by: Jiri Slaby

pinctrl: Fix two deadlocks

2015-01-29T14:44:55Z

commit db93facfb0ef542aa5d8079e47580b3e669a4d82 upstream. This patch is to fix two deadlock cases. Deadlock 1: CPU #1 pinctrl_register-> pinctrl_get -> create_pinctrl (Holding lock pinctrl_maps_mutex) -> get_pinctrl_dev_from_devname (Trying to acquire lock pinctrldev_list_mutex) CPU #0 pinctrl_unregister (Holding lock pinctrldev_list_mutex) -> pinctrl_put ->> pinctrl_free -> pinctrl_dt_free_maps -> pinctrl_unregister_map (Trying to acquire lock pinctrl_maps_mutex) Simply to say CPU#1 is holding lock A and trying to acquire lock B, CPU#0 is holding lock B and trying to acquire lock A. Deadlock 2: CPU #3 pinctrl_register-> pinctrl_get -> create_pinctrl (Holding lock pinctrl_maps_mutex) -> get_pinctrl_dev_from_devname (Trying to acquire lock pinctrldev_list_mutex) CPU #2 pinctrl_unregister (Holding lock pctldev->mutex) -> pinctrl_put ->> pinctrl_free -> pinctrl_dt_free_maps -> pinctrl_unregister_map (Trying to acquire lock pinctrl_maps_mutex) CPU #0 tegra_gpio_request (Holding lock pinctrldev_list_mutex) -> pinctrl_get_device_gpio_range (Trying to acquire lock pctldev->mutex) Simply to say CPU#3 is holding lock A and trying to acquire lock D, CPU#2 is holding lock B and trying to acquire lock A, CPU#0 is holding lock D and trying to acquire lock B. Signed-off-by: Jim Lin Signed-off-by: Linus Walleij Signed-off-by: Jiri Slaby

pinctrl: sunxi: use chained_irq_{enter, exit} for GIC compatibility

2014-03-22T21:01:52Z

commit 905a5117e79367b7e58ae046d12ca9961f048c89 upstream. On tha Allwinner A20 SoC, the external interrupts on the pin controller device are connected to the GIC. Without chained_irq_{enter, exit}, external GPIO interrupts, such as used by mmc core card detect, cause the system to hang. This issue was first encountered during my attempt to get out-of-band interrupts for WiFi on the Cubietruck working. With David's new series of sunci-mci using mmc slot-gpio for (GPIO interrupt based) card detection, removing the SD card also causes my Cubietruck to hang. This problem should extend to all Allwinner A20 based boards. With this fix, the system no longer hangs when I remove or insert the SD card. /proc/interrupts show that the interrupt has correctly fired. However the system still does not detect card removal/insertion. I believe this is another unrelated issue. Signed-off-by: Chen-Yu Tsai Acked-by: Maxime Ripard Signed-off-by: Linus Walleij Signed-off-by: Jiri Slaby

pinctrl: protect pinctrl_list add

2014-02-20T19:08:02Z

commit 7b320cb1ed2dbd2c5f2a778197baf76fd6bf545a upstream. We have few fedora bug reports about list corruption on pinctrl, for example: https://bugzilla.redhat.com/show_bug.cgi?id=1051918 Most likely corruption happen due lack of protection of pinctrl_list when adding new nodes to it. Patch corrects that. Fixes: 42fed7ba44e ("pinctrl: move subsystem mutex to pinctrl_dev struct") Signed-off-by: Stanislaw Gruszka Acked-by: Stephen Warren Signed-off-by: Linus Walleij Signed-off-by: Greg Kroah-Hartman

pinctrl: vt8500: Change devicetree data parsing

2014-02-20T19:08:02Z

commit f17248ed868767567298e1cdf06faf8159a81f7c upstream. Due to an assumption in the VT8500 pinctrl driver, the value passed from devicetree for 'wm,pull' was not explicitly translated before being passed to pinconf. Since v3.10, changes to 'enum pin_config_param', PIN_CONFIG_BIAS_PULL_(UP/DOWN) no longer map 1-to-1 with the expected values in devicetree. This patch adds a small translation between the devicetree values (0..2) and the enum pin_config_param equivalent values. Signed-off-by: Tony Prisk Signed-off-by: Linus Walleij Signed-off-by: Greg Kroah-Hartman

pinctrl: at91: use locked variant of irq_set_handler

2014-02-20T19:08:02Z

commit b0dcfd87323ea86501e93d0fa2a98d2fd3579bcf upstream. When setting the gpio irq type, use the __irq_set_handler_locked() variant instead of the irq_set_handler() to prevent false spinlock recursion warning. Signed-off-by: Nicolas Ferre Signed-off-by: Linus Walleij Signed-off-by: Greg Kroah-Hartman

pinctrl: sunxi: Honor GPIO output initial vaules

2014-02-06T19:22:18Z

commit fa8cf57c923e86a693a85aff1df579245a27cbb3 upstream. Some GPIO users, such as fixed-regulator, request GPIO output with initial value of 1. This was ignored by sunxi driver. Signed-off-by: Chen-Yu Tsai Acked-by: Maxime Ripard Signed-off-by: Linus Walleij Signed-off-by: Greg Kroah-Hartman

Revert "ACPI: Add BayTrail SoC GPIO and LPSS ACPI IDs"

2014-01-25T16:49:28Z

commit 2b844ba79f4a114bd228ad6fee040ffd99a0963d upstream. This reverts commit f6308b36c411 (ACPI: Add BayTrail SoC GPIO and LPSS ACPI IDs), because it causes the Alan Cox' ASUS T100TA to "crash and burn" during boot if the Baytrail pinctrl driver is compiled in. Fixes: f6308b36c411 (ACPI: Add BayTrail SoC GPIO and LPSS ACPI IDs) Reported-by: One Thousand Gnomes Requested-by: Linus Walleij Signed-off-by: Rafael J. Wysocki Signed-off-by: Greg Kroah-Hartman

sh-pfc: Fix PINMUX_GPIO macro

2014-01-09T20:25:15Z

commit 8620f394c4f9abd13e4fdf927d9c2bbeda74cde7 upstream. Commit 7cbb0e55e27e ("sh-pfc: Don't duplicate argument to PINMUX_GPIO macro") erronesouly modified the PINMUX_GPIO macro in a way that resulted in all pins being named "name". Fix the macro to name the pins correctly. Cc: stable@vger.kernel.org Signed-off-by: Laurent Pinchart Signed-off-by: Linus Walleij Signed-off-by: Greg Kroah-Hartman

ACPI: Add BayTrail SoC GPIO and LPSS ACPI IDs

2014-01-09T20:25:09Z

commit f6308b36c411dc5afd6a6f73e6454722bfde57b7 upstream. This adds the new ACPI ID (INT33FC) for the BayTrail GPIO banks as seen on a BayTrail M System-On-Chip platform. This ACPI ID is used by the BayTrail GPIO (pinctrl) driver to manage the Low Power Subsystem (LPSS). Signed-off-by: Paul Drews Acked-by: Linus Walleij Signed-off-by: Rafael J. Wysocki Signed-off-by: Greg Kroah-Hartman