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

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

2020-12-29T12:42:38Z

[ 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: amd: remove debounce filter setting in IRQ type setting

2020-12-29T12:42:31Z

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: rockchip: enable gpio pclk for rockchip_gpio_to_irq

2020-11-24T11:48:10Z

[ Upstream commit 63fbf8013b2f6430754526ef9594f229c7219b1f ] There need to enable pclk_gpio when do irq_create_mapping, since it will do access to gpio controller. Signed-off-by: Jianqun Xu Reviewed-by: Heiko Stuebner Reviewed-by: Kever Yang Link: https://lore.kernel.org/r/20201013063731.3618-3-jay.xu@rock-chips.com Signed-off-by: Linus Walleij Signed-off-by: Sasha Levin

pinctrl: amd: fix incorrect way to disable debounce filter

2020-11-18T17:25:01Z

commit 06abe8291bc31839950f7d0362d9979edc88a666 upstream. The correct way to disable debounce filter is to clear bit 5 and 6 of the register. Cc: stable@vger.kerne.org Signed-off-by: Coiby Xu Reviewed-by: Hans de Goede Cc: Hans de Goede Link: https://lore.kernel.org/linux-gpio/df2c008b-e7b5-4fdd-42ea-4d1c62b52139@redhat.com/ Link: https://lore.kernel.org/r/20201105231912.69527-2-coiby.xu@gmail.com Signed-off-by: Linus Walleij Signed-off-by: Greg Kroah-Hartman

pinctrl: amd: use higher precision for 512 RtcClk

2020-11-18T17:25:01Z

commit c64a6a0d4a928c63e5bc3b485552a8903a506c36 upstream. RTC is 32.768kHz thus 512 RtcClk equals 15625 usec. The documentation likely has dropped precision and that's why the driver mistakenly took the slightly deviated value. Cc: stable@vger.kernel.org Reported-by: Andy Shevchenko Suggested-by: Andy Shevchenko Suggested-by: Hans de Goede Signed-off-by: Coiby Xu Reviewed-by: Andy Shevchenko Reviewed-by: Hans de Goede Link: https://lore.kernel.org/linux-gpio/2f4706a1-502f-75f0-9596-cc25b4933b6c@redhat.com/ Link: https://lore.kernel.org/r/20201105231912.69527-3-coiby.xu@gmail.com Signed-off-by: Linus Walleij Signed-off-by: Greg Kroah-Hartman

pinctrl: devicetree: Avoid taking direct reference to device name string

2020-11-18T17:24:58Z

commit be4c60b563edee3712d392aaeb0943a768df7023 upstream. When populating the pinctrl mapping table entries for a device, the 'dev_name' field for each entry is initialised to point directly at the string returned by 'dev_name()' for the device and subsequently used by 'create_pinctrl()' when looking up the mappings for the device being probed. This is unreliable in the presence of calls to 'dev_set_name()', which may reallocate the device name string leaving the pinctrl mappings with a dangling reference. This then leads to a use-after-free every time the name is dereferenced by a device probe: | BUG: KASAN: invalid-access in strcmp+0x20/0x64 | Read of size 1 at addr 13ffffc153494b00 by task modprobe/590 | Pointer tag: [13], memory tag: [fe] | | Call trace: | __kasan_report+0x16c/0x1dc | kasan_report+0x10/0x18 | check_memory_region | __hwasan_load1_noabort+0x4c/0x54 | strcmp+0x20/0x64 | create_pinctrl+0x18c/0x7f4 | pinctrl_get+0x90/0x114 | devm_pinctrl_get+0x44/0x98 | pinctrl_bind_pins+0x5c/0x450 | really_probe+0x1c8/0x9a4 | driver_probe_device+0x120/0x1d8 Follow the example of sysfs, and duplicate the device name string before stashing it away in the pinctrl mapping entries. Cc: Linus Walleij Reported-by: Elena Petrova Tested-by: Elena Petrova Signed-off-by: Will Deacon Link: https://lore.kernel.org/r/20191002124206.22928-1-will@kernel.org Signed-off-by: Linus Walleij [bwh: Backported to 4.4: adjust context] Signed-off-by: Ben Hutchings Signed-off-by: Sasha Levin

pinctrl-single: fix pcs_parse_pinconf() return value

2020-08-21T08:53:03Z

[ Upstream commit f46fe79ff1b65692a65266a5bec6dbe2bf7fc70f ] This patch causes pcs_parse_pinconf() to return -ENOTSUPP when no pinctrl_map is added. The current behavior is to return 0 when !PCS_HAS_PINCONF or !nconfs. Thus pcs_parse_one_pinctrl_entry() incorrectly assumes that a map was added and sets num_maps = 2. Analysis: ========= The function pcs_parse_one_pinctrl_entry() calls pcs_parse_pinconf() if PCS_HAS_PINCONF is enabled. The function pcs_parse_pinconf() returns 0 to indicate there was no error and num_maps is then set to 2: 980 static int pcs_parse_one_pinctrl_entry(struct pcs_device *pcs, 981 struct device_node *np, 982 struct pinctrl_map **map, 983 unsigned *num_maps, 984 const char **pgnames) 985 { 1053 (*map)->type = PIN_MAP_TYPE_MUX_GROUP; 1054 (*map)->data.mux.group = np->name; 1055 (*map)->data.mux.function = np->name; 1056 1057 if (PCS_HAS_PINCONF && function) { 1058 res = pcs_parse_pinconf(pcs, np, function, map); 1059 if (res) 1060 goto free_pingroups; 1061 *num_maps = 2; 1062 } else { 1063 *num_maps = 1; 1064 } However, pcs_parse_pinconf() will also return 0 if !PCS_HAS_PINCONF or !nconfs. I believe these conditions should indicate that no map was added by returning -ENOTSUPP. Otherwise pcs_parse_one_pinctrl_entry() will set num_maps = 2 even though no maps were successfully added, as it does not reach "m++" on line 940: 895 static int pcs_parse_pinconf(struct pcs_device *pcs, struct device_node *np, 896 struct pcs_function *func, 897 struct pinctrl_map **map) 898 899 { 900 struct pinctrl_map *m = *map; 917 /* If pinconf isn't supported, don't parse properties in below. */ 918 if (!PCS_HAS_PINCONF) 919 return 0; 920 921 /* cacluate how much properties are supported in current node */ 922 for (i = 0; i < ARRAY_SIZE(prop2); i++) { 923 if (of_find_property(np, prop2[i].name, NULL)) 924 nconfs++; 925 } 926 for (i = 0; i < ARRAY_SIZE(prop4); i++) { 927 if (of_find_property(np, prop4[i].name, NULL)) 928 nconfs++; 929 } 930 if (!nconfs) 919 return 0; 932 933 func->conf = devm_kcalloc(pcs->dev, 934 nconfs, sizeof(struct pcs_conf_vals), 935 GFP_KERNEL); 936 if (!func->conf) 937 return -ENOMEM; 938 func->nconfs = nconfs; 939 conf = &(func->conf[0]); 940 m++; This situtation will cause a boot failure [0] on the BeagleBone Black (AM3358) when am33xx_pinmux node in arch/arm/boot/dts/am33xx-l4.dtsi has compatible = "pinconf-single" instead of "pinctrl-single". The patch fixes this issue by returning -ENOSUPP when !PCS_HAS_PINCONF or !nconfs, so that pcs_parse_one_pinctrl_entry() will know that no map was added. Logic is also added to pcs_parse_one_pinctrl_entry() to distinguish between -ENOSUPP and other errors. In the case of -ENOSUPP, num_maps is set to 1 as it is valid for pinconf to be enabled and a given pin group to not any pinconf properties. [0] https://lore.kernel.org/linux-omap/20200529175544.GA3766151@x1/ Fixes: 9dddb4df90d1 ("pinctrl: single: support generic pinconf") Signed-off-by: Drew Fustini Acked-by: Tony Lindgren Link: https://lore.kernel.org/r/20200608125143.GA2789203@x1 Signed-off-by: Linus Walleij Signed-off-by: Sasha Levin

pinctrl: amd: fix npins for uart0 in kerncz_groups

2020-07-31T14:43:11Z

[ Upstream commit 69339d083dfb7786b0e0b3fc19eaddcf11fabdfb ] uart0_pins is defined as: static const unsigned uart0_pins[] = {135, 136, 137, 138, 139}; which npins is wronly specified as 9 later { .name = "uart0", .pins = uart0_pins, .npins = 9, }, npins should be 5 instead of 9 according to the definition. Signed-off-by: Jacky Hu Link: https://lore.kernel.org/r/20200616015024.287683-1-hengqing.hu@gmail.com Signed-off-by: Linus Walleij Signed-off-by: Sasha Levin

pinctrl: samsung: Save/restore eint_mask over suspend for EINT_TYPE GPIOs

2020-06-20T08:23:24Z

commit f354157a7d184db430c1a564c506434e33b1bec5 upstream. Currently, for EINT_TYPE GPIOs, the CON and FLTCON registers are saved and restored over a suspend/resume cycle. However, the EINT_MASK registers are not. On S5PV210 at the very least, these registers are not retained over suspend, leading to the interrupts remaining masked upon resume and therefore no interrupts being triggered for the device. There should be no effect on any SoCs that do retain these registers as theoretically we would just be re-writing what was already there. Fixes: 7ccbc60cd9c2 ("pinctrl: exynos: Handle suspend/resume of GPIO EINT registers") Cc: Signed-off-by: Jonathan Bakker Signed-off-by: Krzysztof Kozlowski Signed-off-by: Greg Kroah-Hartman

pinctrl: tegra: Correctly check the supported configuration

2020-05-10T08:26:34Z

commit b22ef2a0979f2b91cfeeabb086e4d665183a93a1 upstream. The pincontrol registers of Tegra chips has multiple filed per registers. There is two type of registers mux and drive. All configurations belongs to one of these registers. If any configurations are supported then _bit is set to bit position of these registers otherwise -1 to not support it. The member is defined as s32 _bit:6; So if config is not supported ifor given SoC then it is set to -1 in soc pinmmux table. In common driver code, to find out that given config is supported or not, it is checked as: s8 bit = _bit; if (bit > 31) { /* Not supported config */ } But in this case, bit is s8 and hence for non supporting it is -1. Correct the check as: if (bit < 0) { /* Not supported config */ } Fixes: e4c02dced975cb ("pinctrl: tegra: use signed bitfields for optional fields") Signed-off-by: Laxman Dewangan Acked-by: Stephen Warren Signed-off-by: Linus Walleij Signed-off-by: Greg Kroah-Hartman