user/sven/linux.git/drivers/pinctrl, branch v5.4.111

pinctrl: rockchip: fix restore error in resume

2021-04-07T12:47:43Z

commit c971af25cda94afe71617790826a86253e88eab0 upstream. The restore in resume should match to suspend which only set for RK3288 SoCs pinctrl. Fixes: 8dca933127024 ("pinctrl: rockchip: save and restore gpio6_c6 pinmux in suspend/resume") Reviewed-by: Jianqun Xu Reviewed-by: Heiko Stuebner Signed-off-by: Wang Panzhenzhuan Signed-off-by: Jianqun Xu Link: https://lore.kernel.org/r/20210223100725.269240-1-jay.xu@rock-chips.com Signed-off-by: Linus Walleij Signed-off-by: Greg Kroah-Hartman

pinctrl: ingenic: Fix JZ4760 support

2021-01-27T10:47:52Z

commit 9a85c09a3f507b925d75cb0c7c8f364467038052 upstream. - JZ4760 and JZ4760B have a similar register layout as the JZ4740, and don't use the new register layout, which was introduced with the JZ4770 SoC and not the JZ4760 or JZ4760B SoCs. - The JZ4740 code path only expected two function modes to be configurable for each pin, and wouldn't work with more than two. Fix it for the JZ4760, which has four configurable function modes. Fixes: 0257595a5cf4 ("pinctrl: Ingenic: Add pinctrl driver for JZ4760 and JZ4760B.") Cc: # 5.3 Signed-off-by: Paul Cercueil Link: https://lore.kernel.org/r/20201211232810.261565-1-paul@crapouillou.net Signed-off-by: Linus Walleij Signed-off-by: Greg Kroah-Hartman

pinctrl: aspeed: g6: Fix PWMG0 pinctrl setting

2021-01-27T10:47:47Z

[ Upstream commit 92ff62a7bcc17d47c0ce8dddfb7a6e1a2e55ebf4 ] The SCU offset for signal PWM8 in group PWM8G0 is wrong, fix it from SCU414 to SCU4B4. Signed-off-by: Billy Tsai Fixes: 2eda1cdec49f ("pinctrl: aspeed: Add AST2600 pinmux support") Reviewed-by: Joel Stanley Reviewed-by: Andrew Jeffery Link: https://lore.kernel.org/r/20201217024912.3198-1-billy_tsai@aspeedtech.com Signed-off-by: Linus Walleij Signed-off-by: Sasha Levin

pinctrl: sunxi: Always call chained_irq_{enter, exit} in sunxi_pinctrl_irq_handler

2020-12-30T10:51:45Z

commit a1158e36f876f6269978a4176e3a1d48d27fe7a1 upstream. It is found on many allwinner soc that there is a low probability that the interrupt status cannot be read in sunxi_pinctrl_irq_handler. This will cause the interrupt status of a gpio bank to always be active on gic, preventing gic from responding to other spi interrupts correctly. So we should call the chained_irq_* each time enter sunxi_pinctrl_irq_handler(). Signed-off-by: Yangtao Li Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/85263ce8b058e80cea25c6ad6383eb256ce96cc8.1604988979.git.frank@allwinnertech.com Signed-off-by: Linus Walleij Signed-off-by: Greg Kroah-Hartman

pinctrl: falcon: add missing put_device() call in pinctrl_falcon_probe()

2020-12-30T10:51:18Z

[ Upstream commit 89cce2b3f247a434ee174ab6803698041df98014 ] if of_find_device_by_node() succeed, pinctrl_falcon_probe() doesn't have a corresponding put_device(). Thus add put_device() to fix the exception handling for this function implementation. Fixes: e316cb2b16bb ("OF: pinctrl: MIPS: lantiq: adds support for FALCON SoC") Signed-off-by: Yu Kuai Link: https://lore.kernel.org/r/20201119011219.2248232-1-yukuai3@huawei.com Signed-off-by: Linus Walleij Signed-off-by: Sasha Levin

pinctrl: aspeed: Fix GPIO requests on pass-through banks

2020-12-30T10:50:54Z

