Re: [PATCH v2] gpiolib: Add gpio_debounce and gpio_alt_funcfeatures to GPIOLIB

[Ben Nizette]

On Wed, 2009-06-17 at 14:59 +0800, Alek Du wrote:
> Changes from v1:
> 
> Removed gpio_detect since we should do that with irq_chip.set_type function.
> 
> 
> From 6b3c9398acf338c263170fcb74c0b2b345ad5369 Mon Sep 17 00:00:00 2001
> From: Alek Du <alek.du@xxxxxxxxx>
> Date: Wed, 17 Jun 2009 14:50:51 +0800
> Subject: [PATCH] GPIO: Add gpio_debounce and gpio_alt_func features to GPIOLIB
> 
> Add gpio_debounce and gpio_alt_func features to GPIOLIB:
> * gpio_debounce is to adjust signal HW debounce value (need HW support)
> * gpio_alt_func is to set GPIO as alternative function (need HW support)


Please justify the existence of these functions, particularly, who's
supposed to actually call them?  There's no real changelogging here.

First the hardware debounce call.  Hardware debounce functionality
varies massively between chips.  Therefore a driver cannot depend on any
particular behaviour unless it already knows what platform it's running
on.  If it knows the platform it can access the functions directly and
the interface needs no abstraction.  If the driver doesn't know the
platform it can't get any value from the call.  Worse, people are going
to start /expecting/ some behaviour from the call and wonder why their
driver fails subtly on slightly different systems.

Who's supposed to set the alternate functions?  As I see it, only the
board code.  The driver shouldn't ever have to do this itself, all the
pin mux'ing should be done well before the driver needs to access its
pins.  Even if the driver does need to set up it's own pins then it
needs to know /which/ alternate function it is which once again requires
platform knowledge.  If it requires platform knowledge it should be done
in platform code, not driver code, or can at least be done with
non-abstracted calls.

These both seem like needless feature creep and misdirection to me.

	--Ben.


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/