Re: [PATCH] gpio: Revert regression in sysfs-gpio (gpiolib.c)

[Thorsten Leemhuis <regressions@xxxxxxxxxxxxx>]

Hi, this is your Linux kernel regression tracker speaking.

On 20.12.21 21:41, Marcelo Roberto Jimenez wrote:
> On Mon, Dec 20, 2021 at 11:57 AM Bartosz Golaszewski <brgl@xxxxxxxx> wrote:
>> On Sat, Dec 18, 2021 at 7:28 AM Thorsten Leemhuis
>> <regressions@xxxxxxxxxxxxx> wrote:
>>>
>>> [TLDR: I'm adding this regression to regzbot, the Linux kernel
>>> regression tracking bot; most text you find below is compiled from a few
>>> templates paragraphs some of you might have seen already.]
>>>
>>> On 17.12.21 16:35, Marcelo Roberto Jimenez wrote:
>>>> Some GPIO lines have stopped working after the patch
>>>> commit 2ab73c6d8323f ("gpio: Support GPIO controllers without pin-ranges")
>>>>
>>>> And this has supposedly been fixed in the following patches
>>>> commit 89ad556b7f96a ("gpio: Avoid using pin ranges with !PINCTRL")
>>>> commit 6dbbf84603961 ("gpiolib: Don't free if pin ranges are not defined")
>>>
>>> There seems to be a backstory here. Are there any entries and bug
>>> trackers or earlier discussions everyone that looks into this should be
>>> aware of?
>>
>> Agreed with Thorsten. I'd like to first try to determine what's wrong
>> before reverting those, as they are correct in theory but maybe the
>> implementation missed something.
>>
>> Have you tried tracing the execution on your platform in order to see
>> what the driver is doing?
> 
> Yes. The problem is that there is no list defined for the sysfs-gpio
> interface. The driver will not perform pinctrl_gpio_request() and will
> return zero (failure).
> 
> I don't know if this is the case to add something to a global DTD or
> to fix it in the sysfs-gpio code.

Out of interest, has any progress been made on this front?

BTW, there was a last-minute commit for 5.16 yesterday that referenced
the culprit Marcelo specified:

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?h=master&id=c8013355ead68dce152cf426686f8a5f80d88b40

This was for a BCM283x and BCM2711 devices, so I assume it won't help.
Wild guess (I don't know anything about this area of the kernel):
Marcelo, do the dts files for your hardware maybe need a similar fix?

Ciao, Thorsten

P.S.: As a Linux kernel regression tracker I'm getting a lot of reports
on my table. I can only look briefly into most of them. Unfortunately
therefore I sometimes will get things wrong or miss something important.
I hope that's not the case here; if you think it is, don't hesitate to
tell me about it in a public reply, that's in everyone's interest.

BTW, I have no personal interest in this issue, which is tracked using
regzbot, my Linux kernel regression tracking bot
(https://linux-regtracking.leemhuis.info/regzbot/). I'm only posting
this mail to get things rolling again and hence don't need to be CC on
all further activities wrt to this regression.

#regzbot poke