user/sven/linux.git/drivers/pinctrl, branch v4.8.13

pinctrl: iproc: Fix iProc and NSP GPIO support

2016-11-18T09:51:52Z

commit 091c531b09c151c2d712a8f347009ca3698a2467 upstream. Since commit 44a7185c2ae6 ("of/platform: Add common method to populate default bus"), ARM64 platform devices are populated at the arch_initcall_sync level; as a result, the platform_driver_probe calls in both the iProc and NSP GPIO drivers fail with -ENODEV since by that time the platform device was not yet registered. Replace platform_driver_probe with platform_driver_register, that allow the device to be register later Fixes: 44a7185c2ae6 ("of/platform: Add common method to populate default bus") Signed-off-by: Ray Jui Tested-by: Eric Anholt Signed-off-by: Linus Walleij Signed-off-by: Greg Kroah-Hartman

pinctrl: cherryview: Prevent possible interrupt storm on resume

2016-11-18T09:51:46Z

commit d2cdf5dc58f6970e9d9d26e47974c21fe87983f3 upstream. When the system is suspended to S3 the BIOS might re-initialize certain GPIO pins back to their original state or it may re-program interrupt mask of others. For example Acer TravelMate B116-M had BIOS bug where certain GPIO pin (MF_ISH_GPIO_5) was programmed to trigger on high level, and the pin state was high once the BIOS gave control to the OS on resume. This triggers lots of messages like: irq 117, desc: ffff88017a61e600, depth: 1, count: 0, unhandled: 0 ->handle_irq(): ffffffff8109b613, handle_bad_irq+0x0/0x1e0 ->irq_data.chip(): ffffffffa0020180, chv_pinctrl_exit+0x2d84/0x12 [pinctrl_cherryview] ->action(): (null) IRQ_NOPROBE set We reset the mask back to known state in chv_pinctrl_resume() but that is called only after device interrupts have already been enabled. Now, this particular issue was fixed by upgrading the BIOS to the latest (v1.23) but not everybody upgrades their BIOSes so we fix it up in the driver as well. Prevent the possible interrupt storm by moving suspend and resume hooks to be called at _noirq time instead. Since device interrupts are still disabled we can restore the mask back to known state before interrupt storm happens. Reported-by: Christian Steiner Signed-off-by: Mika Westerberg Signed-off-by: Linus Walleij Signed-off-by: Greg Kroah-Hartman

pinctrl: cherryview: Serialize register access in suspend/resume

2016-11-18T09:51:45Z

commit 56211121c0825cd188caad05574fdc518d5cac6f upstream. If async suspend is enabled, the driver may access registers concurrently with another instance which may fail because of the bug in Cherryview GPIO hardware. Prevent this by taking the shared lock while accessing the hardware in suspend and resume hooks. Signed-off-by: Mika Westerberg Signed-off-by: Linus Walleij Signed-off-by: Greg Kroah-Hartman

pinctrl: qcom: fix masking of pinmux functions

2016-10-31T11:02:14Z

commit 6bcf3f63394b9c4f133e4499349d786d7f531473 upstream. The following commit introduced a regression by not properly masking the calculated value. Fixes: 47a01ee9a6c3 ("pinctrl: qcom: Clear all function selection bits") Signed-off-by: John Crispin Reviewed-by: Bjorn Andersson Reviewed-by: Stephen Boyd Signed-off-by: Linus Walleij Signed-off-by: Greg Kroah-Hartman

pinctrl: baytrail: Fix lockdep

2016-10-28T07:45:28Z

commit a171bc51fa697021e1b2082d7e95c12a363bc0a9 upstream. Initialize the spinlock before using it. INFO: trying to register non-static key. the code is fine but needs lockdep annotation. turning off the locking correctness validator. CPU: 2 PID: 1 Comm: swapper/0 Not tainted 4.8.0-dwc-bisect #4 Hardware name: Intel Corp. VALLEYVIEW C0 PLATFORM/BYT-T FFD8, BIOS BLAKFF81.X64.0088.R10.1403240443 FFD8_X64_R_2014_13_1_00 03/24/2014 0000000000000000 ffff8800788ff770 ffffffff8133d597 0000000000000000 0000000000000000 ffff8800788ff7e0 ffffffff810cfb9e 0000000000000002 ffff8800788ff7d0 ffffffff8205b600 0000000000000002 ffff8800788ff7f0 Call Trace: [] dump_stack+0x67/0x90 [] register_lock_class+0x52e/0x540 [] __lock_acquire+0x81/0x16b0 [] ? save_trace+0x41/0xd0 [] ? __lock_acquire+0x13b2/0x16b0 [] ? __lock_is_held+0x4a/0x70 [] lock_acquire+0xba/0x220 [] ? byt_gpio_get_direction+0x3e/0x80 [] _raw_spin_lock_irqsave+0x47/0x60 [] ? byt_gpio_get_direction+0x3e/0x80 [] byt_gpio_get_direction+0x3e/0x80 [] gpiochip_add_data+0x319/0x7d0 [] ? _raw_spin_unlock_irqrestore+0x43/0x70 [] byt_pinctrl_probe+0x2fb/0x620 [] platform_drv_probe+0x3c/0xa0 ... Based on the diff it looks like the problem was introduced in commit 71e6ca61e826 ("pinctrl: baytrail: Register pin control handling") but I wasn't able to verify that empirically as the parent commit just oopsed when I tried to boot it. Cc: Cristina Ciocan Fixes: 71e6ca61e826 ("pinctrl: baytrail: Register pin control handling") Signed-off-by: Ville Syrjälä Acked-by: Mika Westerberg Signed-off-by: Linus Walleij Signed-off-by: Greg Kroah-Hartman

