linux/drivers/pinctrl, branch v4.2

Merge tag 'pinctrl-v4.2-2' of git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-pinctrl

2015-07-21T22:27:27Z

Pull pin control fixes from Linus Walleij: "Here are some overly ripe pin control fixes for the v4.2 series. They got delayed because of various crap commits and having to clean and rinse the patch stack a few times. Now they are however looking good. - some dead defines dropped from the Samsung driver, was targeted for -rc2 but got delayed - drop the strict mode from abx500, this was too strict - fix the R-Car sparse IRQs code to work as intended - fix the IRQ code for the pinctrl-single GPIO backend to not enforce threaded IRQs - clear the latched events/IRQs for the Broadcom BCM2835 driver - fix up debugfs for the Freescale imx1 driver - fix a typo bug in the Schmitt Trigger setup in the LPC18xx driver" * tag 'pinctrl-v4.2-2' of git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-pinctrl: pinctrl: lpc18xx: fix schmitt trigger setup Subject: pinctrl: imx1-core: Fix debug output in .pin_config_set callback pinctrl: bcm2835: Clear the event latch register when disabling interrupts pinctrl: single: ensure pcs irq will not be forced threaded sh-pfc: fix sparse GPIOs for R-Car SoCs pinctrl: abx500: remove strict mode pinctrl: samsung: Remove old unused defines

pinctrl: lpc18xx: fix schmitt trigger setup

2015-07-20T09:01:53Z

The param_val variable is what determines if schmitt trigger is enabled on a pin or not. A typo here mean that schmitt trigger was always enabled for standard and i2c pins. Signed-off-by: Joachim Eastwood Signed-off-by: Linus Walleij

Subject: pinctrl: imx1-core: Fix debug output in .pin_config_set callback

2015-07-20T09:01:53Z

imx1_pinconf_set assumes that the array of pins in struct imx1_pinctrl_soc_info can be indexed by pin id to get the pinctrl_pin_desc for a pin. This used to be correct up to commit 607af165c047 which removed some entries from the array and so made it wrong to access the array by pin id. The result of this bug is a wrong pin name in the output for small pin ids and an oops for the bigger ones. This patch is the result of a discussion that includes patches by Markus Pargmann and Chris Ruehl. Fixes: 607af165c047 ("pinctrl: i.MX27: Remove nonexistent pad definitions") Cc: stable@vger.kernel.org Reported-by: Chris Ruehl Signed-off-by: Uwe Kleine-König Reviewed-by: Markus Pargmann Signed-off-by: Linus Walleij

pinctrl: bcm2835: Clear the event latch register when disabling interrupts

2015-07-20T09:01:52Z

It's possible to hit a race condition if interrupts are generated on a GPIO pin when the IRQ line in question is being disabled. If the interrupt is freed, bcm2835_gpio_irq_disable() is called which disables the event generation sources (edge, level). If an event occurred between the last disabling of hard IRQs and the write to the event source registers, a bit would be set in the GPIO event detect register (GPEDSn) which goes unacknowledged by bcm2835_gpio_irq_handler() so Linux complains loudly. There is no per-GPIO mask register, so when disabling GPIO interrupts write 1 to the relevant bit in GPEDSn to clear out any stale events. Signed-off-by: Jonathan Bell Acked-by: Stephen Warren Signed-off-by: Linus Walleij

pinctrl: single: ensure pcs irq will not be forced threaded

2015-07-20T09:01:52Z

