Re: Linux 5.17-rc8

From: Thorsten Leemhuis <linux@leemhuis.info>
To: Linus Torvalds <torvalds@linux-foundation.org>,
	Marcelo Roberto Jimenez <marcelo.jimenez@gmail.com>
Cc: 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>,
	Bartosz Golaszewski <brgl@bgdev.pl>,
	"regressions@lists.linux.dev" <regressions@lists.linux.dev>,
	Michael Walle <michael@walle.cc>
Subject: Re: Linux 5.17-rc8
Date: Tue, 15 Mar 2022 06:42:39 +0100	[thread overview]
Message-ID: <e5302bda-ba48-4308-2b3a-a686e9430055@leemhuis.info> (raw)
In-Reply-To: <CAHk-=wh0QBksyaTEn4gk=mn6hgAhp3e8i9mRsr657Dd-kQ3MKg@mail.gmail.com>

[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