[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CACRpkdbeYkQiUjb0t2XWik1j1qQTUZZVyjkASMgpE24DWLx0fQ@mail.gmail.com>
Date: Tue, 2 Mar 2021 15:52:37 +0100
From: Linus Walleij <linus.walleij@...aro.org>
To: Andy Shevchenko <andriy.shevchenko@...ux.intel.com>
Cc: Bartosz Golaszewski <bgolaszewski@...libre.com>,
Mika Westerberg <mika.westerberg@...ux.intel.com>,
"open list:GPIO SUBSYSTEM" <linux-gpio@...r.kernel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
ACPI Devel Maling List <linux-acpi@...r.kernel.org>,
"Rafael J. Wysocki" <rjw@...ysocki.net>,
Len Brown <lenb@...nel.org>
Subject: Re: [PATCH v1 3/3] gpio: pca953x: Set IRQ type when handle Intel
Galileo Gen 2
On Thu, Feb 25, 2021 at 5:33 PM Andy Shevchenko
<andriy.shevchenko@...ux.intel.com> wrote:
> The commit 0ea683931adb ("gpio: dwapb: Convert driver to using the
> GPIO-lib-based IRQ-chip") indeliberately made a regression on how
> IRQ line from GPIO I²C expander is handled. I.e. it reveals that
> the quirk for Intel Galileo Gen 2 misses the part of setting IRQ type
> which previously was predefined by gpio-dwapb driver. Now, we have to
> reorganize the approach to call necessary parts, which can be done via
> ACPI_GPIO_QUIRK_ABSOLUTE_NUMBER quirk.
>
> Without this fix and with above mentioned change the kernel hangs
> on the first IRQ event with:
>
> gpio gpiochip3: Persistence not supported for GPIO 1
> irq 32, desc: 62f8fb50, depth: 0, count: 0, unhandled: 0
> ->handle_irq(): 41c7b0ab, handle_bad_irq+0x0/0x40
> ->irq_data.chip(): e03f1e72, 0xc2539218
> ->action(): 0ecc7e6f
> ->action->handler(): 8a3db21e, irq_default_primary_handler+0x0/0x10
> IRQ_NOPROBE set
> unexpected IRQ trap at vector 20
>
> Fixes: ba8c90c61847 ("gpio: pca953x: Override IRQ for one of the expanders on Galileo Gen 2")
> Depends-on: 0ea683931adb ("gpio: dwapb: Convert driver to using the GPIO-lib-based IRQ-chip")
I never saw that before, seems useful!
> Signed-off-by: Andy Shevchenko <andriy.shevchenko@...ux.intel.com>
Not only does it fix the bug, it also looks so much better by
separation of concerns.
Reviewed-by: Linus Walleij <linus.walleij@...aro.org>
Yours,
Linus Walleij
Powered by blists - more mailing lists