linux-kernel - Re: gpio patches in mmotm

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: <Pine.LNX.4.64.0804081227360.4987@axis700.grange>
Date:	Tue, 8 Apr 2008 12:44:46 +0200 (CEST)
From:	Guennadi Liakhovetski <g.liakhovetski@...gutronix.de>
To:	Uwe Kleine-König <Uwe.Kleine-Koenig@...i.com>
cc:	David Brownell <david-b@...bell.net>, linux-kernel@...r.kernel.org,
	Andrew Morton <akpm@...ux-foundation.org>
Subject: Re: gpio patches in mmotm

On Tue, 8 Apr 2008, Uwe Kleine-König wrote:

> arch/arm/mach-ns9xxx.  It's not (yet) fully supported in vanilla, but it
> includes support for different SOCs that have a different handling of
> their GPIOs.  E.g. the ns9360 has one gpio configuration register per 8
> gpios, the ns9215 has one per 4 gpios.  Or another thing: ns9215 has
> 108 gpios, ns9210 has only 54 where the first 50 gpios are identical to
> the first 50 of ns9215, and the last 4 gpios are identical to gpios
> 105-108 on ns9215.  So gpio_is_valid for ns9xxx has to look like:
> 
> 	int gpio_is_valid(int gpio)
> 	{
> 		...
> 		if (processor_is_ns9210())
> 			return gpio >= 0 && gpio < 108 && !(gpio >= 50 && gpio < 105);
> 		...
> 	}
> 
> (In my eyes that hole is ugly, but with it can calculate the address of
> the configuration register without case splitting and can handle ns9215
> and ns9210 identically---apart from the is-valid check.)

Ok, I thought it would be something like that. I think, these are two 
different things: GPIO valid and GPIO currently physically existing. 
gpio_is_valid() is a test whether the number being tested at all stands a 
chance to be a GPIO number on this architecture. As you see in 
include/asm-generic/gpio.h it only compares against ARCH_NR_GPIOS, which 
is just the theoretically highest GPIO number. It says nothing about 
whether or not all valid GPIOs are actually present on the system. Think 
about GPIO expanders, there might or might not be one currently available 
on the system. Still gpio_is_valid() will return the same result for any 
given number. PXA CPUs have the same "feature" as ns9xxx - different 
models have differeng GPIOs, and platform add their own GPIO controllers, 
which are often placed at a fixed start number, which means, on some CPUs 
there will be holes too. And gpio_is_valid is not (and should not be) 
checking for those - this is already the task for request_gpio().

> So you reason that the alternative approach allows only a slight
> simplification and so is not worth considering?  But obviously
> yes, I have a different opinion. :-)

No, my reason is that I didn't want to put "intimate knowledge" of GPIO 
interna, like "-1 is not a valid GPIO" in the driver but use an 
abstraction instead. My original proposal was to introduce just one 
NO_GPIO macro to test against, however, David nicely managed to persuade 
me, that the gpio_is_valid approach is better. Unfortunately, I cannot 
argument as nicely as he did, maybe looking through his emails in LKML 
archives will help you:-)

Thanks
Guennadi
---
Guennadi Liakhovetski
--
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/