On Fri, 2007-11-16 at 15:02 +0100, pHilipp Zabel wrote: > On Nov 16, 2007 2:38 PM, Dmitry Torokhov <[EMAIL PROTECTED]> wrote: > > On Nov 16, 2007 6:33 AM, Herbert Valerio Riedel <[EMAIL PROTECTED]> wrote: > > > Currently, gpio_keys.c assumes the GPIOs to be already properly > > > configured; > > > this patch changes gpio-keys to perform explicit calls to gpio_request() > > > and > > > gpio_configure_input(). > > > > > > This matches the behaviour of leds-gpio.
> > Makes sense from where I sit but let's see what guys who actually use > > the module say... ;) > Looks good to me, too. I have yet to test, but at least the gpio_direction > call > is mandatory as per gpio api docs, so this fixes an actual bug. > gpio_request is optional and claims the GPIO for this driver's use > only (on architectures where this is supported), so I'm not sure if this is > really needed, but it > shouldn't harm any of the current users of gpio-keys. yes, optional and no-harm, to quote the gpio API doc: > These two calls are optional because not not all current Linux platforms > offer such functionality in their GPIO support; a valid implementation > could return success for all gpio_request() calls. Unlike the other calls, > the state they represent doesn't normally match anything from a hardware > register; it's just a software bitmap which clearly is not necessary for > correct operation of hardware or (bug free) drivers. ...but for instance, the current mach-orion/gpio.c implementation, prints annoying printk warnings when someone fiddles with "unrequested" GPIOs... :-) cheers, hvr - To unsubscribe from this list: send the line "unsubscribe linux-input" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
