History log of /drivers/of/gpio.c
Revision Date Author Comments (<<< Hide modified files) (Show modified files >>>)
6270d830d030da48eddffbe31ed1e4444f203fc5 04-Apr-2012 Roland Stigge <stigge@antcom.de> gpio: Fix range check in of_gpio_simple_xlate()

of_gpio_simple_xlate() has an off-by-one bug where it checks to see if
args[0] is > ngpio instead of >=. args[0] must always be less than
ngpio because it is a zero-based enumeration.

Signed-off-by: Roland Stigge <stigge@antcom.de>
[grant.likely: beef up commit text]
Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
/drivers/of/gpio.c
6e2cf6514066cdd5a0844b34760029a5a4870318 02-Mar-2012 Grant Likely <grant.likely@secretlab.ca> gpio: constify the data parameter to gpiochip_find()

Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
/drivers/of/gpio.c
ff64abefb6680dfc2aca7ecaa5e695949e7335c9 02-Feb-2012 Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com> of_gpio: add support of of_gpio_named_count to be able to count named gpio

Signed-off-by: Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>
Cc: devicetree-discuss@lists.ozlabs.org
Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
/drivers/of/gpio.c
15c9a0acc3f7873db4b7d35d016729b2dc229b49 12-Dec-2011 Grant Likely <grant.likely@secretlab.ca> of: create of_phandle_args to simplify return of phandle parsing data

of_parse_phandle_with_args() needs to return quite a bit of data. Rather
than making each datum a separate **out_ argument, this patch creates
struct of_phandle_args to contain all the returned data and reworks the
user of the function. This patch also enables of_parse_phandle_with_args()
to return the device node pointer for the phandle node.

This patch also ends up being fairly major surgery to
of_parse_handle_with_args(). The existing structure didn't work well
when extending to use of_phandle_args, and I discovered bugs during testing.
I also took the opportunity to rename the function to be like the
existing of_parse_phandle().

v2: - moved declaration of of_phandle_args to fix compile on non-DT builds
- fixed incorrect index in example usage
- fixed incorrect return code handling for empty entries

Reviewed-by: Shawn Guo <shawn.guo@freescale.com>
Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
/drivers/of/gpio.c
64842aad5ec5ea3b6f6e716ce53a863f7c409da8 06-Nov-2011 Grant Likely <grant.likely@secretlab.ca> gpiolib: output basic details and consolidate gpio device drivers

This patch adds a kernel message, containing GPIO range and device
name on successful device registration, and removes duplicate messages from the following drivers:
* gpio-adp5588
* gpio-bt8xx
* gpio-cs5535
* gpio-janz-ttl
* gpio-nomadik
* gpio-pcf857x
* gpio-xilinx
* drivers/of/gpio.c

Signed-off-by: Hartmut Knaack <knaack.h@gmx.de>
[grant.likely@secretlab.ca: squashed 2 patches together]
Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
/drivers/of/gpio.c
3038bbdf7404ae3948385cbde30df946579d4e3a 28-Jul-2011 Jamie Iles <jamie@jamieiles.com> of/gpio: export of_gpio_simple_xlate

Allow GPIO drivers to use of_gpio_simple_xlate. This is useful for the
generic GPIO driver for example where gpio_chip is embedded in
bgpio_chip and doesn't need of_mm_gpio_chip but has a simple 1:1 GPIO
mapping.

Cc: Anton Vorontsov <avorontsov@ru.mvista.com>
Cc: Grant Likely <grant.likely@secretlab.ca>
Signed-off-by: Jamie Iles <jamie@jamieiles.com>
Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
/drivers/of/gpio.c
a6b0919140b49e0871584362ae0cf1d18c476058 28-Jun-2011 John Bonesio <bones@secretlab.ca> of/gpio: Add new method for getting gpios under different property names

This patch adds a new routine, of_get_named_gpio_flags(), which takes the
property name as a parameter rather than assuming "gpios".

