linux-kernel - Re: [PATCH v2 0/4] gpiolib: some fixup patches

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Wed, 27 Feb 2013 07:52:04 +0000
From:	Grant Likely <grant.likely@...retlab.ca>
To:	Alexandre Courbot <gnurou@...il.com>
Cc:	Linus Walleij <linus.walleij@...aro.org>,
	Ryan Mallon <rmallon@...il.com>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	"acourbot@...dia.com" <acourbot@...dia.com>
Subject: Re: [PATCH v2 0/4] gpiolib: some fixup patches

On Wed, Feb 27, 2013 at 1:22 AM, Alexandre Courbot <gnurou@...il.com> wrote:
> On Wed, Feb 27, 2013 at 2:53 AM, Grant Likely <grant.likely@...retlab.ca> wrote:
>> On Fri, 22 Feb 2013 11:19:44 +0900, Alexandre Courbot <gnurou@...il.com> wrote:
>>> Grant, will you be able to include these for 3.9? They fix code that
>>> you merged recently, so I'd be glad if they could be squashed into the
>>> patch mentioned in the description.
>>
>> They won't get squashed in because the tree is already composed and in
>> linux-next. I don't rebase unless I really need to. I've applied them
>> and I'll probably push to Linus since they are effectively bug fixes of
>> a sort and the merge window hasn't closed yet.
>
> That's fine too - as long as the patches with side-effects are merged.
> That will allow me to continue going forward with GPIO, thanks!

While you're working on that, I'd like you to keep the following in
mind. I'm getting concerned with the level of overhead that the gpio
access routines are incuring. They're doing a lot of checks right now
when with GPIOs we want it to be as fast as possible for the case of
mmio gpios. (i2c and spi gpios are always going to be slow, so I'm not
so concerned here). gpio_get, gpio_set and gpio_direction all need to
be fast.

Basically, I think the model should be that if you've got a gpio_desc
pointer, then you've got a valid gpio. A lot of the checks that are
currently performed in the gpiod_ versions of functions can be moved
to the gpio_ versions where a lookup has to be performed anyway. For
example, right now gpiod_direction_output() is 61 lines long. Madness!
 :-)

I've been playing with an idea of pulling in some basic MMIO gpio
access directly into gpiolib so that when appropriate gpiolib itself
can have a fast path for doing the register access and shadow register
management.

g.
--
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/