[ Upstream commit 7aeb353802611a8e655e019f09a370ff682af1a6 ] Commit 6726fbff19bf ("pinctrl: aspeed: Fix GPI only function problem.") fixes access to GPIO banks T and U on the AST2600. Both banks contain input-only pins and the GPIO pin function is named GPITx and GPIUx respectively. Unfortunately the fix had a negative impact on GPIO banks D and E for the AST2400 and AST2500 where the GPIO pass-through functions take similar "GPI"-style names. The net effect on the older SoCs was that when the GPIO subsystem requested a pin in banks D or E be muxed for GPIO, they were instead muxed for pass-through mode. Mistakenly muxing pass-through mode e.g. breaks booting the host on IBM's Witherspoon (AC922) platform where GPIOE0 is used for FSI. Further exploit the names in the provided expression structure to differentiate pass-through from pin-specific GPIO modes. This follow-up fix gives the expected behaviour for the following tests: Witherspoon BMC (AST2500): 1. Power-on the Witherspoon host 2. Request GPIOD1 be muxed via /sys/class/gpio/export 3. Request GPIOE1 be muxed via /sys/class/gpio/export 4. Request the balls for GPIOs E2 and E3 be muxed as GPIO pass-through ("GPIE2" mode) via a pinctrl hog in the devicetree Rainier BMC (AST2600): 5. Request GPIT0 be muxed via /sys/class/gpio/export 6. Request GPIU0 be muxed via /sys/class/gpio/export Together the tests demonstrate that all three pieces of functionality (general GPIOs via 1, 2 and 3, input-only GPIOs via 5 and 6, pass-through mode via 4) operate as desired across old and new SoCs. Fixes: 9b92f5c51e9a ("pinctrl: aspeed: Fix GPI only function problem.") Signed-off-by: Andrew Jeffery Tested-by: Joel Stanley Reviewed-by: Joel Stanley Cc: Billy Tsai Cc: Joel Stanley Link: https://lore.kernel.org/r/20201126063337.489927-1-andrew@aj.id.au Signed-off-by: Linus Walleij Signed-off-by: Sasha Levin

pinctrl: baytrail: Avoid clearing debounce value when turning it off

2020-12-30T10:50:52Z

[ Upstream commit 0b74e40a4e41f3cbad76dff4c50850d47b525b26 ] Baytrail pin control has a common register to set up debounce timeout. When a pin configuration requested debounce to be disabled, the rest of the pins may still want to have debounce enabled and thus rely on the common timeout value. Avoid clearing debounce value when turning it off for one pin while others may still use it. Fixes: 658b476c742f ("pinctrl: baytrail: Add debounce configuration") Depends-on: 04ff5a095d66 ("pinctrl: baytrail: Rectify debounce support") Depends-on: 827e1579e1d5 ("pinctrl: baytrail: Rectify debounce support (part 2)") Signed-off-by: Andy Shevchenko Acked-by: Mika Westerberg Signed-off-by: Sasha Levin

pinctrl: merrifield: Set default bias in case no particular value given

2020-12-30T10:50:52Z

[ Upstream commit 0fa86fc2e28227f1e64f13867e73cf864c6d25ad ] When GPIO library asks pin control to set the bias, it doesn't pass any value of it and argument is considered boolean (and this is true for ACPI GpioIo() / GpioInt() resources, by the way). Thus, individual drivers must behave well, when they got the resistance value of 1 Ohm, i.e. transforming it to sane default. In case of Intel Merrifield pin control hardware the 20 kOhm sounds plausible because it gives a good trade off between weakness and minimization of leakage current (will be only 50 uA with the above choice). Fixes: 4e80c8f50574 ("pinctrl: intel: Add Intel Merrifield pin controller support") Depends-on: 2956b5d94a76 ("pinctrl / gpio: Introduce .set_config() callback for GPIO chips") Signed-off-by: Andy Shevchenko Acked-by: Mika Westerberg Signed-off-by: Sasha Levin

pinctrl: amd: remove debounce filter setting in IRQ type setting

2020-12-16T09:56:58Z

