Re: [PATCH] input: gpio_keys: polling mode support
From: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Date: 2010-07-13 01:28:24
On Tue, Jul 13, 2010 at 10:17:07AM +0900, Paul Mundt wrote:
On Mon, Jul 12, 2010 at 08:29:51PM +0100, Alexander Clouter wrote:quoted
Hi, -EDONTCARE? :(You could try Cc-ing akpm on the next version, so it at least doesn't get lost.quoted
quoted
+#if defined(CONFIG_INPUT_POLLDEV) || defined(CONFIG_INPUT_POLLDEV_MODULE) +static void gpio_keys_poll(struct input_polled_dev *dev) +{ + struct gpio_keys_drvdata *ddata = dev->private; + int i; + + for (i = 0; i < ddata->n_buttons; i++) { + struct gpio_button_data *bdata = &ddata->data[i]; + struct gpio_keys_button *button = bdata->button; + + gpio_handle_button_event(button, bdata); + } +} +#endif +This gets back to why I opted to select the polldev stuff in the first place, to avoid the total mess that all of the ifdeffery causes without it. It's also inconsistent, as you have the poll interval tested openly in some places and always defined, while the poll dev itself is always under ifdef due to the input layer definitions. Personally I've never found the argument that the polling stuff should be optional very convincing. It's a reasonable mode of operation for devices that don't have IRQs bound to GPIOs, and having to depend on the platform to select random bits of input subsystem infrastructure to support a driver that may or may not be enabled at all is ugly at best.
Let me play a tad with it and if I can't untangle it reasonably I'll just dig up old Paul's patch. -- Dmitry