lkml.org 
[lkml]   [2022]   [Mar]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
SubjectRe: Linux 5.17-rc8
From
[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

\
 
 \ /
  Last update: 2022-03-15 06:43    [W:0.151 / U:0.032 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site