commit 47a0001436352c9853d72bf2071e85b316d688a2 upstream. Debounce filter setting should be independent from IRQ type setting because according to the ACPI specs, there are separate arguments for specifying debounce timeout and IRQ type in GpioIo() and GpioInt(). Together with commit 06abe8291bc31839950f7d0362d9979edc88a666 ("pinctrl: amd: fix incorrect way to disable debounce filter") and Andy's patch "gpiolib: acpi: Take into account debounce settings" [1], this will fix broken touchpads for laptops whose BIOS set the debounce timeout to a relatively large value. For example, the BIOS of Lenovo AMD gaming laptops including Legion-5 15ARH05 (R7000), Legion-5P (R7000P) and IdeaPad Gaming 3 15ARH05, set the debounce timeout to 124.8ms. This led to the kernel receiving only ~7 HID reports per second from the Synaptics touchpad (MSFT0001:00 06CB:7F28). Existing touchpads like [2][3] are not troubled by this bug because the debounce timeout has been set to 0 by the BIOS before enabling the debounce filter in setting IRQ type. [1] https://lore.kernel.org/linux-gpio/20201111222008.39993-11-andriy.shevchenko@linux.intel.com/ 8dcb7a15a585 ("gpiolib: acpi: Take into account debounce settings") [2] https://github.com/Syniurge/i2c-amd-mp2/issues/11#issuecomment-721331582 [3] https://forum.manjaro.org/t/random-short-touchpad-freezes/30832/28 Signed-off-by: Coiby Xu Reviewed-by: Andy Shevchenko Cc: Hans de Goede Cc: Andy Shevchenko Cc: Benjamin Tissoires Cc: stable@vger.kernel.org Link: https://lore.kernel.org/linux-gpio/CAHp75VcwiGREBUJ0A06EEw-SyabqYsp%2Bdqs2DpSrhaY-2GVdAA%40mail.gmail.com/ BugLink: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1887190 Link: https://lore.kernel.org/r/20201125130320.311059-1-coiby.xu@gmail.com Signed-off-by: Linus Walleij Signed-off-by: Greg Kroah-Hartman

pinctrl: baytrail: Fix pin being driven low for a while on gpiod_get(..., GPIOD_OUT_HIGH)

2020-12-11T12:23:27Z

commit 156abe2961601d60a8c2a60c6dc8dd6ce7adcdaf upstream The pins on the Bay Trail SoC have separate input-buffer and output-buffer enable bits and a read of the level bit of the value register will always return the value from the input-buffer. The BIOS of a device may configure a pin in output-only mode, only enabling the output buffer, and write 1 to the level bit to drive the pin high. This 1 written to the level bit will be stored inside the data-latch of the output buffer. But a subsequent read of the value register will return 0 for the level bit because the input-buffer is disabled. This causes a read-modify-write as done by byt_gpio_set_direction() to write 0 to the level bit, driving the pin low! Before this commit byt_gpio_direction_output() relied on pinctrl_gpio_direction_output() to set the direction, followed by a call to byt_gpio_set() to apply the selected value. This causes the pin to go low between the pinctrl_gpio_direction_output() and byt_gpio_set() calls. Change byt_gpio_direction_output() to directly make the register modifications itself instead. Replacing the 2 subsequent writes to the value register with a single write. Note that the pinctrl code does not keep track internally of the direction, so not going through pinctrl_gpio_direction_output() is not an issue. This issue was noticed on a Trekstor SurfTab Twin 10.1. When the panel is already on at boot (no external monitor connected), then the i915 driver does a gpiod_get(..., GPIOD_OUT_HIGH) for the panel-enable GPIO. The temporarily going low of that GPIO was causing the panel to reset itself after which it would not show an image until it was turned off and back on again (until a full modeset was done on it). This commit fixes this. This commit also updates the byt_gpio_direction_input() to use direct register accesses instead of going through pinctrl_gpio_direction_input(), to keep it consistent with byt_gpio_direction_output(). Note for backporting, this commit depends on: commit e2b74419e5cc ("pinctrl: baytrail: Replace WARN with dev_info_once when setting direct-irq pin to output") Cc: stable@vger.kernel.org Fixes: 86e3ef812fe3 ("pinctrl: baytrail: Update gpio chip operations") Signed-off-by: Hans de Goede Acked-by: Mika Westerberg Signed-off-by: Andy Shevchenko [sudip: use byt_gpio and vg->pdev->dev for dev_info()] Signed-off-by: Sudip Mukherjee Signed-off-by: Sasha Levin