linux/drivers/pinctrl/intel, branch v5.2

pinctrl: intel: Clear interrupt status in mask/unmask callback

2019-05-20T12:04:25Z

Commit a939bb57cd47 ("pinctrl: intel: implement gpio_irq_enable") was added because clearing interrupt status bit is required to avoid unexpected behavior. Turns out the unmask callback also needs the fix, which can solve weird IRQ triggering issues on I2C touchpad ELAN1200. Signed-off-by: Kai-Heng Feng Signed-off-by: Andy Shevchenko

pinctrl: intel: Use GENMASK() consistently

2019-05-20T12:04:25Z

Use GENMASK() macro for all definitions. No functional change intended. Signed-off-by: Andy Shevchenko

pinctrl: intel: Increase readability of intel_gpio_update_pad_mode()

2019-04-28T17:19:06Z

We better to use usual pattern for read-modify-update, than doing some operations in definition block. No functional change. Signed-off-by: Andy Shevchenko

pinctrl: intel: Retain HOSTSW_OWN for requested gpio pin

2019-04-28T17:10:06Z

The touchpad of the ASUS laptops E403NA, X540NA, X541NA are not responsive after suspend/resume. The following error message shows after resume. i2c_hid i2c-ELAN1200:00: failed to reset device. On these laptops, the touchpad interrupt is connected via a GPIO pin which is controlled by Intel pinctrl. After system resumes, the GPIO is in ACPI mode and no longer works as an IRQ. This commit saves the HOSTSW_OWN value during suspend, make sure the HOSTSW_OWN mode remains the same after resume. Signed-off-by: Chris Chiu Acked-by: Mika Westerberg Signed-off-by: Andy Shevchenko

pinctrl: pinctrl-intel: move gpio suspend/resume to noirq phase

2019-04-09T15:26:44Z

In current driver, SET_LATE_SYSTEM_SLEEP_PM_OPS is used to install the callbacks for suspend/resume. GPIO pin may be used as the interrupt pin by some device. However, using SET_LATE_SYSTEM_SLEEP_PM_OPS() to install the callbacks, the resume callback is called after resume_device_irqs(). Unintended interrupts may arrive due to resuming device irqs first, but the GPIO controller is not properly restored. Normally, for a SMP system, there are multiple cores, so even when there are unintended interrupts, BSP gets the chance to initialize the GPIO chip soon. But when there is only 1 core is active (other cores are offlined or single core) during resume, it is more easily to observe the unintended interrupts. This patch renames the suspend/resume function by adding suffix "_noirq", and installs the callbacks using SET_NOIRQ_SYSTEM_SLEEP_PM_OPS(). Signed-off-by: Binbin Wu Acked-by: Mika Westerberg Signed-off-by: Andy Shevchenko

pinctrl: cedarfork: Update pin names according to v1.13c

2019-04-03T11:49:47Z

Version 1.13c of pin list has some changes in pin names for Intel Cedarfork. Update the driver accordingly. Signed-off-by: Andy Shevchenko Acked-by: Mika Westerberg Acked-by: Linus Walleij

pinctrl: baytrail: Fix potential NULL pointer dereference

2019-03-18T09:43:23Z

saved-context in byt_gpio_probe is allocated via devm_kcalloc and is used without checking for NULL in later functions. This patch avoids such a scenario. Signed-off-by: Aditya Pakki Signed-off-by: Andy Shevchenko

pinctrl: cherryview: fix Strago DMI workaround

2019-01-21T12:05:42Z

Well, hopefully 3rd time is a charm. We tried making that check DMI_BIOS_VERSION and DMI_BOARD_VERSION, but the real one is DMI_PRODUCT_VERSION. Fixes: 86c5dd6860a6 ("pinctrl: cherryview: limit Strago DMI workarounds to version 1.0") Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=197953 Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1631930 Cc: stable@vger.kernel.org Signed-off-by: Dmitry Torokhov Reviewed-by: Andy Shevchenko Acked-by: Mika Westerberg Signed-off-by: Linus Walleij

pinctrl: cherryview: Stop clearing the GPIO_EN bit from chv_gpio_disable_free

2018-12-05T12:11:05Z

Clearing the GPIO_EN bit from chv_gpio_disable_free is a bad idea and pinctrl-cherryview.c is the only Intel pinctrl driver doing something like this. Clearing the GPIO_EN bit means that if the pin was an output it is now effectively floating. The datasheet is not clear what happens to pull ups / downs in this case, but from testing it looks like these are disabled too, also floating input pins. One example where this is causing issues is the soc_button_array input driver, this parses ACPI tables to create 2 platform devices for the gpio_keys input driver. The list of GPIOs is passed through struct gpio_keys_platform_data which uses gpio numbers rather then gpio_desc pointers. The buttons handled by this drivers short the pin to ground when pressed and the volume buttons rely on the SoC's internal pull-up to pull the pin high when the button is not pressed. To get the gpio number, the soc_button_array code calls gpiod_get_index followed by a desc_to_gpio call and then gpiod_put on the gpio_desc. This last call causes chv_gpio_disable_free to clear the GPIO_EN bit. When the gpio_keys driver then loads next it gets the gpio_desc again causing the GPIO_EN bit to be set again and immediately reads the GPIO value which for the volume buttons reads 0 at this time, causing a spurious press of the volume buttons to get reported. Putting a small delay between the gpio_desc request and the read fixes this, I assume that this is caused by the pull-up being temporarily disabled while the GPIO_EN bit is cleared as the powerbutton which also has its GPIO_EN bit cleared does not have this problem. The soc_button_array code is not the only code temporarily requesting GPIOs the DWC3 PCI code also does this, to set the enable and reset GPIOs for the external phy, so that the code instantiating the ULPI phy can read the vendor and product ID registers from the phy. These GPIOs are released after this so that the PHY driver can claim and use them when it loads. Another example of temporary GPIO usage would be a user-space set_gpio utility using the userspace ioctls to set a GPIO as output value 0 or 1, having the GPIO revert to floating as soon as this utility exits would certainly be unexpected behavior. One argument in favor of clearing the GPIO_EN bit is if the GPIO is going to be muxed to another function after being released, but in that case chv_pinmux_set_mux() already clears it. TL;DR: Clearing the GPIO_EN bit from is a bad idea, this commit therefor removes the clearing from chv_gpio_disable_free(), replacing it with code to clear the interrupt-trigger condition so that the GPIO stops generating interrupts when released, as pinctrl-baytrail.c does. Note this commit adds a !chv_pad_locked() condition to the trigger clearing call, which the original GPIO_EN clearing code was missing. Signed-off-by: Hans de Goede Acked-by: Mika Westerberg Signed-off-by: Andy Shevchenko

pinctrl: cherryview: Add chv_gpio_clear_triggering() helper function

2018-12-05T12:11:05Z

This is a preparation patch for clearing the interrupt trigger from chv_gpio_disable_free(). Signed-off-by: Hans de Goede Acked-by: Mika Westerberg Signed-off-by: Andy Shevchenko