of_get_gpio_flags() is modified to call of_get_named_gpio_flags() with "gpios"
as the property parameter.

Signed-off-by: John Bonesio <bones@secretlab.ca>
[grant.likely: Tidied up whitespace and tweaked kerneldoc comments.]
Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
/drivers/of/gpio.c
2e13cba8dc35774bf1d7169733e876c5b7adee54 06-Jul-2010 Grant Likely <grant.likely@secretlab.ca> of/gpio: fix of_gpio includes

drivers/of/gpio.c is missing includes for of_irq and struct device which
cause build failures on ARM. This patch adds the correct include files
and removes the unneeded kernel.h include

Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
/drivers/of/gpio.c
391c970c0dd1100e3b9e1681f7d0f20aac35455a 08-Jun-2010 Anton Vorontsov <avorontsov@ru.mvista.com> of/gpio: add default of_xlate function if device has a node pointer

Implement generic OF gpio hooks and thus make device-enabled GPIO chips
(i.e. the ones that have gpio_chip->dev specified) automatically attach
to the OpenFirmware subsystem. Which means that now we can handle I2C and
SPI GPIO chips almost* transparently.

* "Almost" because some chips still require platform data, and for these
chips OF-glue is still needed, though with this change the glue will
be much smaller.

Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
Cc: David Brownell <dbrownell@users.sourceforge.net>
Cc: Bill Gatliff <bgat@billgatliff.com>
Cc: Dmitry Eremin-Solenikov <dbaryshkov@gmail.com>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Jean Delvare <khali@linux-fr.org>
Cc: Andrew Morton <akpm@linux-foundation.org>
CC: linux-kernel@vger.kernel.org
CC: devicetree-discuss@lists.ozlabs.org
/drivers/of/gpio.c
594fa265e084073443390c5b93d5410fd28e9bcd 08-Jun-2010 Grant Likely <grant.likely@secretlab.ca> of/gpio: stop using device_node data pointer to find gpio_chip

Currently the kernel uses the struct device_node.data pointer to resolve
a struct gpio_chip pointer from a device tree node. However, the .data
member doesn't provide any type checking and there aren't any rules
enforced on what it should be used for. There's no guarantee that the
data stored in it actually points to an gpio_chip pointer.

Instead of relying on the .data pointer, this patch modifies the code
to add a lookup function which scans through the registered gpio_chips
and returns the gpio_chip that has a pointer to the specified
device_node.

Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
CC: Andrew Morton <akpm@linux-foundation.org>
CC: Anton Vorontsov <avorontsov@ru.mvista.com>
CC: Grant Likely <grant.likely@secretlab.ca>
CC: David Brownell <dbrownell@users.sourceforge.net>
CC: Bill Gatliff <bgat@billgatliff.com>
CC: Dmitry Eremin-Solenikov <dbaryshkov@gmail.com>
CC: Benjamin Herrenschmidt <benh@kernel.crashing.org>
CC: Jean Delvare <khali@linux-fr.org>
CC: linux-kernel@vger.kernel.org
CC: devicetree-discuss@lists.ozlabs.org
/drivers/of/gpio.c
a19e3da5bc5fc6c10ab73f310bea80f3845b4531 08-Jun-2010 Anton Vorontsov <avorontsov@ru.mvista.com> of/gpio: Kill of_gpio_chip and add members directly to gpio_chip

The OF gpio infrastructure is great for describing GPIO connections within
the device tree. However, using a GPIO binding still requires changes to
the gpio controller just to add an of_gpio structure. In most cases, the
gpio controller doesn't actually need any special support and the simple
OF gpio mapping function is more than sufficient. Additional, the current
scheme of using of_gpio_chip requires a convoluted scheme to maintain
1:1 mappings between of_gpio_chip and gpio_chip instances.

If the struct of_gpio_chip data members were moved into struct gpio_chip,
then it would simplify the processing of OF gpio bindings, and it would
make it trivial to use device tree OF connections on existing gpiolib
controller drivers.

