On Mon, Mar 07, 2016 at 06:07:07PM +0200, Johan Hedberg wrote:
On Mon, Mar 07, 2016, Tomasz Bursztyka wrote:
-typedef void (*gpio_callback_t)(struct device *port, uint32_t pin);I realize this typedef is inherited from the original code, but do we
+ void (*handler)(struct device *port,
+ gpio_callback_t *cb,
+ uint32_t pins);
+ uint32_t pin_mask;
+ struct gpio_callback *_next;
+typedef struct gpio_callback gpio_callback_t;
really need/want to enforce an opaque type here? The general preference
with the coding style (inherited from Linux and checkpatch even
complains about it) is to avoid typedefs whenever possible. I could e.g.
imagine a handler function wanting set/unset some pins in the pin_mask
when it gets called, in which case the struct couldn't be considered
Another thing is: it seems like that you expect the app developers
to statically allocate a bunch of this struct to have multiple callbacks.
This is, AFAIK, not a common practice when setting callbacks. Developers
may simply allocate a struct in stack (like inside a function) and
pass it to the function. This struct may go out of scope, and
the resulting errors and exceptions will be confusing to developers.
Could we do something to mitigate this?