linux-kernel - [PATCH RFC 0/5] pinctrl: introduce the concept of a GPIO pin function category

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Message-Id: <20250702-pinctrl-gpio-pinfuncs-v1-0-ed2bd0f9468d@linaro.org>
Date: Wed, 02 Jul 2025 10:45:30 +0200
From: Bartosz Golaszewski <brgl@...ev.pl>
To: Linus Walleij <linus.walleij@...aro.org>, 
 Bjorn Andersson <andersson@...nel.org>, 
 Konrad Dybcio <konradybcio@...nel.org>, 
 Alexey Klimov <alexey.klimov@...aro.org>
Cc: linux-gpio@...r.kernel.org, linux-kernel@...r.kernel.org, 
 linux-arm-msm@...r.kernel.org, 
 Bartosz Golaszewski <bartosz.golaszewski@...aro.org>
Subject: [PATCH RFC 0/5] pinctrl: introduce the concept of a GPIO pin
 function category

Note: this really is an RFC. Please don't spend too much time revieweing
the code in detail. I'd like to figure out if that's a good approach at
all first. Also: while I tested it on sm8650-qrd and sc8280xp-crd, the
last patch cannot be applied until all Qualcomm platforms are converted.

Problem: when pinctrl core binds pins to a consumer device and the
pinmux ops of the underlying driver are marked as strict, the pin in
question can no longer be requested as a GPIO using the GPIO descriptor
API. It will result in the following error:

[    5.095688] sc8280xp-tlmm f100000.pinctrl: pin GPIO_25 already requested by regulator-edp-3p3; cannot claim for f100000.pinctrl:570
[    5.107822] sc8280xp-tlmm f100000.pinctrl: error -EINVAL: pin-25 (f100000.pinctrl:570)

This typically makes sense except when the pins are muxed to a function
that actually says "GPIO". Of course, the function name is just a string
so it has no meaning to the pinctrl subsystem.

We have many Qualcomm SoCs (and I can imagine it's a common pattern in
other platforms as well) where we mux a pin to "gpio" function using the
`pinctrl-X` property in order to configure bias or drive-strength and
then access it using the gpiod API. This makes it impossible to mark the
pin controller module as "strict".

This series proposes to introduce a concept of a sub-category of
pinfunctions: GPIO functions where the above is not true and the pin
muxed as a GPIO can still be accessed via the GPIO consumer API even for
strict pinmuxers.

The first patch implements this functionality in pinctrl core, the
second adds local infrastructure to pinctrl-msm, next we convert two
Qualcomm platforms as examples and then finally enable the strict flag
in pinctrl-msm.

Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@...aro.org>
---
Bartosz Golaszewski (5):
      pinctrl: allow to mark pin functions as requestable GPIOs
      pinctrl: qcom: add infrastructure for marking pin functions as GPIOs
      pinctrl: qcom: sm8650: mark the `gpio` pin function as a non-strict function
      pinctrl: qcom: sc8280xp: mark the `gpio` pin function as a non-strict function
      pinctrl: qcom: make the pinmuxing strict

 drivers/pinctrl/pinmux.c                | 17 +++++++++++++++--
 drivers/pinctrl/qcom/pinctrl-msm.c      | 10 ++++++++++
 drivers/pinctrl/qcom/pinctrl-msm.h      |  5 +++++
 drivers/pinctrl/qcom/pinctrl-sc8280xp.c |  2 +-
 drivers/pinctrl/qcom/pinctrl-sm8650.c   |  2 +-
 include/linux/pinctrl/pinctrl.h         | 14 ++++++++++++++
 include/linux/pinctrl/pinmux.h          |  2 ++
 7 files changed, 48 insertions(+), 4 deletions(-)
---
base-commit: 1343433ed38923a21425c602e92120a1f1db5f7a
change-id: 20250701-pinctrl-gpio-pinfuncs-de82bd9aac43

Best regards,
-- 
Bartosz Golaszewski <bartosz.golaszewski@...aro.org>