From: Bjorn Andersson <quic_bjorande@quicinc.com>
To: Johan Hovold <johan@kernel.org>
Cc: Bjorn Andersson <andersson@kernel.org>,
Linus Walleij <linus.walleij@linaro.org>,
Brian Norris <computersforpeace@gmail.com>,
Jaiganesh Narayanan <njaigane@codeaurora.org>,
Doug Anderson <dianders@chromium.org>,
<linux-arm-msm@vger.kernel.org>, <linux-gpio@vger.kernel.org>,
<linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] pinctrl: qcom: Fix behavior in abscense of open-drain support
Date: Thu, 25 Apr 2024 06:47:26 -0700 [thread overview]
Message-ID: <Zipe7u/9ajRXa81U@hu-bjorande-lv.qualcomm.com> (raw)
In-Reply-To: <ZipGRl_QC_x83MFt@hovoldconsulting.com>
On Thu, Apr 25, 2024 at 02:02:14PM +0200, Johan Hovold wrote:
> On Wed, Apr 24, 2024 at 08:45:31PM -0700, Bjorn Andersson wrote:
> > When a GPIO is configured as OPEN_DRAIN gpiolib will in
> > gpiod_direction_output() attempt to configure the open-drain property of
> > the hardware and if this fails fall back to software emulation of this
> > state.
> >
> > The TLMM block in most Qualcomm platform does not implement such
> > functionality, so this call would be expected to fail. But due to lack
> > of checks for this condition, the zero-initialized od_bit will cause
> > this request to silently corrupt the lowest bit in the config register
> > (which typically is part of the bias configuration) and happily continue
> > on.
> >
> > Fix this by checking if the od_bit value is unspecified and if so fail
> > the request to avoid the unexpected state, and to make sure the software
> > fallback actually kicks in.
>
> Fortunately, this is currently not a problem as the gpiochip driver does
> not implement the set_config() callback, which means that the attempt to
> change the pin configuration currently always fails with -ENOTSUP (see
> gpio_do_set_config()).
>
You're right. I was convinced that I implemented set_config() and got
lost in the indirections.
> Specifically, this means that the software fallback kicks in, which I
> had already verified.
>
I thought you did, and found this strange.
> Now, perhaps there is some other path which can allow you to end up
> here, but it's at least not via gpiod_direction_output().
>
> The msm pinctrl binding does not allow 'drive-open-drain' so that path
> should also be ok unless you have a non-conformant devicetree.
>
Looking at it again, I believe you're right and this is currently dead
code, waiting to screw us over once someone opens up the code path I
thought I fixed...
> > It is assumed for now that no implementation will come into existence
> > with BIT(0) being the open-drain bit, simply for convenience sake.
> >
> > Fixes: 13355ca35cd1 ("pinctrl: qcom: ipq4019: add open drain support")
>
> I guess hardware open-drain mode has never been properly tested on
> ipq4019.
>
I see no other explanation. Perhaps there were additional changes in the
downstream tree where that change came from.
> > Signed-off-by: Bjorn Andersson <quic_bjorande@quicinc.com>
> > ---
> > drivers/pinctrl/qcom/pinctrl-msm.c | 2 ++
> > drivers/pinctrl/qcom/pinctrl-msm.h | 3 ++-
> > 2 files changed, 4 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/pinctrl/qcom/pinctrl-msm.c b/drivers/pinctrl/qcom/pinctrl-msm.c
> > index aeaf0d1958f5..329474dc21c0 100644
> > --- a/drivers/pinctrl/qcom/pinctrl-msm.c
> > +++ b/drivers/pinctrl/qcom/pinctrl-msm.c
> > @@ -313,6 +313,8 @@ static int msm_config_reg(struct msm_pinctrl *pctrl,
> > *mask |= BIT(g->i2c_pull_bit) >> *bit;
> > break;
> > case PIN_CONFIG_DRIVE_OPEN_DRAIN:
> > + if (!g->od_bit)
> > + return -EOPNOTSUPP;
>
> I believe this should be -ENOTSUPP, which the rest of the driver and
> subsystem appear to use.
>
Both error codes are used in across gpio/pinctrl subsystems. I first
went ENOTSUPP but folded, perhaps too easily, when checkpatch told me
EOPNOTSUPP was better.
I'm leaning towards us reverting the ipq4019 patch, rather than try
complete the patch, but will give this some more thought before spinning
v2.
Thank you,
Bjorn
> > *bit = g->od_bit;
> > *mask = 1;
> > break;
>
> Johan
next prev parent reply other threads:[~2024-04-25 13:48 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-04-25 3:45 [PATCH] pinctrl: qcom: Fix behavior in abscense of open-drain support Bjorn Andersson
2024-04-25 12:02 ` Johan Hovold
2024-04-25 13:47 ` Bjorn Andersson [this message]
2024-04-26 22:08 ` Brian Norris
2024-04-26 23:43 ` Bjorn Andersson
2024-04-27 6:18 ` Brian Norris
2024-05-03 7:28 ` Linus Walleij
2024-05-03 7:35 ` Johan Hovold
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=Zipe7u/9ajRXa81U@hu-bjorande-lv.qualcomm.com \
--to=quic_bjorande@quicinc.com \
--cc=andersson@kernel.org \
--cc=computersforpeace@gmail.com \
--cc=dianders@chromium.org \
--cc=johan@kernel.org \
--cc=linus.walleij@linaro.org \
--cc=linux-arm-msm@vger.kernel.org \
--cc=linux-gpio@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=njaigane@codeaurora.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.