user/sven/linux.git/drivers/pinctrl, branch v6.8.6

pinctrl: renesas: checker: Limit cfg reg enum checks to provided IDs

2024-04-13T11:10:03Z

[ Upstream commit 3803584a4e9b65bb5b013f862f55c5055aa86c25 ] If the number of provided enum IDs in a variable width config register description does not match the expected number, the checker uses the expected number for validating the individual enum IDs. However, this may cause out-of-bounds accesses on the array holding the enum IDs, leading to bogus enum_id conflict warnings. Worse, if the bug is an incorrect bit field description (e.g. accidentally using "12" instead of "-12" for a reserved field), thousands of warnings may be printed, overflowing the kernel log buffer. Fix this by limiting the enum ID check to the number of provided enum IDs. Signed-off-by: Geert Uytterhoeven Link: https://lore.kernel.org/r/c7385f44f2faebb8856bcbb4e908d846fc1531fb.1705930809.git.geert+renesas@glider.be Signed-off-by: Sasha Levin

kbuild: make -Woverride-init warnings more consistent

2024-04-10T14:38:00Z

[ Upstream commit c40845e3195d074b34f8f8e400e28c9403a06588 ] The -Woverride-init warn about code that may be intentional or not, but the inintentional ones tend to be real bugs, so there is a bit of disagreement on whether this warning option should be enabled by default and we have multiple settings in scripts/Makefile.extrawarn as well as individual subsystems. Older versions of clang only supported -Wno-initializer-overrides with the same meaning as gcc's -Woverride-init, though all supported versions now work with both. Because of this difference, an earlier cleanup of mine accidentally turned the clang warning off for W=1 builds and only left it on for W=2, while it's still enabled for gcc with W=1. There is also one driver that only turns the warning off for newer versions of gcc but not other compilers, and some but not all the Makefiles still use a cc-disable-warning conditional that is no longer needed with supported compilers here. Address all of the above by removing the special cases for clang and always turning the warning off unconditionally where it got in the way, using the syntax that is supported by both compilers. Fixes: 2cd3271b7a31 ("kbuild: avoid duplicate warning options") Signed-off-by: Arnd Bergmann Acked-by: Hamza Mahfooz Acked-by: Jani Nikula Acked-by: Andrew Jeffery Signed-off-by: Jani Nikula Reviewed-by: Linus Walleij Signed-off-by: Masahiro Yamada Signed-off-by: Sasha Levin

genirq: Introduce IRQF_COND_ONESHOT and use it in pinctrl-amd

2024-04-03T13:32:45Z

