stable.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Will McVicker <willmcvicker@google.com>
To: Geert Uytterhoeven <geert@linux-m68k.org>
Cc: Bartosz Golaszewski <brgl@bgdev.pl>,
	Marcelo Roberto Jimenez <marcelo.jimenez@gmail.com>,
	Thorsten Leemhuis <regressions@leemhuis.info>,
	stable <stable@vger.kernel.org>,
	regressions@lists.linux.dev,
	Linus Walleij <linus.walleij@linaro.org>,
	"open list:GPIO SUBSYSTEM" <linux-gpio@vger.kernel.org>,
	Thierry Reding <treding@nvidia.com>,
	Vidya Sagar <vidyas@nvidia.com>,
	Stephen Rothwell <sfr@canb.auug.org.au>,
	Edmond Chung <edmondchung@google.com>,
	Andrew Chant <achant@google.com>,
	Sergio Tanzilli <tanzilli@acmesystems.it>
Subject: Re: [PATCH] gpio: Revert regression in sysfs-gpio (gpiolib.c)
Date: Mon, 20 Dec 2021 11:24:53 -0800	[thread overview]
Message-ID: <CABYd82b2i4Uuyi5+zLoTgiC-QMS1y=VkwmMznZqxLca0iP9qTQ@mail.gmail.com> (raw)
In-Reply-To: <CAMuHMdVp621B0DywkW6sx6wNcPFez9=3-=cfSo7UoRttJ6QXCg@mail.gmail.com>

On Mon, Dec 20, 2021 at 7:14 AM Geert Uytterhoeven <geert@linux-m68k.org> wrote:
>
> On Mon, Dec 20, 2021 at 3:57 PM Bartosz Golaszewski <brgl@bgdev.pl> wrote:
> > On Sat, Dec 18, 2021 at 7:28 AM Thorsten Leemhuis
> > <regressions@leemhuis.info> wrote:
> > > [TLDR: I'm adding this regression to regzbot, the Linux kernel
> > > regression tracking bot; most text you find below is compiled from a few
> > > templates paragraphs some of you might have seen already.]
> > >
> > > On 17.12.21 16:35, Marcelo Roberto Jimenez wrote:
> > > > Some GPIO lines have stopped working after the patch
> > > > commit 2ab73c6d8323f ("gpio: Support GPIO controllers without pin-ranges")
> > > >
> > > > And this has supposedly been fixed in the following patches
> > > > commit 89ad556b7f96a ("gpio: Avoid using pin ranges with !PINCTRL")
> > > > commit 6dbbf84603961 ("gpiolib: Don't free if pin ranges are not defined")
> > >
> > > There seems to be a backstory here. Are there any entries and bug
> > > trackers or earlier discussions everyone that looks into this should be
> > > aware of?
> > >
> >
> > Agreed with Thorsten. I'd like to first try to determine what's wrong
> > before reverting those, as they are correct in theory but maybe the
> > implementation missed something.
> >
> > Have you tried tracing the execution on your platform in order to see
> > what the driver is doing?
>
> Looking at commits that have related Fixes tags:
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=bf781869e5cf3e4ec1a47dad69b6f0df97629cbd
> https://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-pinctrl.git/commit/?id=e8f24c58d1b69ecf410a673c22f546dc732bb879
>
> Gr{oetje,eeting}s,
>
>                         Geert
>
> --
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
>
> In personal conversations with technical people, I call myself a hacker. But
> when I'm talking to journalists I just say "programmer" or something like that.
>                                 -- Linus Torvalds

Hi Marcelo,

Thanks for reporting this issue. I can give you a little context on
why commit 6dbbf84603961 ("gpiolib: Don't free if pin ranges are not
defined") was created. We were seeing a refcounting issue on Pixel 6.
In our kernel CONFIG_PINCTRL is defined. Basically, the camera kernel
module requests for a GPIO on sensor enable (when the camera sensor is
turned on) and releases that GPIO on sensor disable (when the camera
sensor is turned off). Before commit 6dbbf84603961, if we constantly
switched between the front and back camera eventually we would hit the
below error in drivers/pinctrl/pinmux.c:pin_request():

    E samsung-pinctrl 10840000.pinctrl: could not increase module
refcount for pin 134

In our kernel the sensor GPIOs don't have pin_ranges defined. So you
would get these call stacks:

Sensor Enable:
  gpiochip_generic_request()
  -> return 0

Sensor Disable:
  gpiochip_generic_free()
  -> pinctrl_gpio_free()

This led to an imbalance of request vs free calls leading to the
refcounting error. When we added commit 6dbbf84603961 ("gpiolib: Don't
free if pin ranges are not defined"), this issue was resolved. My
recommendation would be to drill down into your driver to figure out
what happens in these functions to see why you're getting the results
you reported.

--Will

  reply	other threads:[~2021-12-20 19:25 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-12-17 15:35 [PATCH] gpio: Revert regression in sysfs-gpio (gpiolib.c) Marcelo Roberto Jimenez
2021-12-18  6:28 ` Thorsten Leemhuis
2021-12-20 14:57   ` Bartosz Golaszewski
2021-12-20 15:14     ` Geert Uytterhoeven
2021-12-20 19:24       ` Will McVicker [this message]
2021-12-20 20:41         ` Marcelo Roberto Jimenez
2021-12-20 20:41       ` Marcelo Roberto Jimenez
2021-12-20 20:41     ` Marcelo Roberto Jimenez
2022-01-10  7:02       ` Thorsten Leemhuis
2022-01-12  0:09         ` Marcelo Roberto Jimenez
2022-02-08 12:24           ` Thorsten Leemhuis
2022-02-17 19:11           ` Thierry Reding
2022-02-11  0:02 ` Linus Walleij
2022-02-11 22:36   ` Marcelo Roberto Jimenez
2022-02-12 16:54     ` Linus Walleij
2022-02-13 23:23       ` Marcelo Roberto Jimenez
2022-02-15 21:56         ` Linus Walleij
2022-02-16 14:40           ` Bartosz Golaszewski
2022-03-04  7:13             ` Thorsten Leemhuis
2022-03-07  9:58               ` Bartosz Golaszewski
2022-03-07 10:12                 ` Thorsten Leemhuis
2022-05-20  9:12             ` Thorsten Leemhuis
2022-05-20 17:28               ` Marcelo Roberto Jimenez
2022-03-14 15:55 ` Michael Walle
2022-03-15 15:32   ` Bartosz Golaszewski
2022-03-15 15:45     ` Michael Walle
2022-03-17  8:37       ` Andy Shevchenko
2022-03-17  8:48         ` Michael Walle

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='CABYd82b2i4Uuyi5+zLoTgiC-QMS1y=VkwmMznZqxLca0iP9qTQ@mail.gmail.com' \
    --to=willmcvicker@google.com \
    --cc=achant@google.com \
    --cc=brgl@bgdev.pl \
    --cc=edmondchung@google.com \
    --cc=geert@linux-m68k.org \
    --cc=linus.walleij@linaro.org \
    --cc=linux-gpio@vger.kernel.org \
    --cc=marcelo.jimenez@gmail.com \
    --cc=regressions@leemhuis.info \
    --cc=regressions@lists.linux.dev \
    --cc=sfr@canb.auug.org.au \
    --cc=stable@vger.kernel.org \
    --cc=tanzilli@acmesystems.it \
    --cc=treding@nvidia.com \
    --cc=vidyas@nvidia.com \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).