> What do you mean? In <linux/gpio.h> I see:
>
> struct gpio {
> unsigned gpio;
> (...)
>
> static inline int gpio_get_value(unsigned int gpio)
> {
> return __gpio_get_value(gpio);
> }
>
> And in <linux/i2c-gpio.h>:
>
> struct i2c_gpio_platform_data {
> unsigned int sda_pin;
> unsigned int scl_pin;
> (...)
I remembered this paragraph from Documentation/gpio.txt:
===
If you want to initialize a structure with an invalid GPIO number, use
some negative number (perhaps "-EINVAL"); that will never be valid. To
test if such number from such a structure could reference a GPIO, you
may use this predicate:
int gpio_is_valid(int number);
...
===
Confusingly, I know found that the chapter starts with
===
GPIOs are identified by unsigned integers in the range 0..MAX_INT. That
reserves "negative" numbers for other purposes like marking signals as
"not available on this board", or indicating faults.
===
Meh.
> If you still have a concern about the types used, please clarify and
> let me know what change you expect.
Leave it. I think the fragile part is gpio_is_valid() but this is truly
outside the scope of this patch.
> > > + ret = gpio_request(sda_pin, "sda");
> > > + if (ret) {
> > > + if (ret == -EINVAL)
> > > + ret = -EPROBE_DEFER; /* Try again later */
> >
> > Would gpio_request_array() make the code simpler?
>
> I gave it a try, this indeed makes the code slightly simpler (-4 lines)
> but the resulting binary slightly larger (+40 bytes on x86-64.) I'd say
> it's not worth it?
OK. Then leave it.
> Note that my patch doesn't introduce the gpio_request() calls, they
> were there before, so this decision is actually independent from my
> patch, and even if we decide to switch to using gpio_request_array(),
> I'd rather do it in a separate patch for clarity.
I don't fully get it. Do you want to appl gpio_request() to this patch?
Otherwise, I'd take it as is.
Thanks,
Wolfram
--
To unsubscribe from this list: send the line "unsubscribe linux-i2c" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