commit c2ddeb29612f7ca84ed10c6d4f3ac99705135447 upstream. There is a problem when a driver requests a shared interrupt line to run a threaded handler on it without IRQF_ONESHOT set if that flag has been set already for the IRQ in question by somebody else. Namely, the request fails which usually leads to a probe failure even though the driver might have worked just fine with IRQF_ONESHOT, but it does not want to use it by default. Currently, the only way to handle this is to try to request the IRQ without IRQF_ONESHOT, but with IRQF_PROBE_SHARED set and if this fails, try again with IRQF_ONESHOT set. However, this is a bit cumbersome and not very clean. When commit 7a36b901a6eb ("ACPI: OSL: Use a threaded interrupt handler for SCI") switched the ACPI subsystem over to using a threaded interrupt handler for the SCI, it had to use IRQF_ONESHOT for it because that's required due to the way the SCI handler works (it needs to walk all of the enabled GPEs before the interrupt line can be unmasked). The SCI interrupt line is not shared with other users very often due to the SCI handling overhead, but on sone systems it is shared and when the other user of it attempts to install a threaded handler, a flags mismatch related to IRQF_ONESHOT may occur. As it turned out, that happened to the pinctrl-amd driver and so commit 4451e8e8415e ("pinctrl: amd: Add IRQF_ONESHOT to the interrupt request") attempted to address the issue by adding IRQF_ONESHOT to the interrupt flags in that driver, but this is now causing an IRQF_ONESHOT-related mismatch to occur on another system which cannot boot as a result of it. Clearly, pinctrl-amd can work with IRQF_ONESHOT if need be, but it should not set that flag by default, so it needs a way to indicate that to the interrupt subsystem. To that end, introdcuce a new interrupt flag, IRQF_COND_ONESHOT, which will only have effect when the IRQ line is shared and IRQF_ONESHOT has been set for it already, in which case it will be promoted to the latter. This is sufficient for drivers sharing the interrupt line with the SCI as it is requested by the ACPI subsystem before any drivers are probed, so they will always see IRQF_ONESHOT set for the interrupt in question. Fixes: 4451e8e8415e ("pinctrl: amd: Add IRQF_ONESHOT to the interrupt request") Reported-by: Francisco Ayala Le Brun Signed-off-by: Rafael J. Wysocki Signed-off-by: Thomas Gleixner Reviewed-by: Linus Walleij Cc: 6.8+ # 6.8+ Closes: https://lore.kernel.org/lkml/CAN-StX1HqWqi+YW=t+V52-38Mfp5fAz7YHx4aH-CQjgyNiKx3g@mail.gmail.com/ Link: https://lore.kernel.org/r/12417336.O9o76ZdvQC@kreacher Signed-off-by: Greg Kroah-Hartman

pinctrl: qcom: sm8650-lpass-lpi: correct Kconfig name

2024-04-03T13:32:05Z

[ Upstream commit 47847b9bcdb13c2da1829323a66651ef63047b77 ] Use proper model name in SM8650 LPASS pin controller Kconfig entry. Cc: Fixes: c4e47673853f ("pinctrl: qcom: sm8650-lpass-lpi: add SM8650 LPASS") Signed-off-by: Krzysztof Kozlowski Reviewed-by: Neil Armstrong Link: https://lore.kernel.org/r/20240216102435.89867-1-krzysztof.kozlowski@linaro.org Signed-off-by: Linus Walleij Signed-off-by: Sasha Levin

gpio: nomadik: fix offset bug in nmk_pmx_set()

2024-03-26T22:17:15Z

[ Upstream commit 53cf6b72e074864b94ade97dcb6f30b5ac1a82dc ] Previously, the statement looked like: slpm[x] &= ~BIT(g->grp.pins[i]); Where: - slpm is a unsigned int pointer; - g->grp.pins[i] is a pin number. It can grow to more than 32. The expected shift amount is a pin bank offset. This bug does not occur on every group or pin: the altsetting must be NMK_GPIO_ALT_C and the pin must be 32 or above. It might have occured. For example, in pinctrl-nomadik-db8500.c, pin group i2c3_c_2 has the right altsetting and pins 229 and 230. Fixes: dbfe8ca259e1 ("pinctrl/nomadik: implement pin multiplexing") Reviewed-by: Linus Walleij Signed-off-by: Théo Lebrun Link: https://lore.kernel.org/r/20240228-mbly-gpio-v2-5-3ba757474006@bootlin.com Signed-off-by: Linus Walleij Signed-off-by: Sasha Levin

pinctrl: renesas: Allow the compiler to optimize away sh_pfc_pm

2024-03-26T22:17:09Z

[ Upstream commit a6f06b909fee72c679c565adfa7f080f9595e336 ] The conversion to DEFINE_NOIRQ_DEV_PM_OPS() lost the ability of the compiler to optimize away the struct dev_pm_ops object when it is not needed. Fix this by replacing the use of pm_sleep_ptr() by a custom wrapper. Fixes: 727eb02eb753375e ("pinctrl: renesas: Switch to use DEFINE_NOIRQ_DEV_PM_OPS() helper") Signed-off-by: Geert Uytterhoeven Reviewed-by: Andy Shevchenko Link: https://lore.kernel.org/r/6238a78e32fa21f0c795406b6cba7bce7af92577.1708513940.git.geert+renesas@glider.be Signed-off-by: Sasha Levin

