How about a gpio_get(device *, char *) function?

[Linus Walleij]

On Thu, Nov 8, 2012 at 7:23 AM, Alex Courbot <acourbot at 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 <acourbot at 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