This patch eliminates the of_gpio_chip structure and moves the relevant
fields into struct gpio_chip (conditional on CONFIG_OF_GPIO). This move
simplifies the existing code and prepares for adding automatic device tree
support to existing drivers.

Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Anton Vorontsov <avorontsov@ru.mvista.com>
Cc: Grant Likely <grant.likely@secretlab.ca>
Cc: David Brownell <dbrownell@users.sourceforge.net>
Cc: Bill Gatliff <bgat@billgatliff.com>
Cc: Dmitry Eremin-Solenikov <dbaryshkov@gmail.com>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Jean Delvare <khali@linux-fr.org>
/drivers/of/gpio.c
5a0e3ad6af8660be21ca98a971cd00f331318c05 24-Mar-2010 Tejun Heo <tj@kernel.org> include cleanup: Update gfp.h and slab.h includes to prepare for breaking implicit slab.h inclusion from percpu.h

percpu.h is included by sched.h and module.h and thus ends up being
included when building most .c files. percpu.h includes slab.h which
in turn includes gfp.h making everything defined by the two files
universally available and complicating inclusion dependencies.

percpu.h -> slab.h dependency is about to be removed. Prepare for
this change by updating users of gfp and slab facilities include those
headers directly instead of assuming availability. As this conversion
needs to touch large number of source files, the following script is
used as the basis of conversion.

http://userweb.kernel.org/~tj/misc/slabh-sweep.py

The script does the followings.

* Scan files for gfp and slab usages and update includes such that
only the necessary includes are there. ie. if only gfp is used,
gfp.h, if slab is used, slab.h.

* When the script inserts a new include, it looks at the include
blocks and try to put the new include such that its order conforms
to its surrounding. It's put in the include block which contains
core kernel includes, in the same order that the rest are ordered -
alphabetical, Christmas tree, rev-Xmas-tree or at the end if there
doesn't seem to be any matching order.

* If the script can't find a place to put a new include (mostly
because the file doesn't have fitting include block), it prints out
an error message indicating which .h file needs to be added to the
file.

The conversion was done in the following steps.

1. The initial automatic conversion of all .c files updated slightly
over 4000 files, deleting around 700 includes and adding ~480 gfp.h
and ~3000 slab.h inclusions. The script emitted errors for ~400
files.

2. Each error was manually checked. Some didn't need the inclusion,
some needed manual addition while adding it to implementation .h or
embedding .c file was more appropriate for others. This step added
inclusions to around 150 files.

3. The script was run again and the output was compared to the edits
from #2 to make sure no file was left behind.

4. Several build tests were done and a couple of problems were fixed.
e.g. lib/decompress_*.c used malloc/free() wrappers around slab
APIs requiring slab.h to be added manually.

5. The script was run on all .h files but without automatically
editing them as sprinkling gfp.h and slab.h inclusions around .h
files could easily lead to inclusion dependency hell. Most gfp.h
inclusion directives were ignored as stuff from gfp.h was usually
wildly available and often used in preprocessor macros. Each
slab.h inclusion directive was examined and added manually as
necessary.

6. percpu.h was updated not to include slab.h.

