linux-kernel - [patch/rfc 0/4] GPIO implementation framework

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

Date:	Mon, 29 Oct 2007 18:50:12 -0700
From:	David Brownell <david-b@...bell.net>
To:	Linux Kernel list <linux-kernel@...r.kernel.org>
Cc:	Felipe Balbi <felipebalbi@...rs.sourceforge.net>,
	Bill Gatliff <bgat@...lgatliff.com>,
	Haavard Skinnemoen <hskinnemoen@...el.com>,
	Andrew Victor <andrew@...people.com>,
	Tony Lindgren <tony@...mide.com>,
	Jean Delvare <khali@...ux-fr.org>,
	"eric miao" <eric.y.miao@...il.com>,
	Kevin Hilman <khilman@...sta.com>,
	Paul Mundt <lethal@...ux-sh.org>,
	Ben Dooks <ben@...nity.fluff.org>
Subject: [patch/rfc 0/4] GPIO implementation framework

When we hashed out the Documentation/gpio.txt GPIO programming
interfaces last year, there were a few features in the "we want
this eventually, but can live without it for now" category.
Following this post are patches adding some of those features.

Two core patches are:

 - Implementation framework in lib/gpiolib.c ... the interface
   provided to GPIO _users_ is unchanged, but providers can now
   hook up through a "gpio_chip" that lets multiple types of
   GPIO provider coexist.  Examples:  SOC-native GPIOs, ones
   provided by an FPGA, I2C or SPI GPIO expanders, etc.

   (I'm thinking this is pretty much ready to merge into MM,
   unless someone turns up a blocking issue...)

 - I2C driver for common pcf8574/8575 GPIO expanders ... these
   are pretty common on embedded hardware, and it's routine for
   external trees to have ugly board-specific hacks exposing
   those GPIOs to drivers.  Unlike such hacks, I think support
   using standard GPIO calls should be mergable upstream.

   (IMO this is ready to merge too, although I know Jean would
   like additional infrastructure which could let us obsolete
   existing drivers, instead of just offering an alternative for
   systems that need kernel access instead of userspace access.)

Two more patches show how they can be used:

 - Platform conversion for DaVinci ... making the SOC-native
   GPIOs plug in through gpiolib instead of directly, except
   when callers can leverage the inline optimization.

 - Board conversion (partial) for DaVinci EVM ... exposing
   the LEDs hooked up to one pcf8574a chip using leds-gpio,
   along with the A/V clocks (and a random user switch) on
   another pcf chip.  A third pcf chip isn't converted; it'd
   mean changing half a dozen drivers, none of which are yet
   upstream.

If the gpiolib patch merges into MM, then I think it'd be
realistic to expect some platforms and boards to be using
this new infrastructure in 2.6.25 ...

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