Thread (8 messages) 8 messages, 3 authors, 2010-07-13

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
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help