7. Build test were done on the following configurations and failures
were fixed. CONFIG_GCOV_KERNEL was turned off for all tests (as my
distributed build env didn't work with gcov compiles) and a few
more options had to be turned off depending on archs to make things
build (like ipr on powerpc/64 which failed due to missing writeq).

* x86 and x86_64 UP and SMP allmodconfig and a custom test config.
* powerpc and powerpc64 SMP allmodconfig
* sparc and sparc64 SMP allmodconfig
* ia64 SMP allmodconfig
* s390 SMP allmodconfig
* alpha SMP allmodconfig
* um on x86_64 SMP allmodconfig

8. percpu.h modifications were reverted so that it could be applied as
a separate patch and serve as bisection point.

Given the fact that I had only a couple of failures from tests on step
6, I'm fairly confident about the coverage of this conversion patch.
If there is a breakage, it's likely to be something in one of the arch
headers which should be easily discoverable easily on most builds of
the specific arch.

Signed-off-by: Tejun Heo <tj@kernel.org>
Guess-its-ok-by: Christoph Lameter <cl@linux-foundation.org>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: Lee Schermerhorn <Lee.Schermerhorn@hp.com>
/drivers/of/gpio.c
337148812f97368a8ec4a69f1691e4c5ce3af494 30-Jan-2010 Jeremy Kerr <jeremy.kerr@canonical.com> of: assume big-endian properties, adding conversions where necessary

Properties in the device tree are specified as big-endian. At present,
the only platforms to support device trees are also big-endian, so we've
been acessing the properties as raw values.

We'd like to add device tree support to little-endian platforms too, so
add endian conversion to the sites where we access property values in
the common of code.

Compiled on powerpc (ppc44x_defconfig & ppc64_defconfig) and arm (fdt
support only for now).

Signed-off-by: Jeremy Kerr <jeremy.kerr@canonical.com>
Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
/drivers/of/gpio.c
749820928a2fd47ff536773d869d2c3f8038b7d1 05-Dec-2008 Anton Vorontsov <avorontsov@ru.mvista.com> of/gpio: Implement of_gpio_count()

This function is used to count how many GPIOs are specified for
a device node.

Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
Signed-off-by: Paul Mackerras <paulus@samba.org>
/drivers/of/gpio.c
b908b53d580c3e9aba81ebe3339c5b7b4fa8031d 01-Dec-2008 Anton Vorontsov <avorontsov@ru.mvista.com> of/gpio: Implement of_get_gpio_flags()

This adds a new function, of_get_gpio_flags, which is like
of_get_gpio(), but accepts a new "flags" argument. This new function
will be used by the drivers that need to retrieve additional GPIO
information, such as active-low flag.

Also, this changes the default ("simple") .xlate routine to warn about
bogus (< 2) #gpio-cells usage: the second cell should always be present
for GPIO flags.

Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
Signed-off-by: Paul Mackerras <paulus@samba.org>
/drivers/of/gpio.c
64b60e096fa391c56f93e6216115e6757bf86b7e 10-Oct-2008 Anton Vorontsov <avorontsov@ru.mvista.com> of: Add new helper of_parse_phandles_with_args()

The helper is factored out of of_get_gpio(). Will be used by the QE
pin multiplexing functions (they need to parse the gpios = <> too).

Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
/drivers/of/gpio.c
21451155d8858773ee764e9218de2ca0f4d6fc38 29-Apr-2008 Anton Vorontsov <avorontsov@ru.mvista.com> [POWERPC] of/gpio: Use dynamic base allocation

Since the "gpiolib: dynamic gpio number allocation" patch was recently
merged into Linus' tree (commit 8d0aab2f16c4fa170f32e7a74a52cd0122bbafef),
we can use dynamic GPIO base allocation now.

This, in turn, removes number of gpios per chip constraint.

Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
Signed-off-by: Paul Mackerras <paulus@samba.org>
/drivers/of/gpio.c
863fbf4966a7ac301a4077e4a04d73e8abfdd7b2 11-Apr-2008 Anton Vorontsov <avorontsov@ru.mvista.com> [POWERPC] OF helpers for the GPIO API

This implements various helpers to support OF bindings for the GPIO
LIB API.

Previously this was PowerPC specific, but it seems this code isn't
arch-dependent anyhow, so let's place it into of/.

SPARC will not see this addition yet, real hardware seem to not use
GPIOs at all. But this might change:

http://www.leox.org/docs/faq_MLleon.html

"16-bit I/O port" sounds promising. :-)

Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
Acked-by: Grant Likely <grant.likely@secretlab.ca>
Signed-off-by: Paul Mackerras <paulus@samba.org>
/drivers/of/gpio.c