linux-stable.git/drivers/pinctrl/qcom, branch v6.18

pinctrl: qcom: msm: Fix deadlock in pinmux configuration

2025-11-12T12:41:34+00:00

Replace disable_irq() with disable_irq_nosync() in msm_pinmux_set_mux()
to prevent deadlock when wakeup IRQ is triggered on the same
GPIO being reconfigured.

The issue occurs when a wakeup IRQ is triggered on a GPIO and the IRQ
handler attempts to reconfigure the same GPIO's pinmux. In this scenario,
msm_pinmux_set_mux() calls disable_irq() which waits for the currently
running IRQ handler to complete, creating a circular dependency that
results in deadlock.

Using disable_irq_nosync() avoids waiting for the IRQ handler to
complete, preventing the deadlock condition while still properly
disabling the interrupt during pinmux reconfiguration.

Suggested-by: Prasad Sodagudi 
Signed-off-by: Praveen Talari 
Reviewed-by: Bjorn Andersson 
Signed-off-by: Linus Walleij

pinctrl: qcom: Add SDM660 LPASS LPI TLMM

2025-09-10T13:35:42+00:00

The Snapdragon 660 has a Low-Power Island (LPI) TLMM for configuring
pins related to audio. Add the driver for this.
Also, this driver uses predefined pin_offsets for each pin taken from
downstream driver, which does not follow the usual 0x1000 distance
between pins and uses an array with predefined offsets that do not
follow any regular pattern [1].

[1] https://git.codelinaro.org/clo/la/kernel/msm-4.4/-/blob/LA.UM.7.2.c27-07400-sdm660.0/drivers/pinctrl/qcom/pinctrl-lpi.c#L107

Reviewed-by: Konrad Dybcio 
Signed-off-by: Richard Acayan 
Co-developed-by: Nickolay Goppen 
Signed-off-by: Nickolay Goppen 
Signed-off-by: Linus Walleij

pinctrl: qcom: lpass-lpi: Add ability to use custom pin offsets

2025-09-10T13:35:41+00:00

By default pin_offset is calculated by formula: LPI_TLMM_REG_OFFSET * pin_id.
However not all platforms are using this pin_offset formula (e.g. SDM660 LPASS
LPI uses a predefined array of offsets [1]), so extend lpi_pingroup struct
with pin_offset field, introduce extended LPI_PINGROUP_OFFSET macro with
pin_offet field and introduce LPI_FLAG_USE_PREDEFINED_PIN_OFFSET flag.
This adds an ability to use predefined offset for pin if it exists.

[1] https://git.codelinaro.org/clo/la/kernel/msm-4.4/-/blob/LA.UM.7.2.c27-07400-sdm660.0/drivers/pinctrl/qcom/pinctrl-lpi.c#L107

Reviewed-by: Konrad Dybcio 
Signed-off-by: Nickolay Goppen 
Signed-off-by: Linus Walleij

pinctrl: qcom: Add glymur pinctrl driver

2025-09-08T12:56:47+00:00

Add TLMM pinctrl driver to support pin configuration with pinctrl
framework for Glymur SoC.

Reviewed-by: Bjorn Andersson 
Reviewed-by: Konrad Dybcio 
Signed-off-by: Pankaj Patil 
Signed-off-by: Linus Walleij

pinctrl: qcom: sm8250: Add egpio support

2025-09-08T12:24:32+00:00

This mirrors the egpio support added to sc7280/sm8450/etc. This change
is necessary for GPIOs 146 - 179 (34 GPIOs) to be used as normal GPIOs.

Signed-off-by: Sean Parker 
Reviewed-by: Konrad Dybcio 
Signed-off-by: Linus Walleij

pinctrl: generic: rename PIN_CONFIG_OUTPUT to LEVEL

2025-09-08T12:24:20+00:00

This generic pin config property is confusingly named so let's
rename it to make things clearer.

There are already drivers in the tree that use PIN_CONFIG_OUTPUT
to *read* the value of an output driven pin, which is a big
semantic confusion for the head: are we then reading the
setting of the output or the actual value/level that is put
out on the pin?

We already have PIN_CONFIG_OUTPUT_ENABLE that turns on driver
buffers for output, so this can by logical conclusion only
drive the voltage level if it should be any different.

But if we read the pin, are we then reading the *setting* of
the output value or the *actual* value we can see on the
line?

If the pin has not first been set into output mode with
PIN_CONFIG_OUTPUT_ENABLE, but is instead in some input mode
or tristate, what will reading this property actually
return?

Reading the current users reading this property it is clear
that what we read is the logical level of the pin as 0 or 1
depending on if it is low or high.

Rename it to PIN_CONFIG_LEVEL so it is crystal clear that
we set or read the voltage level of the pin and nothing else.

Acked-by: Sudeep Holla 
Signed-off-by: Linus Walleij

pinctrl: qcom: make the pinmuxing strict

2025-09-08T12:23:24+00:00

The strict flag in struct pinmux_ops disallows the usage of the same pin
as a GPIO and for another function. Without it, a rouge user-space
process with enough privileges (or even a buggy driver) can request a
used pin as GPIO and drive it, potentially confusing devices or even
crashing the system. Set it globally for all pinctrl-msm users.

Reviewed-by: Konrad Dybcio 
Tested-by: Neil Armstrong 
Signed-off-by: Bartosz Golaszewski 
Signed-off-by: Linus Walleij

pinctrl: qcom: mark the `gpio` and `egpio` pins function as non-strict functions

2025-09-08T12:23:15+00:00

Allow pins muxed to the "gpio" or "egpio" function to be requested as
GPIOs even if pinmux_ops say the controller should be strict.

Reviewed-by: Konrad Dybcio 
Tested-by: Neil Armstrong 
Signed-off-by: Bartosz Golaszewski 
Signed-off-by: Linus Walleij

pinctrl: qcom: add infrastructure for marking pin functions as GPIOs

2025-09-08T12:23:07+00:00

Add a helper macro that wraps PINCTRL_GPIO_PINFUNCTION() for pinctrl-msm
pin functions and assign the .function_is_gpio() callback in pinmux_ops.

Reviewed-by: Konrad Dybcio 
Tested-by: Neil Armstrong 
Signed-off-by: Bartosz Golaszewski 
Signed-off-by: Linus Walleij

pinctrl: qcom: use generic pin function helpers

2025-09-08T12:22:50+00:00

With the pinmux core no longer duplicating memory used to store the
struct pinfunction objects in .rodata, we can now use the existing
infrastructure for storing and looking up pin functions in qualcomm
drivers. Remove hand-crafted callbacks.

Reviewed-by: Konrad Dybcio 
Tested-by: Neil Armstrong 
Signed-off-by: Bartosz Golaszewski 
Signed-off-by: Linus Walleij