Messages in this thread | | | From | Linus Torvalds <> | Date | Mon, 14 Mar 2022 18:47:11 -0700 | Subject | Re: Linux 5.17-rc8 |
| |
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?
LinusW/Bartoz - this all really sounds strange to me. Maybe I'm 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?
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.
Linus
| |