linux-kernel - Re: [PATCH 0/4] gpio: introduce descriptor-based interface

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <50F3DC2B.6000603@nvidia.com>
Date:	Mon, 14 Jan 2013 19:21:31 +0900
From:	Alex Courbot <acourbot@...dia.com>
To:	Arnd Bergmann <arnd@...db.de>, Mike Frysinger <vapier@...too.org>,
	Geert Uytterhoeven <geert@...ux-m68k.org>
CC:	Grant Likely <grant.likely@...retlab.ca>,
	Linus Walleij <linus.walleij@...aro.org>,
	Guenter Roeck <linux@...ck-us.net>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	linux-arch <linux-arch@...r.kernel.org>,
	"linux-arm-kernel@...ts.infradead.org" 
	<linux-arm-kernel@...ts.infradead.org>,
	"devicetree-discuss@...ts.ozlabs.org" 
	<devicetree-discuss@...ts.ozlabs.org>, <gnurou@...il.com>,
	<linux-m68k@...ts.linux-m68k.org>,
	<uclinux-dist-devel@...ckfin.uclinux.org>
Subject: Re: [PATCH 0/4] gpio: introduce descriptor-based interface

On 01/10/2013 07:08 PM, Arnd Bergmann wrote:
> I've tried to find platforms that don't yet use GPIOLIB and fortunately
> there are very few left:
>
> I found two that provide the generic gpio interfaces when gpiolib
> is disabled, but use gpiolib otherwise for the same hardware,
> arch/m68k/include/asm/mcfgpio.h and arch/blackfin/include/asm/gpio.h.
> I would assume that we can simply remove the non-gpiolib shortcut
> here at cost of a small overhead.

I performed a search on my side too (checking configurations options 
which select GENERIC_GPIO but not ARCH_REQUIRE_GPIOLIB) and found the 
same list. This takes some time btw - many platforms use this combo to 
make GPIO support optional. Can I ask how you figured out these two archs?

I'd assume the overhead induced by forcibly compiling GPIOlib is 
neglectable, but let's make sure this is ok indeed - Mike, Geert, would 
you mind if selecting GENERIC_GPIO enforced GPIOlib to be compiled in, 
effectively making it mandatory to implement the generic GPIO interface 
using GPIOlib? Both your implementations support GPIOlib already, but 
can also work without it, and that would make that possibility obsolete.

> Then there are a bunch that use gpiolib but have a nontrivial
> implementation of gpio_get_value and other functions. I'm not sure
> if these are a problematic with your code.

AFAICT these all implement an inline path that bypasses GPIOlib when the 
GPIO number is known at compile time, for faster bitbanging I presume. 
It should be totally harmless to keep them. Unfortunately, I don't think 
it would be possible to have a similar trick using handlers.

Thanks,
Alex.
--
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/