pinctrl: intel: Only restore pins that are used by the driver

2016-10-28T07:45:28Z

commit c538b9436751a0be2e1246b48353bc23156bdbcc upstream. Dell XPS 13 (and maybe some others) uses a GPIO (CPU_GP_1) during suspend to explicitly disable USB touchscreen interrupt. This is done to prevent situation where the lid is closed the touchscreen is left functional. The pinctrl driver (wrongly) assumes it owns all pins which are owned by host and not locked down. It is perfectly fine for BIOS to use those pins as it is also considered as host in this context. What happens is that when the lid of Dell XPS 13 is closed, the BIOS configures CPU_GP_1 low disabling the touchscreen interrupt. During resume we restore all host owned pins to the known state which includes CPU_GP_1 and this overwrites what the BIOS has programmed there causing the touchscreen to fail as no interrupts are reaching the CPU anymore. Fix this by restoring only those pins we know are explicitly requested by the kernel one way or other. Link: https://bugzilla.kernel.org/show_bug.cgi?id=176361 Reported-by: AceLan Kao Tested-by: AceLan Kao Signed-off-by: Mika Westerberg Signed-off-by: Linus Walleij Signed-off-by: Greg Kroah-Hartman

pinctrl: sunxi: fix uart1 CTS/RTS pins at PG on A23/A33

2016-08-23T10:28:31Z

PG8, PG9 is said to be the CTS/RTS pins for UART1 according to the A23/33 datasheets. However, the function is wrongly named "uart2" in the pinctrl driver. This patch fixes this by modifying them to be named "uart1". Cc: stable@vger.kernel.org Signed-off-by: Icenowy Zheng Acked-by: Maxime Ripard Signed-off-by: Linus Walleij

pinctrl: cherryview: Do not mask all interrupts in probe

2016-08-22T13:57:04Z

The Cherryview GPIO controller has 8 or 16 wires connected to the I/O-APIC which can be used directly by the platform/BIOS or drivers. One such wire is used as SCI (System Control Interrupt) which ACPI depends on to be able to trigger GPEs (General Purpose Events). The pinctrl driver itself uses another IRQ resource which is wire OR of all the 8 (or 16) wires and follows what BIOS has programmed to the IntSel register of each pin. Currently the driver masks all interrupts at probe time and this prevents these direct interrupts from working as expected. The reason for this is that some early stage prototypes had some pins misconfigured causing lots of spurious interrupts. We fix this by leaving the interrupt mask untouched. This allows SCI and other direct interrupts work properly. What comes to the possible spurious interrupts we switch the default handler to be handle_bad_irq() instead of handle_simple_irq() (which was not correct anyway). Reported-by: Yu C Chen Reported-by: Anisse Astier Signed-off-by: Mika Westerberg Signed-off-by: Linus Walleij

pinctrl: pistachio: fix mfio pll_lock pinmux

2016-08-22T13:28:35Z

A previous patch attempted to fix the pinmuxes for mfio 84 - 89, but it omitted a change to pistachio_pin_group pistachio_groups, which results in incorrect pll_lock signals being routed. Apply the correct mux settings throughout the driver. fixes: cefc03e5995e ("pinctrl: Add Pistachio SoC pin control driver") fixes: e9adb336d0bf ("pinctrl: pistachio: fix mfio84-89 function description and pinmux.") Cc: # 4.4.x- Signed-off-by: James Hartley Reviewed-by: Sifan Naeem Signed-off-by: Linus Walleij

pinctrl: intel: merrifield: Add missed header

2016-08-10T13:46:28Z

On x86 builds the absense of makes static analyzer and compiler unhappy which fails to build the driver. CHECK drivers/pinctrl/intel/pinctrl-merrifield.c drivers/pinctrl/intel/pinctrl-merrifield.c:518:17: error: undefined identifier 'readl' drivers/pinctrl/intel/pinctrl-merrifield.c:570:17: error: undefined identifier 'readl' drivers/pinctrl/intel/pinctrl-merrifield.c:575:9: error: undefined identifier 'writel' drivers/pinctrl/intel/pinctrl-merrifield.c:645:17: error: undefined identifier 'readl' CC drivers/pinctrl/intel/pinctrl-merrifield.o drivers/pinctrl/intel/pinctrl-merrifield.c: In function ‘mrfld_pin_dbg_show’: drivers/pinctrl/intel/pinctrl-merrifield.c:518:10: error: implicit declaration of function ‘readl’ [-Werror=implicit-function-declaration] value = readl(bufcfg); ^ drivers/pinctrl/intel/pinctrl-merrifield.c: In function ‘mrfld_update_bufcfg’: drivers/pinctrl/intel/pinctrl-merrifield.c:575:2: error: implicit declaration of function ‘writel’ [-Werror=implicit-function-declaration] writel(value, bufcfg); ^ cc1: some warnings being treated as errors Add header to the top of the module. Fixes: 4e80c8f50574 ("pinctrl: intel: Add Intel Merrifield pin controller support") Signed-off-by: Andy Shevchenko Signed-off-by: Linus Walleij