The PSC IRQ is requested using request_irq() API and as result it can be forced to be threaded IRQ in RT-Kernel if PCS_QUIRK_HAS_SHARED_IRQ is enabled for pinctrl domain. As result, following 'possible irq lock inversion dependency' report can be seen: ========================================================= [ INFO: possible irq lock inversion dependency detected ] 3.14.43-rt42-00360-g96ff499-dirty #24 Not tainted --------------------------------------------------------- irq/369-pinctrl/927 just changed the state of lock: (&pcs->lock){+.....}, at: [] pcs_irq_handle+0x48/0x9c but this lock was taken by another, HARDIRQ-safe lock in the past: (&irq_desc_lock_class){-.....} and interrupts could create inverse lock ordering between them. other info that might help us debug this: Possible interrupt unsafe locking scenario: CPU0 CPU1 ---- ---- lock(&pcs->lock); local_irq_disable(); lock(&irq_desc_lock_class); lock(&pcs->lock); lock(&irq_desc_lock_class); *** DEADLOCK *** no locks held by irq/369-pinctrl/927. the shortest dependencies between 2nd lock and 1st lock: -> (&irq_desc_lock_class){-.....} ops: 58724 { IN-HARDIRQ-W at: [] lock_acquire+0x9c/0x158 [] _raw_spin_lock+0x48/0x58 [] handle_fasteoi_irq+0x24/0x15c [] generic_handle_irq+0x3c/0x4c [] handle_IRQ+0x50/0xa0 [] gic_handle_irq+0x3c/0x6c [] __irq_svc+0x44/0x8c [] arch_cpu_idle+0x40/0x4c [] cpu_startup_entry+0x270/0x2e0 [] rest_init+0xd4/0xe4 [] start_kernel+0x3d0/0x3dc [<80008084>] 0x80008084 INITIAL USE at: [] lock_acquire+0x9c/0x158 [] _raw_spin_lock_irqsave+0x54/0x68 [] __irq_get_desc_lock+0x64/0xa4 [] irq_set_chip+0x30/0x78 [] irq_set_chip_and_handler_name+0x24/0x3c [] gic_irq_domain_map+0x48/0xb4 [] irq_domain_associate+0x84/0x1d4 [] irq_create_mapping+0x80/0x11c [] irq_create_of_mapping+0x80/0x120 [] irq_of_parse_and_map+0x34/0x3c [] omap_dm_timer_init_one+0x90/0x30c [] omap5_realtime_timer_init+0x8c/0x48c [] time_init+0x28/0x38 [] start_kernel+0x240/0x3dc [<80008084>] 0x80008084 } ... key at: [] irq_desc_lock_class+0x0/0x8 ... acquired at: [] _raw_spin_lock+0x48/0x58 [] pcs_irq_unmask+0x58/0xa0 [] irq_enable+0x38/0x48 [] irq_startup+0x78/0x7c [] __setup_irq+0x4a8/0x4f4 [] request_threaded_irq+0xb8/0x138 [] omap_8250_startup+0x4c/0x148 [] serial8250_startup+0x24/0x30 [] uart_startup.part.9+0x5c/0x1b4 [] uart_open+0xf4/0x16c [] tty_open+0x170/0x61c [] chrdev_open+0xbc/0x1b4 [] do_dentry_open+0x1e8/0x2bc [] finish_open+0x44/0x5c [] do_last.isra.47+0x710/0xca0 [] path_openat+0xc4/0x640 [] do_filp_open+0x3c/0x98 [] do_sys_open+0x114/0x1d8 [] SyS_open+0x28/0x2c [] kernel_init_freeable+0x168/0x1e4 [] kernel_init+0x1c/0xf8 [] ret_from_fork+0x14/0x20 -> (&pcs->lock){+.....} ops: 65 { HARDIRQ-ON-W at: [] lock_acquire+0x9c/0x158 [] _raw_spin_lock+0x48/0x58 [] pcs_irq_handle+0x48/0x9c [] pcs_irq_handler+0x1c/0x28 [] irq_forced_thread_fn+0x30/0x74 [] irq_thread+0x158/0x1c4 [] kthread+0xd4/0xe8 [] ret_from_fork+0x14/0x20 INITIAL USE at: [] lock_acquire+0x9c/0x158 [] _raw_spin_lock_irqsave+0x54/0x68 [] pcs_enable+0x7c/0xe8 [] pinmux_enable_setting+0x178/0x220 [] pinctrl_select_state+0x110/0x194 [] pinctrl_bind_pins+0x7c/0x108 [] driver_probe_device+0x70/0x254 [] __driver_attach+0x9c/0xa0 [] bus_for_each_dev+0x78/0xac [] driver_attach+0x2c/0x30 [] bus_add_driver+0x15c/0x204 [] driver_register+0x88/0x108 [] __platform_driver_register+0x64/0x6c [] omap_hsmmc_driver_init+0x1c/0x20 [] do_one_initcall+0x110/0x170 [] kernel_init_freeable+0x140/0x1e4 [] kernel_init+0x1c/0xf8 [] ret_from_fork+0x14/0x20 } ... key at: [] __key.18572+0x0/0x8 ... acquired at: [] mark_lock+0x388/0x76c [] __lock_acquire+0x6d0/0x1f98 [] lock_acquire+0x9c/0x158 [] _raw_spin_lock+0x48/0x58 [] pcs_irq_handle+0x48/0x9c [] pcs_irq_handler+0x1c/0x28 [] irq_forced_thread_fn+0x30/0x74 [] irq_thread+0x158/0x1c4 [] kthread+0xd4/0xe8 [] ret_from_fork+0x14/0x20 stack backtrace: CPU: 1 PID: 927 Comm: irq/369-pinctrl Not tainted 3.14.43-rt42-00360-g96ff499-dirty #24 [] (unwind_backtrace) from [] (show_stack+0x20/0x24) [] (show_stack) from [] (dump_stack+0x84/0xd0) [] (dump_stack) from [] (print_irq_inversion_bug+0x1d0/0x21c) [] (print_irq_inversion_bug) from [] (check_usage_backwards+0xb4/0x11c) [] (check_usage_backwards) from [] (mark_lock+0x388/0x76c) [] (mark_lock) from [] (__lock_acquire+0x6d0/0x1f98) [] (__lock_acquire) from [] (lock_acquire+0x9c/0x158) [] (lock_acquire) from [] (_raw_spin_lock+0x48/0x58) [] (_raw_spin_lock) from [] (pcs_irq_handle+0x48/0x9c) [] (pcs_irq_handle) from [] (pcs_irq_handler+0x1c/0x28) [] (pcs_irq_handler) from [] (irq_forced_thread_fn+0x30/0x74) [] (irq_forced_thread_fn) from [] (irq_thread+0x158/0x1c4) [] (irq_thread) from [] (kthread+0xd4/0xe8) [] (kthread) from [] (ret_from_fork+0x14/0x20) To fix it use IRQF_NO_THREAD to ensure that pcs irq will not be forced threaded. Cc: Tony Lindgren Cc: Sebastian Andrzej Siewior Signed-off-by: Grygorii Strashko Acked-by: Tony Lindgren Signed-off-by: Linus Walleij

