Re: [PATCH] input: gpio_keys: polling mode support

[Paul Mundt <lethal@linux-sh.org>]

On Mon, Jul 12, 2010 at 08:29:51PM +0100, Alexander Clouter wrote:
> Hi,
> 
> -EDONTCARE? :(
> 
You could try Cc-ing akpm on the next version, so it at least doesn't get
lost.

> >  
> > +#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.