Re: Proper way to handle GPIO IRQ enablement

Tomasz Bursztyka


Knowing this, I have a couple of questions:

First, is this already a known and accepted issue that a user is
expected to know to avoid? (Obviously, this would be at the price of
having the most efficient list insertion which seems like an
acceptable tradeoff)
Actually you found a bug. It's not up to the user to know that the cb
is already installed (even though, logically it does not make sense to
add the same cb many times), in other words: gpio should not blindly
install an already installed cb.

I'll open an issue. I think it should check the status of the node, if
already set up, it will try to find it and return an error: -EALREADY
if found, or -EINVAL as it might have been inserted into another
controller's list and we should not touch it.

Once my IRQ pin is configured and my callback added, it looks like I
should ONLY ever use gpio_pin_[enable|disable]_callback() to enable
or disable the IRQ? This is okay, but requires me to maintain more
state in my peripheral device driver. It would be nice if something
catastrophic happens, I could blindly reinitialize my driver and
either (a) have a GPIO api to check if a callback is already
registered before calling gpio_add_callback() or (b) the
gpio_add_callback() function will do nothing if the callback is
already in the list.
I think my fix proposal above should clarify that.
If it returns 0 or -EALREADY, all will be fine.

Any recommendation or comments are appreciated! Or perhaps I'm off
base on something, let me know!
No that was a good catch!



Join to automatically receive all group messages.