Messages in this thread | | | From | Bartosz Golaszewski <> | Date | Tue, 15 Mar 2022 17:48:32 +0100 | Subject | Re: Linux 5.17-rc8 |
| |
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
| |