linux-kernel - OpenFirmware GPIO LED driver

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

Date:	Fri, 24 Oct 2008 16:04:57 -0700 (PDT)
From:	Trent Piepho <tpiepho@...escale.com>
To:	linux-kernel@...r.kernel.org
cc:	linuxppc-dev@...abs.org,
	Anton Vorontsov <avorontsov@...mvista.com>,
	Richard Purdie <rpurdie@...ys.net>,
	Sean MacLennan <smaclennan@...atech.com>,
	Wolfram Sang <w.sang@...gutronix.de>,
	Grant Likely <grant.likely@...retlab.ca>
Subject: OpenFirmware GPIO LED driver

This series of patches adds support for OpenFirmware bindings for GPIO based
LEDs.

I last posted a version of this in July but discussion of the OF binding
details didn't seem to be going anywhere.

I've since been contacted by some people who are actually using the previous
patches and have been motivated to try again.

All the users of this code are satisfied with the current version and it does
everything they need it to do.

The first patch extends the of_get_gpio() function to provide the gpio flags.

The way this already works (i.e., this is not something I'm adding, it's
what's already there) is that the OF gpio specifier is an opaque sequence of
words.  The GPIO controller driver (of which only one currently exists)
provides an ->xlate() method that turns this into a Linux gpiolib gpio number. 
All current gpio controllers have flags in their gpio specifier, but there is
no way to get them.  So I extend the xlate method to also produce the flags in
a Linux format, the same way it produces a Linux gpio number.

The second patch adds OF bindings to the gpio-leds driver.  The existing code
is refactored so that almost all of the common code is shared between the two
binding methods.  Either or both bindings can be selected via Kconfig.  The
bindings do have one "linux," property, but no one has been able to come up
with something close to workable that avoids this and still satisfies the
*requirement* that the default trigger be settable from the OF bindings.

The second and third patches add some additional capabilities for gpio leds
that some users need.

One is to have a LED start in the on state when it's made known to Linux. 
There is already a "default-on" trigger that does this, but it produces a
glitch where an LED that is already on will turn off then back on.  My (tiny)
patch avoids this problem.

The next lets an LED stay, without glitches, in whatever state it was already
in when it's made known to Linux.  It may have been put into this state by the
BIOS, firmware, bootloader, or the hardware itself.
--
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/