[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <ZjSTqfxgrox0IceO@hovoldconsulting.com>
Date: Fri, 3 May 2024 09:35:05 +0200
From: Johan Hovold <johan@...nel.org>
To: Linus Walleij <linus.walleij@...aro.org>
Cc: Bjorn Andersson <quic_bjorande@...cinc.com>,
Bjorn Andersson <andersson@...nel.org>,
Brian Norris <computersforpeace@...il.com>,
Jaiganesh Narayanan <njaigane@...eaurora.org>,
Doug Anderson <dianders@...omium.org>,
linux-arm-msm@...r.kernel.org, linux-gpio@...r.kernel.org,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH] pinctrl: qcom: Fix behavior in abscense of open-drain
support
On Fri, May 03, 2024 at 09:28:41AM +0200, Linus Walleij wrote:
> On Thu, Apr 25, 2024 at 5:46 AM Bjorn Andersson
> <quic_bjorande@...cinc.com> 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.
> >
> > 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")
> > Signed-off-by: Bjorn Andersson <quic_bjorande@...cinc.com>
>
> I tried to follow the discussion but couldn't get to a verdict on this patch,
> should it be applied or not, and if it should be applied, should the Fixes:
> tag be dropped or left and considered a nonurgent fix as it does not
> affect current behaviour?
It should not be applied in its current form (e.g. as the commit message
is incorrect). Bjorn will be sending a v2.
Johan
Powered by blists - more mailing lists