From: Bartosz Golaszewski <brgl@bgdev.pl>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Marcelo Roberto Jimenez <marcelo.jimenez@gmail.com>,
Guenter Roeck <linux@roeck-us.net>,
Thierry Reding <treding@nvidia.com>,
Linus Walleij <linus.walleij@linaro.org>,
Vidya Sagar <vidyas@nvidia.com>,
Edmond Chung <edmondchung@google.com>,
Andrew Chant <achant@google.com>,
Will McVicker <willmcvicker@google.com>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: Linux 5.17-rc8
Date: Tue, 15 Mar 2022 17:48:32 +0100 [thread overview]
Message-ID: <CAMRc=MfK1ak6BN27BuLAV3cyD8kRSdfQOovOsKqF35GBhJqpWQ@mail.gmail.com> (raw)
In-Reply-To: <CAHk-=wh0QBksyaTEn4gk=mn6hgAhp3e8i9mRsr657Dd-kQ3MKg@mail.gmail.com>
On Tue, Mar 15, 2022 at 2:47 AM Linus Torvalds
<torvalds@linux-foundation.org> wrote:
>
> On Mon, Mar 14, 2022 at 5:45 PM Marcelo Roberto Jimenez
> <marcelo.jimenez@gmail.com> wrote:
> >
> > At a certain point, I tried Thorsten's suggestion to add a gpio-ranges
> > property in a way similar to another patch, but the kernel went into
> > an EPROBE_DEFER deadlock. Thierry Reding made some comments about this
> > in the sequence.
>
> Hmm. The problem does sound like that particular driver doesn't use
> the pin_ranges thing, so then the tests for an empty pin_ranges will
> always be true.
>
> The EPROBE_DEFER deadlock then sounds like something went wrong in the
> gpio-ranges patch when you tried to fix it - but I don't actually find
> that patch or that attempt, so I can't even guess at it.
>
> This whole code pin_ranges code looks very odd:
> gpiochip_add_pin{group}_range() seems to add the pin ranges properly,
> but that actual gpiochip_add_pin_ranges() function does *not*.
>
> It just expects that that the 'add_pin_ranges()' callback exists, and
> if it doesn't, does nothing at all.
>
> Which then makes those
>
> if (list_empty(&gc->gpiodev->pin_ranges))
> return 0;
>
> tests very suspicious - because if some doesn't implement that
> add_pin_ranges() callback, it looks like nothing at all ever gets
> done, because nothing calls the function to actually add the pinrange.
> And then that "list_empty()" test very much will trigger.
>
> IOW, it looks like either a gpio controller has to implement that
> 'add_pin_ranges()' function (only tegra), or it needs to always add
> the pin ranges at probe time.
>
> Am I guessing right that the driver that you use does neither?
>
There are more drivers than just tegra that implement add_pin_ranges()
but you're right, pinctrl-at91.c used by Marcelo does not.
> LinusW/Bartoz - this all really sounds strange to me. Maybe I'm
It's BartoSz actually. :)
> misreading the situation entirely. Should there be some sanity-test
> that any gpio/pinctrl driver that uses gpiochip_generic_request()
> would either have to have that add_pin_ranges() callback, or a
> successful probe needs to always populate that 'gpiodev->pin_ranges'
> list?
>
This sounds right to me but I need to spend some more time on this, I
didn't author the code in question.
> Or maybe I'm misreading the situation entirely. I don't know the code
> - I'm just grepping for things and trying to make sense of how that
> '->pin_ranges' list is supposed to work.
>
> But for now, I think that patch has to be reverted.
>
Sounds good, I'll send a revert and make another PR with fixes before v5.17.
Bartosz
> Linus
next prev parent reply other threads:[~2022-03-15 16:48 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-03-13 20:43 Linux 5.17-rc8 Linus Torvalds
2022-03-14 7:55 ` Build regressions/improvements in v5.17-rc8 Geert Uytterhoeven
2022-03-14 19:25 ` Linux 5.17-rc8 Guenter Roeck
2022-03-14 20:13 ` Linus Torvalds
2022-03-15 0:45 ` Marcelo Roberto Jimenez
2022-03-15 1:13 ` Guenter Roeck
2022-03-15 1:47 ` Linus Torvalds
2022-03-15 5:42 ` Thorsten Leemhuis
2022-03-15 16:48 ` Bartosz Golaszewski [this message]
2022-03-15 9:05 ` Geert Uytterhoeven
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='CAMRc=MfK1ak6BN27BuLAV3cyD8kRSdfQOovOsKqF35GBhJqpWQ@mail.gmail.com' \
--to=brgl@bgdev.pl \
--cc=achant@google.com \
--cc=edmondchung@google.com \
--cc=linus.walleij@linaro.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux@roeck-us.net \
--cc=marcelo.jimenez@gmail.com \
--cc=torvalds@linux-foundation.org \
--cc=treding@nvidia.com \
--cc=vidyas@nvidia.com \
--cc=willmcvicker@google.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).