linux-stable.git/drivers/pinctrl, branch v6.8.4 Linux kernel stable tree genirq: Introduce IRQF_COND_ONESHOT and use it in pinctrl-amd 2024-04-03T13:32:45+00:00 Rafael J. Wysocki rafael.j.wysocki@intel.com 2024-03-25T12:58:08+00:00 5543766d4b730cfb2885ee678c02688d8b420f1c 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 <francisco@videowindow.eu> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Cc: 6.8+ <stable@vger.kernel.org> # 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 <gregkh@linuxfoundation.org> 
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 <francisco@videowindow.eu>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Cc: 6.8+ <stable@vger.kernel.org> # 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 <gregkh@linuxfoundation.org>
pinctrl: qcom: sm8650-lpass-lpi: correct Kconfig name 2024-04-03T13:32:05+00:00 Krzysztof Kozlowski krzysztof.kozlowski@linaro.org 2024-02-16T10:24:35+00:00 a558397482986f3632bb16da9d27692545c8ae00 [ Upstream commit 47847b9bcdb13c2da1829323a66651ef63047b77 ] Use proper model name in SM8650 LPASS pin controller Kconfig entry. Cc: <stable@vger.kernel.org> Fixes: c4e47673853f ("pinctrl: qcom: sm8650-lpass-lpi: add SM8650 LPASS") Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org> Link: https://lore.kernel.org/r/20240216102435.89867-1-krzysztof.kozlowski@linaro.org Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Sasha Levin <sashal@kernel.org> 
[ Upstream commit 47847b9bcdb13c2da1829323a66651ef63047b77 ]

Use proper model name in SM8650 LPASS pin controller Kconfig entry.

