[PATCH AUTOSEL 6.17-5.4] pinctrl: qcom: make the pinmuxing strict

[Sasha Levin <sashal@kernel.org>]

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,
-- 
2.51.0