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:	Sat, 23 Feb 2008 02:56:28 +0300
From:	Anton Vorontsov <cbouatmailru@...il.com>
To:	David Brownell <david-b@...bell.net>
Cc:	Andrew Morton <akpm@...ux-foundation.org>,
	Florian Fainelli <florian.fainelli@...ecomint.eu>,
	linux-kernel@...r.kernel.org, hpa@...or.com, tglx@...utronix.de,
	Ingo Molnar <mingo@...e.hu>,
	Mauro Carvalho Chehab <mchehab@...radead.org>
Subject: Re: [PATCH 1/4 resend] [x86] Add generic GPIO support to x86

On Wed, Feb 13, 2008 at 05:55:30PM -0800, David Brownell wrote:
> On Wednesday 13 February 2008, Andrew Morton wrote:
> > It would be more modern to have a <linux/gpio.h> which takes care of
> > cruddy details, but it's getting too late for that.
> 
> Sort of like this?  For drivers that don't want to list themselves
> in Kconfig as depending on GENERIC_GPIO (e.g. one NAND driver I heard
> about), this lets them use <linux/gpio.h> ... existing code can't
> break, and it won't hurt if new code uses this.
> 
> - Dave
> 
> 
> ============== CUT HERE
> Add a <linux/gpio.h> defining fail/warn stubs for GPIO calls on
> platforms that don't support the GPIO programming interface.  It
> includes the arch-specific interface glue otherwise.
> 
> Signed-off-by: David Brownell <dbrownell@...rs.sourceforge.net>
> ---
>  include/linux/gpio.h |   93 +++++++++++++++++++++++++++++++++++++++++++++++++++
>  1 file changed, 93 insertions(+)
> 
> --- /dev/null	1970-01-01 00:00:00.000000000 +0000
> +++ g26/include/linux/gpio.h	2008-02-13 17:40:06.000000000 -0800
> @@ -0,0 +1,93 @@
> +#ifndef __LINUX_GPIO_H
> +#define __LINUX_GPIO_H
> +
> +#ifdef CONFIG_GENERIC_GPIO
> +#include <asm/gpio.h>
> +
> +#else
> +
> +/*
> + * Some platforms don't support the GPIO programming interface.
> + *
> + * In case some driver uses it anyway (it should normally have
> + * depended on GENERIC_GPIO), these routines help the compiler
> + * optimize out much GPIO-related code ... or trigger a runtime
> + * warning when something is wrongly called.
> + */
> +
> +static inline int gpio_is_valid(int number)
> +{
> +	return 0;
> +}
> +
> +static inline int gpio_request(unsigned gpio, const char *label)
> +{
> +	return -EINVAL;

Could we return -ENOSYS instead, so drivers will able to distinguish
between "something really failed" and "there is no gpio support,
fallback to other methods"? Without this, the notorious NAND driver
will hardly benefit from this change. ;-)

-- 
Anton Vorontsov
email: cbou@...l.ru
backup email: ya-cbou@...dex.ru
irc://irc.freenode.net/bd2
--
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