Messages in this thread | | | From | Vincent Pelletier <> | Date | Mon, 28 Jun 2021 12:36:53 +0900 | Subject | gpiochip_lock_as_irq on pins without FLAG_REQUESTED: bug or feature ? |
| |
Hello,
While trying to debug an IRQ handling issue on a sifive-unmatched board (which is a very recent board on a recent architecture, so I would not be overly surprised if there were bugs in hiding), I realised that I was able to claim via sysfs GPIO pins which are being actively used as IRQ sources.
Checking drivers/gpio/gpiolib.c and kernel/irq/chip.c, I believe this is because gpiolib (gpiochip_irq_reqres, gpiochip_reqres_irq, gpiochip_lock_as_irq) does not call gpiod_request_{,commit}, resulting in a pin which is available for use. I could confirm this by adding (just as a debugging aid): WARN_ON(!test_bit(FLAG_REQUESTED, &desc->flags)); early in gpiochip_lock_as_irq, and this statement gets triggered.
Is this intentional ? Does this requesting belong to something else in the codepath from request_threaded_irq (and similar) ? Could it be something missing in the devicetree for this board ?
Also, I notice that both gpiochip_hierarchy_add_domain and gpiochip_reqres_irq call gpiochip_lock_as_irq, and I am surprised I do not get any error about this: in my understanding only the first call on a given pin should succeed, but with my WARN_ON I am seeing both stack traces and no other warning.
FWIW, my builds are based on vanilla 5.13-rc6.
Regards, -- Vincent Pelletier
| |