From: Bartosz Golaszewski bartosz.golaszewski@linaro.org
[ Upstream commit cc85cb96e2e4489826e372cde645b7823c435de0 ]
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 konrad.dybcio@oss.qualcomm.com Tested-by: Neil Armstrong neil.armstrong@linaro.org Signed-off-by: Bartosz Golaszewski bartosz.golaszewski@linaro.org Signed-off-by: Linus Walleij linus.walleij@linaro.org Signed-off-by: Sasha Levin sashal@kernel.org ---
LLM Generated explanations, may be completely bogus:
YES – with the prerequisite series in place.
- `drivers/pinctrl/qcom/pinctrl-msm.c:219-227` now turns on `.strict`, so once a TLMM pin is muxed to a function it cannot be re-requested as a GPIO by a second consumer. This closes the long-standing hole where a privileged userspace process (or a misbehaving kernel client) could grab an in-use pin via gpiolib and drive it, confusing or crashing attached peripherals.
- The pinmux core side already enforces the exclusivity checks: see `drivers/pinctrl/pinmux.c:79-143`, where `ops->strict` blocks a second claimant unless the current mux function is known to be a GPIO. With `.strict` enabled, we finally get the same protection for Qualcomm TLMM as many other pinctrl drivers already enjoy.
- Safe backporting absolutely requires the two earlier commits that landed right before this one upstream: 1. `11aa02d6a9c22 ("pinctrl: allow to mark pin functions as requestable GPIOs")` adds `PINFUNCTION_FLAG_GPIO` plus the `function_is_gpio` hook used to keep GPIO-mode pins requestable even under `strict`. 2. `b65803da894ca ("pinctrl: qcom: add infrastructure for marking pin functions as GPIOs")` wires that hook up for TLMM by tagging the `msm_mux_gpio` functions and populating `.function_is_gpio` in `msm_pinmux_ops`. Without these, setting `.strict` would regress every board that applies a GPIO pinctrl state and then requests the same line through gpiolib (the common regulator/reset pattern).
- Impact scope is large—the TLMM driver serves virtually every modern Qualcomm SoC—but the behaviour now matches core expectations, and legitimate GPIO users keep working because the GPIO function is flagged appropriately. The only fallout should be catching real conflicts (double ownership or debug “pin poking”), which is precisely what we want to prevent.
- Change size is tiny, architectural churn is nil, and the fix has Reviewed/Tested tags. Risk mainly comes from omitting the dependencies; with them backported, this is a low-risk hardening fix.
Given the security and robustness benefits, and provided the two prerequisite commits are included, this commit is a good candidate for the stable kernels.
drivers/pinctrl/qcom/pinctrl-msm.c | 1 + 1 file changed, 1 insertion(+)
diff --git a/drivers/pinctrl/qcom/pinctrl-msm.c b/drivers/pinctrl/qcom/pinctrl-msm.c index 83eb075b6bfa1..bdce967710a31 100644 --- a/drivers/pinctrl/qcom/pinctrl-msm.c +++ b/drivers/pinctrl/qcom/pinctrl-msm.c @@ -293,6 +293,7 @@ static const struct pinmux_ops msm_pinmux_ops = { .get_function_groups = msm_get_function_groups, .gpio_request_enable = msm_pinmux_request_gpio, .set_mux = msm_pinmux_set_mux, + .strict = true, };
static int msm_config_reg(struct msm_pinctrl *pctrl,