[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <6422b80a-7588-eeaa-360d-ae12c7628ee0@zonque.org>
Date: Wed, 6 Sep 2023 22:50:23 +0200
From: Daniel Mack <daniel@...que.org>
To: Arnd Bergmann <arnd@...db.de>,
Thorsten Leemhuis <regressions@...mhuis.info>,
"open list:GPIO SUBSYSTEM" <linux-gpio@...r.kernel.org>,
manikanta.guntupalli@....com
Cc: linux-kernel@...r.kernel.org, stable@...nel.org,
Bartosz Golaszewski <bartosz.golaszewski@...aro.org>,
Linus Walleij <linus.walleij@...aro.org>,
Linux kernel regressions list <regressions@...ts.linux.dev>
Subject: Re: [PATCH] gpio: zynq: restore
zynq_gpio_irq_reqres/zynq_gpio_irq_relres callbacks
On 9/6/23 22:12, Arnd Bergmann wrote:
>> On 01.09.23 14:24, Daniel Mack wrote:
>>> Commit f56914393537 ("gpio: zynq: fix zynqmp_gpio not an immutable chip
>>> warning") ditched the open-coded resource allocation handlers in favor
>>> of the generic ones. These generic handlers don't maintain the PM
>>> runtime anymore, which causes a regression in that level IRQs are no
>>> longer reported.
>>>
>>> Restore the original handlers to fix this.
>>>
>>> Signed-off-by: Daniel Mack <daniel@...que.org>
>>> Fixes: f56914393537 ("gpio: zynq: fix zynqmp_gpio not an immutable chip warning")
>>> Cc: stable@...nel.org
>>
>> This seems to be a regression report that comes straight with a fix, but
>> there wasn't a single reply yet afaics. :-/ Maybe the extended list of
>> recipients will get things moving. But to ensure this doesn't fall
>> through the cracks, I'll add it to the list of tracked regressions.
>
> I don't understand what the GPIOCHIP_IRQ_RESOURCE_HELPERS change
> intended to do in the first place: Manikanta's patch changed the behavior
> here with the addition of GPIOCHIP_IRQ_RESOURCE_HELPERS, while my patch
> was a cleanup that removed the dead code.
Manikanta's patch (f56914393537 "gpio: zynq: fix zynqmp_gpio not an
immutable chip warning") did many things at once, the move to the
generic resource handlers was just one of the changes. I can only guess
that it intended to simply the code a bit, and the dropped pm runtime
detail was just an oversight.
> Daniel's fix reverts both my cleanup patch and part of the original
> change, which may or may not be what we want here.
Enabling the pm runtime is necessary on my boards, at least for level
IRQs. Edge IRQs are still handled fine, interestingly.
Thanks,
Daniel
Powered by blists - more mailing lists