On Monday 10 December 2007, Anton Vorontsov wrote: > On Mon, Dec 10, 2007 at 02:55:24PM -0800, David Brownell wrote:
> > The point of CONFIG_GENERIC_GPIO is to be *the* conditional used to > > tell whether that programming interface is available ... starting > > from "#include <asm/gpio.h>", and including all gpio_*() calls. > > > > So my first reaction is to not like this patch. It changes semantics > > in an incompatible way. And AFAICT, needlessly so. > > Why incompatible? gpio-aware drivers will get -ENOSYS on gpio_request, > thus they will not do anything wrong. GPIO-only drivers could still > depend on GENERIC_GPIO, and their behaviour will not change. If you still want this, I think a better approach would be: http://marc.info/?l=linux-kernel&m=120295461410848&w=2 That is, #include <linux/gpio.h> and have *that* do the relevant switch, based on GENERIC_GPIO. No semantic changes at all, if one discounts the implicit switch to <linux/gpio.h> (important for platforms that don't *have* any <asm/gpio.h> header), which won't affect any existing code. So your NAND code could use that, and work equally well on SOC variants that have generic GPIOs and those that don't. Comments? - Dave _______________________________________________ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
