On Thu, Nov 8, 2012 at 7:23 AM, Alex Courbot <acour...@nvidia.com> wrote: > On Thursday 08 November 2012 05:24:19 Linus Walleij wrote: >> On Tue, Nov 6, 2012 at 2:33 AM, Alex Courbot <acour...@nvidia.com> wrote: >> > How about, in a first time (and because I'd also like to get the power >> > seqs >> > moving on), a typedef from int to gpio_handle_t and a first implementation >> > of the gpio_handle_*() API that would just call the existing >> > integer-based API (apart from gpio_handle_get())? That way things will >> > not break when we switch to a real handle. >> >> I'm afraid of typedef:ing gpio_handle_t to int because it sort of >> encourages non-handlers to be used mixed with the old integers. >> >> I would prefer to create, e.g. in <linux/gpio/consumer.h> >> something like: >> >> struct gpio; >> >> struct gpio *gpio_get(struct device *dev, const char *name); >> >> int gpio_get_value(struct gpio *g); >> >> Nothing more! I.e. struct gpio is an opaque cookie, nothing to be known >> about it. > > However these is already a struct gpio declared in linux/gpio.h. Shall the > opaque handler be renamed something like "struct gpioh", or is your idea to > make both APIs mutually exclusive?
Basically I'd like the API's to be mutually execlusive. But maybe there is a namespace clash anyway, since the handler code will have to #linclude <linux/gpio.h> This is one of the rare cases where I'd maybe like to even #undef gpio in the core code just to be able to mask that defintion of "gpio" with the "gpio" from the new API. I really like the fact that it will bite your hand if you try to use both APIs at once, you could even introduce some #define DO_NOT_INCLUDE_LINUX_GPIO_H in <linux/gpio/consumer.h> And #define DO_NOT_INCLUDE_GPIO_CONSUMER_H in <linux/gpio.h> and then put things like: #ifdef DO_NOT_INCLUDE_LINUX_GPIO_H #error "Trying to use mutually exclusive interfaces" #endif into <linux/gpio.h>... Yours, Linus Walleij -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