pinctrl: mediatek: Drop bogus slew rate register range for MT8192

2024-03-26T22:17:03Z

[ Upstream commit e15ab05a6b3ed42f2f43f8bd1a1abdbde64afecd ] The MT8192 does not support configuring pin slew rate. This is evident from both the datasheet, and the fact that the driver points the slew rate register range at the GPIO direction register range. Drop the bogus setting. Fixes: d32f38f2a8fc ("pinctrl: mediatek: Add pinctrl driver for mt8192") Signed-off-by: Chen-Yu Tsai Reviewed-by: AngeloGioacchino Del Regno Link: https://lore.kernel.org/r/20240131071910.3950450-2-wenst@chromium.org Signed-off-by: Linus Walleij Signed-off-by: Sasha Levin

pinctrl: mediatek: Drop bogus slew rate register range for MT8186

2024-03-26T22:17:03Z

[ Upstream commit 3a29c87548809405bcbc66acc69cbe6f15184d94 ] The MT8186 does not support configuring pin slew rate. This is evident from both the datasheet, and the fact that the driver points the slew rate register range at the GPIO direction register range. Drop the bogus setting. Fixes: 8b483bda1e46 ("pinctrl: add pinctrl driver on mt8186") Signed-off-by: Chen-Yu Tsai Reviewed-by: AngeloGioacchino Del Regno Link: https://lore.kernel.org/r/20240131071910.3950450-1-wenst@chromium.org Signed-off-by: Linus Walleij Signed-off-by: Sasha Levin

pinctrl: renesas: r8a779g0: Add missing SCIF_CLK2 pin group/function

2024-03-26T22:17:02Z

[ Upstream commit 68540257cdf1d07ff8a649aa94c21c5804bbb9b0 ] R-Car V4H actually has two SCIF_CLK pins. The second pin provides the SCIF_CLK signal for HSCIF2 and SCIF4. Fixes: 050442ae4c74f830 ("pinctrl: renesas: r8a779g0: Add pins, groups and functions") Signed-off-by: Geert Uytterhoeven Link: https://lore.kernel.org/r/6352ec9b63fdd38c2c70d8d203e46f21fbfeccdc.1705589612.git.geert+renesas@glider.be Signed-off-by: Sasha Levin

pinctrl: renesas: rzg2l: Fix locking in rzg2l_dt_subnode_to_map()

2024-03-26T22:17:01Z

[ Upstream commit bd433c25ca81b2ac6dca7ea288a8474eea4fb8a0 ] Commit d3aaa7203a17 ("pinctrl: renesas: rzg2l: Add pin configuration support for pinmux groups") introduced the possibility to parse pin configuration for pinmux groups. It did that by calling rzg2l_map_add_config() at the end of rzg2l_dt_subnode_to_map() and jumping to the remove_group label in case rzg2l_map_add_config() failed. But if that happens, the mutex will already be unlocked, thus this it will lead to double mutex unlock operation. To fix this move the rzg2l_map_add_config() call just after all the name argument is ready and before the mutex is locked. There is no harm in doing this, as this only parses the data from device tree that will be further processed by pinctrl core code. Fixes: d3aaa7203a17 ("pinctrl: renesas: rzg2l: Add pin configuration support for pinmux groups") Reported-by: Dan Carpenter Closes: https://lore.kernel.org/all/f8c3a3a0-7c48-4e40-8af0-ed4e9d9b049f@moroto.mountain Signed-off-by: Claudiu Beznea Reviewed-by: Geert Uytterhoeven Link: https://lore.kernel.org/r/20240115153453.99226-1-claudiu.beznea.uj@bp.renesas.com Signed-off-by: Geert Uytterhoeven Signed-off-by: Sasha Levin