Messages in this thread | | | Date | Tue, 15 Mar 2022 06:42:39 +0100 | Subject | Re: Linux 5.17-rc8 | From | Thorsten Leemhuis <> |
| |
[CCing regressions list and Michael Walle]
FWIW, I was a bit surprised to see this, I had assumed the revert that causing trouble (fc328a7d1fcc) would go in the next merge window. Seems my regression tracking work did more harm then good here. :-/ Whatever:
On 15.03.22 02:47, Linus Torvalds 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. > > [...] > > 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.
There is a another reason to do so: Michael Walle reported that the revert is causing a regression for him: https://lore.kernel.org/stable/20220314155509.552218-1-michael@walle.cc/
To quote:
``` > This breaks the pinctrl-microchip-sgpio driver as far as I can see. > > I tried to debug it and this is what I have discovered so far: > (1) the sgpio driver will use the gpio_stub_drv for its child nodes. > Looks like a workaround, see [1]. > (2) these will have an empty gpio range > (3) with the changes of this patch, pinctrl_gpio_request() will now > be called and will fail with -EPROBE_DEFER. > > I'm not exactly sure what to do here. Saravana Kannan once suggested > to use devm_of_platform_populate() to probe the child nodes [2]. But > I haven't found any other driver doing that. > > Also, I'm not sure if there are any other other driver which get > broken by this. I.e. ones falling into the gpio_stub_drv category. > > [1] https://lore.kernel.org/lkml/20210122193600.1415639-1-saravanak@google.com/ > [2] https://lore.kernel.org/lkml/CAGETcx9PiX==mLxB9PO8Myyk6u2vhPVwTMsA5NkD-ywH5xhusw@mail.gmail.com/ > > -michael > > NB. this patch doesn't contain a Fixes tag. Was this on purpose? ```
Ciao, Thorsten
| |