linux-kernel - Re: [PATCH RFC/RFT] pinctrl: qcom: make the pinmuxing strict

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-prev] [day] [month] [year] [list]

Message-ID: <CAMRc=MeL3PNJjBQ88L9Hqj+kvHvBDFTe36YR2Oi6OZbLnKEWsg@mail.gmail.com>
Date: Fri, 4 Jul 2025 10:09:41 +0200
From: Bartosz Golaszewski <brgl@...ev.pl>
To: Linus Walleij <linus.walleij@...aro.org>
Cc: Konrad Dybcio <konrad.dybcio@....qualcomm.com>, Bjorn Andersson <andersson@...nel.org>, 
	Konrad Dybcio <konradybcio@...nel.org>, linux-arm-msm@...r.kernel.org, 
	linux-gpio@...r.kernel.org, linux-kernel@...r.kernel.org, 
	Bartosz Golaszewski <bartosz.golaszewski@...aro.org>
Subject: Re: [PATCH RFC/RFT] pinctrl: qcom: make the pinmuxing strict

On Fri, Jul 4, 2025 at 12:21 AM Linus Walleij <linus.walleij@...aro.org> wrote:
>
> On Fri, Jun 27, 2025 at 10:26 AM Bartosz Golaszewski <brgl@...ev.pl> wrote:
>
> > Yeah, I would be surprised if nothing broke.It's probably worth
> > looking into the implementation of the strict flag as it makes every
> > muxed pin unavailable as GPIO even if - like in this case - the
> > function *is* "gpio". Of course the "gpio" string has no real meaning
> > to the pinctrl core, it's just a name but it would be awesome if we
> > could say for a given function that this means GPIO and as such should
> > be available to the GPIOLIB API.
>
> Can't we just add a special callback to the pinmux_ops for that?
> like
>
> int (*is_gpio_mode) (struct pinctrl_dev *pctldev, unsigned int pin);
>
> That the core code can call to ask the driver if a pin is in GPIO
> mode already? A simple strcmp("gpio", ...) is one way for the
> Qualcomm driver to implement that.
>

Yeah, this is similar to what I proposed in my RFC except that I went
with a flag in struct pinfunction. I think it's more future-proof than
string comparison, especially when we also have functions called
"egpio" which, while not used now, may also need this (possibly).

It's unfortunate that the struct pinfunction list for given controller
- while defined globally - does not seem to be stored anywhere in
pinctrl core data structures. That would allow the core to query these
things like function name and - in this case - whether it's a GPIO
without going through pinmux callbacks. Maybe this could be added to
struct pinctrl_desc?

Bart