kernel/drivers/pinctrl/intel/pinctrl-intel.c, branch linux-5.1.y

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

2019-06-22T06:09:07Z

[ Upstream commit 670784fb4ebe54434e263837390e358405031d9e ] 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 Signed-off-by: Sasha Levin

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

2019-06-15T09:53:03Z

[ Upstream commit 2fef32766861c6e171f436ab99c89198cf0ca6e1 ] 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 Signed-off-by: Sasha Levin

pinctrl: intel: Unexport intel_pinctrl_probe()

2018-11-08T15:16:40Z

Since there are no more users, unexport it and make static. Signed-off-by: Andy Shevchenko Acked-by: Mika Westerberg

pinctrl: intel: simplify getting .driver_data

2018-11-08T15:16:33Z

We should get 'driver_data' from 'struct device' directly. Going via platform_device is an unneeded step back and forth. Signed-off-by: Wolfram Sang Acked-by: Mika Westerberg Acked-by: Linus Walleij Signed-off-by: Andy Shevchenko

pinctrl: intel: Fix a spelling typo in kernel documentation

2018-10-03T07:05:35Z

The parameter 'community' had been spelled incorrectly. Fix it here. As a side effect it satisfies static checkers that issue the following warnings: drivers/pinctrl/intel/pinctrl-intel.c:845: warning: Function parameter or member 'community' not described in 'intel_gpio_to_pin' drivers/pinctrl/intel/pinctrl-intel.c:845: warning: Excess function parameter 'commmunity' description in 'intel_gpio_to_pin' Signed-off-by: Andy Shevchenko Acked-by: Mika Westerberg Signed-off-by: Linus Walleij

pinctrl: intel: Convert unsigned to unsigned int

2018-10-03T07:05:21Z

Simple type conversion with no functional change implied. Signed-off-by: Andy Shevchenko Acked-by: Mika Westerberg Signed-off-by: Linus Walleij

Merge tag 'v4.19-rc6' into devel

2018-10-01T11:20:45Z

This is the 4.19-rc6 release I needed to merge this in because of extensive conflicts in the MSM and Intel pin control drivers. I know how to resolve them, so let's do it like this. Signed-off-by: Linus Walleij

Revert "pinctrl: intel: Do pin translation when lock IRQ"

2018-09-25T10:50:00Z

This reverts commit 55aedef50d4d810670916d9fce4a40d5da2079e7. Commit 55aedef50d4d ("pinctrl: intel: Do pin translation when lock IRQ") added special translation from GPIO number to hardware pin number to irq_reqres/relres hooks to avoid failure when IRQs are requested. The actual failure happened inside gpiochip_lock_as_irq() because it calls gpiod_get_direction() and pinctrl-intel.c::intel_gpio_get_direction() implementation originally missed the translation so the two hooks made it work by skipping the ->get_direction() call entirely (it overwrote the default GPIOLIB provided functions). The proper fix that adds translation to GPIO callbacks was merged with commit 96147db1e1df ("pinctrl: intel: Do pin translation in other GPIO operations as well"). This allows us to use the default GPIOLIB provided functions again. In addition as find out by Benjamin Tissoires the two functions (intel_gpio_irq_reqres()/intel_gpio_irq_relres()) now cause problems of their own because they operate on pin numbers and pass that pin number to gpiochip_lock_as_irq() which actually expects a GPIO number. Link: https://bugzilla.kernel.org/show_bug.cgi?id=199911 Fixes: 55aedef50d4d ("pinctrl: intel: Do pin translation when lock IRQ") Reported-and-tested-by: Benjamin Tissoires Signed-off-by: Mika Westerberg Acked-by: Andy Shevchenko Signed-off-by: Linus Walleij

pinctrl: intel: Do pin translation in other GPIO operations as well

2018-09-20T15:21:52Z

For some reason I thought GPIOLIB handles translation from GPIO ranges to pinctrl pins but it turns out not to be the case. This means that when GPIOs operations are performed for a pin controller having a custom GPIO base such as Cannon Lake and Ice Lake incorrect pin number gets used internally. Fix this in the same way we did for lock/unlock IRQ operations and translate the GPIO number to pin before using it. Fixes: a60eac3239f0 ("pinctrl: intel: Allow custom GPIO base for pad groups") Reported-by: Rajat Jain Signed-off-by: Mika Westerberg Tested-by: Rajat Jain Signed-off-by: Linus Walleij

pinctrl: intel: Introduce intel_pinctrl_probe_by_hid() internal API

2018-08-31T09:25:11Z

Introduce intel_pinctrl_probe_by_hid() internal API to simplify drivers, which are using ACPI _HID to distinguish which SoC data needs to be used when being probed. Signed-off-by: Andy Shevchenko Acked-by: Mika Westerberg Signed-off-by: Linus Walleij