linux-kernel - Re: Linux 5.17-rc8

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <e5302bda-ba48-4308-2b3a-a686e9430055@leemhuis.info>
Date:   Tue, 15 Mar 2022 06:42:39 +0100
From:   Thorsten Leemhuis <linux@...mhuis.info>
To:     Linus Torvalds <torvalds@...ux-foundation.org>,
        Marcelo Roberto Jimenez <marcelo.jimenez@...il.com>
Cc:     Guenter Roeck <linux@...ck-us.net>,
        Thierry Reding <treding@...dia.com>,
        Linus Walleij <linus.walleij@...aro.org>,
        Vidya Sagar <vidyas@...dia.com>,
        Edmond Chung <edmondchung@...gle.com>,
        Andrew Chant <achant@...gle.com>,
        Will McVicker <willmcvicker@...gle.com>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Bartosz Golaszewski <brgl@...ev.pl>,
        "regressions@...ts.linux.dev" <regressions@...ts.linux.dev>,
        Michael Walle <michael@...le.cc>
Subject: Re: Linux 5.17-rc8

[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@...il.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