On Fri, Feb 22, 2008 at 03:42:03PM -0800, David Brownell wrote: > 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?
I like it. :-) Thanks. p.s. would be great to see this in 2.6.25, so we can start use this include for the new code. -- Anton Vorontsov email: [EMAIL PROTECTED] backup email: [EMAIL PROTECTED] irc://irc.freenode.net/bd2 _______________________________________________ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
