[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAMRc=Mdk+fGiVOH_Zq0K_gRpo-c2Gyh=SakKL77bL2BscS_PKQ@mail.gmail.com>
Date: Thu, 3 Jul 2025 10:17:43 +0200
From: Bartosz Golaszewski <brgl@...ev.pl>
To: Dmitry Baryshkov <dmitry.baryshkov@....qualcomm.com>
Cc: Linus Walleij <linus.walleij@...aro.org>, Bjorn Andersson <andersson@...nel.org>,
Konrad Dybcio <konradybcio@...nel.org>, Alexey Klimov <alexey.klimov@...aro.org>,
linux-gpio@...r.kernel.org, linux-kernel@...r.kernel.org,
linux-arm-msm@...r.kernel.org,
Bartosz Golaszewski <bartosz.golaszewski@...aro.org>
Subject: Re: [PATCH RFC 3/5] pinctrl: qcom: sm8650: mark the `gpio` pin
function as a non-strict function
On Thu, Jul 3, 2025 at 12:50 AM Dmitry Baryshkov
<dmitry.baryshkov@....qualcomm.com> wrote:
>
> On Wed, Jul 02, 2025 at 10:45:33AM +0200, Bartosz Golaszewski wrote:
> > From: Bartosz Golaszewski <bartosz.golaszewski@...aro.org>
> >
> > Allow pins muxed to the "gpio" function to be requested as GPIOs even if
> > pinmux_ops say the controller should be strict.
>
> This is a strange commit message, shouldn't "gpio" function behave
> exactly like that - mark the pin as a GPIO?
>
They should but they don't. I should maybe rework the commit message
to say: "muxed to the function called `gpio`...". The "gpio" here is
just a name, it could as well be saying "dmitry" or "123456", the
pinctrl core doesn't interpret it in any special way. What I'm doing
here, is marking the associated struct pinfunction object as one that
should allow pinmux core to export this pin as a GPIOLIB GPIO.
Bart
Powered by blists - more mailing lists