sh-pfc: fix sparse GPIOs for R-Car SoCs

2015-07-20T09:01:52Z

The PFC driver causes the kernel to hang on the R-Car gen2 SoC based boards when the CPU_ALL_PORT() macro is fixed to reflect the reality, i.e. when the GPIO space becomes actually sparse. This happens because the _GP_GPIO() macro includes an indexed initializer which causes the "holes" (array entries filled with all 0s) between the groups of the existing GPIOs; and the driver can't cope with that. There seems to be no reason to use the indexed initializer, so we can remove the index specifier and so avoid the "holes". Signed-off-by: Sergei Shtylyov Acked-by: Laurent Pinchart Tested-by: Geert Uytterhoeven Signed-off-by: Linus Walleij

pinctrl: abx500: remove strict mode

2015-07-20T09:01:51Z

Commit a21763a0b1e5a5ab8310f581886d04beadc16616 "pinctrl: nomadik: activate strict mux mode" put all Nomadik pin controllers to strict mode. This was not good on the Snowball platform: the muxing of GPIOs to different pins is done with hogs in the DTS file, and then these GPIOs are used by offset, relying on hogs to mux the pins. Since that means the pin controller "owns" the pins and at the same time we have a GPIO user, this pin controller is by definition not strict. Signed-off-by: Linus Walleij

Update Viresh Kumar's email address

2015-07-17T23:39:53Z

Switch to my kernel.org alias instead of a badly named gmail address, which I rarely use. Signed-off-by: Viresh Kumar Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds

pinctrl: samsung: Remove old unused defines

2015-07-17T07:55:55Z

Since 9a2c1c3b91aa ("pinctrl: samsung: Allow grouping multiple pinmux/pinconf nodes") the defines for GPIO group and function names are not used anywhere in the driver. Signed-off-by: Krzysztof Kozlowski Inspired-by: Dan Carpenter Signed-off-by: Linus Walleij

Merge branch 'irq-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip

2015-07-01T22:19:35Z

Pull irq fixes from Thomas Gleixner: "This contains: - a series of fixes for interrupt drivers to prevent a potential race when installing a chained interrupt handler - a fix for cpumask pointer misuse - a fix for using the wrong interrupt number from struct irq_data - removal of unused code and outdated comments - a few new helper functions which allow us to cleanup the interrupt handling code further in 4.3 I decided against doing the cleanup at the end of this merge window and rather do the preparatory steps for 4.3, so we can run the final ABI change at the end of the 4.3 merge window with less risk" * 'irq-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: (26 commits) ARM/LPC32xx: Use irq not hwirq for __irq_set_handler_locked() genirq: Implement irq_set_handler_locked()/irq_set_chip_handler_name_locked() genirq: Introduce helper irq_desc_get_irq() genirq: Remove irq_node() genirq: Clean up outdated comments related to include/linux/irqdesc.h mn10300: Fix incorrect use of irq_data->affinity MIPS/ralink: Fix race in installing chained IRQ handler MIPS/pci: Fix race in installing chained IRQ handler MIPS/ath25: Fix race in installing chained IRQ handler MIPS/ath25: Fix race in installing chained IRQ handler m68k/psc: Fix race in installing chained IRQ handler avr32/at32ap: Fix race in installing chained IRQ handler sh/intc: Fix race in installing chained IRQ handler sh/intc: Fix potential race in installing chained IRQ handler pinctrl/sun4i: Fix race in installing chained IRQ handler pinctrl/samsung: Fix race in installing chained IRQ handler pinctrl/samsung: Fix race in installing chained IRQ handler pinctrl/exynos: Fix race in installing chained IRQ handler pinctrl/st: Fix race in installing chained IRQ handler pinctrl/adi2: Fix race in installing chained IRQ handler ...