Cc:  <stable@vger.kernel.org>
Fixes: c4e47673853f ("pinctrl: qcom: sm8650-lpass-lpi: add SM8650 LPASS")
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org>
Link: https://lore.kernel.org/r/20240216102435.89867-1-krzysztof.kozlowski@linaro.org
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
gpio: nomadik: fix offset bug in nmk_pmx_set() 2024-03-26T22:17:15+00:00 Théo Lebrun theo.lebrun@bootlin.com 2024-02-28T11:28:03+00:00 1f409905631faca13af42398bec264bc51157cf2 [ 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 <linus.walleij@linaro.org> Signed-off-by: Théo Lebrun <theo.lebrun@bootlin.com> Link: https://lore.kernel.org/r/20240228-mbly-gpio-v2-5-3ba757474006@bootlin.com Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Sasha Levin <sashal@kernel.org> 
[ 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 <linus.walleij@linaro.org>
Signed-off-by: Théo Lebrun <theo.lebrun@bootlin.com>
Link: https://lore.kernel.org/r/20240228-mbly-gpio-v2-5-3ba757474006@bootlin.com
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
pinctrl: renesas: Allow the compiler to optimize away sh_pfc_pm 2024-03-26T22:17:09+00:00 Geert Uytterhoeven geert+renesas@glider.be 2024-02-21T11:13:59+00:00 a02e9bd417d2c2027004630e0b8d649813ea9ac1 [ 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 <geert+renesas@glider.be> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Link: https://lore.kernel.org/r/6238a78e32fa21f0c795406b6cba7bce7af92577.1708513940.git.geert+renesas@glider.be Signed-off-by: Sasha Levin <sashal@kernel.org> 
[ 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 <geert+renesas@glider.be>
Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Link: https://lore.kernel.org/r/6238a78e32fa21f0c795406b6cba7bce7af92577.1708513940.git.geert+renesas@glider.be
Signed-off-by: Sasha Levin <sashal@kernel.org>
pinctrl: mediatek: Drop bogus slew rate register range for MT8192 2024-03-26T22:17:03+00:00 Chen-Yu Tsai wenst@chromium.org 2024-01-31T07:19:08+00:00 1ed607ce690aed96c76a5ea8151131b1ed812982 [ 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 <wenst@chromium.org> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Link: https://lore.kernel.org/r/20240131071910.3950450-2-wenst@chromium.org Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Sasha Levin <sashal@kernel.org> 
[ 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 <wenst@chromium.org>
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Link: https://lore.kernel.org/r/20240131071910.3950450-2-wenst@chromium.org
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
pinctrl: mediatek: Drop bogus slew rate register range for MT8186 2024-03-26T22:17:03+00:00 Chen-Yu Tsai wenst@chromium.org 2024-01-31T07:19:07+00:00 1b5b3ab230d4b72bd859a81bed645aad0e633deb [ 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 <wenst@chromium.org> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Link: https://lore.kernel.org/r/20240131071910.3950450-1-wenst@chromium.org Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Sasha Levin <sashal@kernel.org> 
[ 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 <wenst@chromium.org>
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Link: https://lore.kernel.org/r/20240131071910.3950450-1-wenst@chromium.org
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
pinctrl: renesas: r8a779g0: Add missing SCIF_CLK2 pin group/function 2024-03-26T22:17:02+00:00 Geert Uytterhoeven geert+renesas@glider.be 2024-01-18T16:32:36+00:00 c96427ebb59d72bd3da7d3e2ffab933dd9a04379 [ 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 <geert+renesas@glider.be> Link: https://lore.kernel.org/r/6352ec9b63fdd38c2c70d8d203e46f21fbfeccdc.1705589612.git.geert+renesas@glider.be Signed-off-by: Sasha Levin <sashal@kernel.org> 
[ 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 <geert+renesas@glider.be>
Link: https://lore.kernel.org/r/6352ec9b63fdd38c2c70d8d203e46f21fbfeccdc.1705589612.git.geert+renesas@glider.be
Signed-off-by: Sasha Levin <sashal@kernel.org>
pinctrl: renesas: rzg2l: Fix locking in rzg2l_dt_subnode_to_map() 2024-03-26T22:17:01+00:00 Claudiu Beznea claudiu.beznea.uj@bp.renesas.com 2024-01-15T15:34:53+00:00 e8b63587feed5b6bae35ebb4fe541f32c202d9a0 [ 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 <dan.carpenter@linaro.org> Closes: https://lore.kernel.org/all/f8c3a3a0-7c48-4e40-8af0-ed4e9d9b049f@moroto.mountain Signed-off-by: Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be> Link: https://lore.kernel.org/r/20240115153453.99226-1-claudiu.beznea.uj@bp.renesas.com Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Signed-off-by: Sasha Levin <sashal@kernel.org> 
[ 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 <dan.carpenter@linaro.org>
Closes: https://lore.kernel.org/all/f8c3a3a0-7c48-4e40-8af0-ed4e9d9b049f@moroto.mountain
Signed-off-by: Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Link: https://lore.kernel.org/r/20240115153453.99226-1-claudiu.beznea.uj@bp.renesas.com
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: Sasha Levin <sashal@kernel.org>
pinctrl: don't put the reference to GPIO device in pinctrl_pins_show() 2024-02-29T13:36:40+00:00 Bartosz Golaszewski bartosz.golaszewski@linaro.org 2024-02-23T12:32:14+00:00 f6443e0177a55f78e94ccc1a43eb63a023a0b6fd The call to gpiod_to_gpio_device() does not increase the reference count of the GPIO device struct so it must not be decreased. Remove the buggy __free() decorator. Fixes: 524fc108b895 ("pinctrl: stop using gpiod_to_chip()") Reported-by: David Arcari <darcari@redhat.com> Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org> Link: https://lore.kernel.org/r/20240223123214.288181-1-brgl@bgdev.pl Signed-off-by: Linus Walleij <linus.walleij@linaro.org> 
The call to gpiod_to_gpio_device() does not increase the reference count
of the GPIO device struct so it must not be decreased. Remove the buggy
__free() decorator.

Fixes: 524fc108b895 ("pinctrl: stop using gpiod_to_chip()")
Reported-by: David Arcari <darcari@redhat.com>
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
Link: https://lore.kernel.org/r/20240223123214.288181-1-brgl@bgdev.pl
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
pinctrl: stm32: fix PM support for stm32mp257 2024-02-13T08:42:22+00:00 Antonio Borneo antonio.borneo@foss.st.com 2024-02-07T10:46:04+00:00 cb4443f26b43efa54494b8de8a50457febb06940 The driver for stm32mp257 is missing the suspend callback in struct dev_pm_ops. Add the callback, using the common stm32_pinctrl_suspend() function. Signed-off-by: Antonio Borneo <antonio.borneo@foss.st.com> Fixes: 619f8ca4a73d ("pinctrl: stm32: add stm32mp257 pinctrl support") Link: https://lore.kernel.org/r/20240207104604.174843-1-antonio.borneo@foss.st.com Signed-off-by: Linus Walleij <linus.walleij@linaro.org> 
The driver for stm32mp257 is missing the suspend callback in
struct dev_pm_ops.

Add the callback, using the common stm32_pinctrl_suspend()
function.

Signed-off-by: Antonio Borneo <antonio.borneo@foss.st.com>
Fixes: 619f8ca4a73d ("pinctrl: stm32: add stm32mp257 pinctrl support")
Link: https://lore.kernel.org/r/20240207104604.174843-1-antonio.borneo@foss.st.com
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>