linux-kernel - Re: gpiochip_lock_as_irq on pins without FLAG

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: <CAF78GY1PO3YwYHgQkEhYF1_FRQ=HVOOWFtECcHen9PFCR1=JOA@mail.gmail.com>
Date:   Tue, 29 Jun 2021 07:52:24 +0900
From:   Vincent Pelletier <plr.vincent@...il.com>
To:     Andy Shevchenko <andy.shevchenko@...il.com>
Cc:     Linus Walleij <linus.walleij@...aro.org>,
        Bartosz Golaszewski <bgolaszewski@...libre.com>,
        "open list:GPIO SUBSYSTEM" <linux-gpio@...r.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: gpiochip_lock_as_irq on pins without FLAG_REQUESTED: bug or
 feature ?

On Mon, Jun 28, 2021 at 10:42 PM Andy Shevchenko
<andy.shevchenko@...il.com> wrote:
> And one important note: do NOT use sysfs GPIO interface. Use a GPIO
> character device instead.

I am indeed aware of this. My IRQ issue is unrelated to the gpios
being claimed by anything, and I was doing it while trying to get
more information about the current state of the gpio driver.

For more background, the context of my IRQ issue is:
  PMIC (da9063) /irq -> GPIO pin 1 -> PLIC irq 24
The PMIC has several internal interrupt sources, like the power
button being pressed or the ADC conversion completion signal.
The first time after a boot that I press the power button, I do
get an interrupt and the da9063-onkey driver produces a keypress
input event.
But any further button press does not produce an IRQ. So something
is going wrong in the IRQ acknowledgement.
AFAIK the PLIC (platform-level interrupt controller) works: it is
used for PCIe interrupts, and those work.
The PMIC driver exists since 2013, so I assume any bug would have
been identified long ago.
But I believe the GPIO level has not handled any interrupt until I
enabled the power button event source, and this one is a lot more
recent: gpio-sifive.c from late 2019. So this is where I turned my
attention. Discovering that the pin is somehow only half-claimed
made me wonder if there was some important initialisation step
missing, which could maybe be related to these IRQ issues.

While on this topic, there is a bullet point in
Documentation/driver-api/gpio/driver.rst which I fail to understand:

| - Nominally set all handlers to handle_bad_irq() in the setup call and pass
|   handle_bad_irq() as flow handler parameter in
gpiochip_irqchip_add() if it is
|   expected for GPIO driver that irqchip .set_type() callback will be called
|   before using/enabling each GPIO IRQ. Then set the handler to
|   handle_level_irq() and/or handle_edge_irq() in the irqchip .set_type()
|   callback depending on what your controller supports and what is requested
|   by the consumer.

- why the plural in "set all handlers to handle_bad_irq()" ? Isn't
  there only a single handler in struct gpio_irq_chip ?
- I do not find a function named gpiochip_irqchip_add(), only
  gpiochip_irqchip_add_domain()
- "Then set the handler to [...] in the irqchip .set_type() callback"
  Isn't set_type per-pin, and isn't the interrupt handler chip-level ?

Regards,
-- 
Vincent Pelletier