lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-Id: <200810160956.12845.david-b@pacbell.net>
Date:	Thu, 16 Oct 2008 09:56:12 -0700
From:	David Brownell <david-b@...bell.net>
To:	avorontsov@...mvista.com
Cc:	Andrew Morton <akpm@...ux-foundation.org>,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH] gpiolib: fix oops on reading sysfs exported GPIOs

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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