Re: [PATCH] gpiolib: fix oops on reading sysfs exported GPIOs

[David Brownell]

On Thursday 16 October 2008, Anton Vorontsov wrote:
> > Not true; the API explicitly allows GPIOs to be treated
> > as bidirectional, even when they're configured as outputs.
> > That's because most GPIOs *are* bidirectional.
>
> I just recalling somebody was speaking about not wasting cycles with
> the checks in the gpio_{set,get}_value().

void __gpio_set_value(unsigned gpio, int value)
{
        struct gpio_chip        *chip;

        chip = gpio_to_chip(gpio);
        WARN_ON(extra_checks && chip->can_sleep);
        chip->set(chip, gpio - chip->base, value);
}

So not many checks there at all.  The get() path has one
additional check -- is the method null? -- for the reason
summarized above.  And if you're coming from userspace via
sysfs, you won't even notice those checks.


> And the solution was that 
> before using the gpio_{set,get} one should always try to issue the
> "direction" calls to ensure that gpio controller is capable of that
> direction... 

The reason to use gpio_direction_{output,input}() calls is
mostly to turn the output drivers on/off.  Secondarily they
do report errors when that particular GPIO can't do that.

If you really want GPIO operations to be two instructions
with no subroutine calls, make sure your platform supports
inlining the gpio_get_value() calls that have constant params
that correspond to on-chip GPIOs.  (Can't be done over I2C...)

That *CAN* make a big difference in bitbang speed ... multiple
megabits per second with SPI, for example, vs less than one.

- Dave
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/