Commit Graph

97 Commits

Author SHA1 Message Date
Alexandre Courbot 0204df470d gpiolib: let gpiod_request() return -EPROBE_DEFER
Patch be1a4b brought some improvements to the GPIO error handling code,
but also changed the return value of gpiod_request() when called on a
not yet initialized GPIO descriptor: it now returns -EINVAL instead of
-EPROBE_DEFER, and this affects some drivers.

This patch restores the original behavior for gpiod_request(). It is
safe to do so now that desc_to_gpio() does not rely on the GPIO
descriptor to be initialized. Other functions changed by patch be1a4b
do not see their return value affected, so these are not reverted.

Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
Reported-by: Dr. H. Nikolaus Schaller <hns@goldelico.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2013-10-11 16:31:54 +02:00
Alexandre Courbot 8c0fca8153 gpiolib: safer implementation of desc_to_gpio()
The current implementation of desc_to_gpio() relies on the chip pointer
to be set to a valid value in order to compute the GPIO number. This
was done in the hope that we can get rid of the gpio_desc global array,
but this is not happening anytime soon.

This patch reimplements desc_to_gpio() in a fashion similar to that of
gpio_to_desc(). As a result, desc_to_gpio(gpio_to_desc(gpio)) == gpio is
now always true. This allows to call desc_to_gpio() on non-initialized
descriptors as some error-handling code currently does.

Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
Reported-by: Dr. H. Nikolaus Schaller <hns@goldelico.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2013-10-11 16:31:53 +02:00
Linus Walleij 65d876564e gpio: return -ENOTSUPP if debounce cannot be set
It appears some drivers are using gpio_set_debounce()
opportunistically, i.e. without knowing whether it works or
not. (Example: input/keyboard/gpio_keys.c) to account for
this use case, return -ENOTSUPP and do not print any
warnings in this case.

Took a round over the other gpio_set_debounce() consumers
to make sure that none of them are relying on the returned
error code to be something specific.

Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2013-09-04 14:22:47 +02:00
Linus Walleij be1a4b1308 gpio: improve error path in gpiolib
At several places the gpiolib will proceed to handle a GPIO
descriptor even if it's ->chip member is NULL and no gpiochip
is associated.

Fix this by checking that both the descriptor cookie *and*
the chip pointer are valid.

Also bail out earlier with more specific diagnostic messages
on missing operations for setting as input/output or debounce.

ChangeLog v1->v2:
- Also return -EIO on gpiod_set_debounce() with missing
  operations in the vtable
- Fix indentations.

Suggested-by: Alexandre Courbot <acourbot@nvidia.com>
Acked-by: Alexandre Courbot <acourbot@nvidia.com>
Reviewed-by: Frank Rowand <frank.rowand@sonymobile.com>
Cc: Tim Bird <tim.bird@sonymobile.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2013-09-03 14:08:28 +02:00
Jingoo Han a3d88c92a1 gpiolib: replace strict_strtol() with kstrtol()
The usage of strict_strtol() is not preferred, because
strict_strtol() is obsolete. Thus, kstrtol() should be
used.

Signed-off-by: Jingoo Han <jg1.han@samsung.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2013-07-21 00:20:34 +02:00
Zhangfei Gao 3bae4811fb gpiolib: remove warnning of allocations with IRQs disabled
Move of_gpiochip_add outof spin_lock, since kzalloc inside
of_gpiochip_add -> of_gpiochip_add_pin_range -> gpiochip_add_pin_range -> kzalloc

WARNING: at kernel/lockdep.c:2740 lockdep_trace_alloc+0xf8/0xfc()
DEBUG_LOCKS_WARN_ON(irqs_disabled_flags(flags))

Signed-off-by: Zhangfei Gao <zhangfei.gao@linaro.org>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2013-06-20 10:37:41 +02:00
Alexandre Courbot 24d7628fe8 gpiolib: move comment to right function
This comment applies to gpio_to_chip(), not gpiod_to_chip().

Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
2013-03-02 13:20:20 +00:00
Alexandre Courbot def634338d gpiolib: use const parameters when possible
Constify descriptor parameter of gpiod_* functions for those that
should obviously not modify it. This includes value or direction get,
cansleep, and IRQ number query.

Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
2013-03-02 13:20:19 +00:00
Alexandre Courbot bcabdef12d gpiolib: check descriptors validity before use
Some functions dereferenced their GPIO descriptor argument without
checking its validity first, potentially leading to an oops when given
an invalid argument.

This patch also makes gpio_get_value() more resilient when given an
invalid GPIO, returning 0 instead of silently crashing.

Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
Cc: Ryan Mallon <rmallon@gmail.com>
Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
2013-03-02 13:20:19 +00:00
Tejun Heo 62f516b8d6 gpio: convert to idr_alloc()
Convert to the much saner new idr interface.

Signed-off-by: Tejun Heo <tj@kernel.org>
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Cc: Grant Likely <grant.likely@secretlab.ca>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2013-02-27 19:10:15 -08:00
Linus Torvalds 4c8c225abf GPIO changes for Linux 3.9
This branch contains the usual set of individual driver improvements and
 bug fixes, as well as updates to the core code. The more notable changes
 include:
 
 - Internally add new API for referencing GPIOs by gpio_desc instead of
   number. Eventually this will become a public API
 - ACPI GPIO binding support
 -----BEGIN PGP SIGNATURE-----
 Version: GnuPG v1.4.11 (GNU/Linux)
 
 iQIcBAABAgAGBQJRK77kAAoJEEFnBt12D9kBwZ0P/iJ++tvmUg9mt9qzN0Le0Q02
 TKCQpgOivxng03oTcLIQRK46PNPWdq2zDb1v5seqXKxdMjRd++WLxPxj4eRZNdqA
 J0K820KvqYSLAqEUDwqO288ciOyP6ThDfeT+SUUUCOwFHkFCVS0xYuxLjcX0evah
 pcXuIu6nev2Yo/RivgXVaVkOTVBf7ssR7rTpdkDl/RvK2BMZTfpmt4fAXdDcCb9k
 JlBeSC6Ifx6iUcl+lV+jA0PeA7vOEHBhXWqoy5ivtNPcBbPL//cz0ZdAL0jfVtgn
 17RPugskNv/s2uVJlhiyKA3kF2IzbE3pKGxyl2Teb4Xus398pqqaHPtiLNeKIiSV
 KUJRIu2mGdvb4Vyvno0e5Vll9PcUPX0uIeQ2uzrMAB7XtI4EHw7d9+qwj4qOI6Dg
 edCFNcI9zTeuU/Z3fAg/+ufdIY7muQz8OsKnh3R8fY29SVSa+6o6TT+tgX5M7tjH
 IEI11RaYQQEJSri9bAR0vE1nsFleWsoW6QljVIHLpNS/tBz/S8KYpbQ5qPNXknxf
 lgD0FzkNYPWWi9D3wNutwNeaktCacRfcCTH1Z4FzE+PmxoYeiCzf/4pjFbxU06dm
 WJ7i8E0SRrVW+cM8z7M+Lj6emqtQ5En0bg5ZTo75SM2X+9sNrWtw3UMQ7Ea4gxKM
 362n9tWp2k626DixWzBd
 =JN4M
 -----END PGP SIGNATURE-----

Merge tag 'gpio-for-linus' of git://git.secretlab.ca/git/linux

Pull GPIO changes from Grant Likely:
 "This branch contains the usual set of individual driver improvements
  and bug fixes, as well as updates to the core code.  The more notable
  changes include:

   - Internally add new API for referencing GPIOs by gpio_desc instead
     of number.  Eventually this will become a public API

   - ACPI GPIO binding support"

* tag 'gpio-for-linus' of git://git.secretlab.ca/git/linux: (33 commits)
  arm64: select ARCH_WANT_OPTIONAL_GPIOLIB
  gpio: em: Use irq_domain_add_simple() to fix runtime error
  gpio: using common order: let 'static const' instead of 'const static'
  gpio/vt8500: memory cleanup missing
  gpiolib: Fix locking on gpio debugfs files
  gpiolib: let gpio_chip reference its descriptors
  gpiolib: use descriptors internally
  gpiolib: use gpio_chips list in gpiochip_find_base
  gpiolib: use gpio_chips list in sysfs ops
  gpiolib: use gpio_chips list in gpiochip_find
  gpiolib: use gpio_chips list in gpiolib_sysfs_init
  gpiolib: link all gpio_chips using a list
  gpio/langwell: cleanup driver
  gpio/langwell: Add Cloverview ids to pci device table
  gpio/lynxpoint: add chipset gpio driver.
  gpiolib: add missing braces in gpio_direction_show
  gpiolib-acpi: Fix error checks in interrupt requesting
  gpio: mpc8xxx: don't set IRQ_TYPE_NONE when creating irq mapping
  gpiolib: remove gpiochip_reserve()
  arm: pxa: tosa: do not use gpiochip_reserve()
  ...
2013-02-26 09:35:29 -08:00
Grant Likely 362432aed5 gpiolib: Fix locking on gpio debugfs files
The debugfs files really need to hold the gpiolib spinlock before
accessing the list. Otherwise chip addition/removal will cause an oops.

Cc: Alexandre Courbot <acourbot@nvidia.com>
Cc: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
2013-02-11 22:21:28 +00:00
Alexandre Courbot 6c0b4e6c85 gpiolib: let gpio_chip reference its descriptors
Add a pointer to the gpio_chip structure that references the array of
GPIO descriptors belonging to the chip, and update gpiolib code to use
this pointer instead of the global gpio_desc[] array. This is another
step towards the removal of the gpio_desc[] global array.

Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
Reviewed-by: Linus Walleij <linus.walleij@linaro.orh>
Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
2013-02-11 22:21:28 +00:00
Alexandre Courbot 372e722ea4 gpiolib: use descriptors internally
Make sure gpiolib works internally with descriptors and (chip, offset)
pairs instead of using the global integer namespace. This prepares the
ground for the removal of the global gpio_desc[] array and the
introduction of the descriptor-based GPIO API.

Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
[grant.likely: Squash in fix for link error when CONFIG_SYSFS=n]
Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
2013-02-11 22:20:55 +00:00
Alexandre Courbot 83cabe33eb gpiolib: use gpio_chips list in gpiochip_find_base
Re-implement gpiochip_find_base using the list of chips instead of the
global gpio_desc[] array. This makes it both simpler and more efficient,
and is needed to remove the global descriptors array.

The new code should preserve the exact same GPIO number assignment
policy as the code it is replacing. There shouldn't be any visible
change to the assigned GPIO numbers.

Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
[grant.likely: Added comment about assignment policy]
Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
2013-02-09 10:07:10 +00:00
Alexandre Courbot cb1650d4e0 gpiolib: use gpio_chips list in sysfs ops
This makes the code both simpler and faster compared to parsing the GPIO
number space.

Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
2013-02-09 09:30:17 +00:00
Alexandre Courbot 125eef96f6 gpiolib: use gpio_chips list in gpiochip_find
Using the GPIO chips list is much faster than parsing the entire GPIO
number space.

Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
2013-02-09 09:23:30 +00:00
Alexandre Courbot 65493e3ac4 gpiolib: use gpio_chips list in gpiolib_sysfs_init
Use the small list of GPIO chips instead of parsing the whole GPIO
number space.

Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
2013-02-09 09:22:21 +00:00
Alexandre Courbot 1a989d0f1d gpiolib: link all gpio_chips using a list
Add a list member to gpio_chip that allows all chips to be parsed
quickly. The current method requires parsing the entire GPIO integer
space, which is painfully slow. Using a list makes many chip operations
that involve lookup or parsing faster, and also simplifies the code. It
is also necessary to eventually get rid of the global gpio_desc[] array.

The list of gpio_chips is always ordered by base GPIO number to ensure
chips traversal is done in the right order.

Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
2013-02-09 09:20:12 +00:00
Michał Mirosław 9f3b795a62 driver-core: constify data for class_find_device()
All in-kernel users of class_find_device() don't really need mutable
data for match callback.

In two places (kernel/power/suspend_test.c, drivers/scsi/osd/osd_uld.c)
this patch changes match callbacks to use const search data.

The const is propagated to rtc_class_open() and power_supply_get_by_name()
parameters.

Note that there's a dev reference leak in suspend_test.c that's not
touched in this patch.

Signed-off-by: Michał Mirosław <mirq-linux@rere.qmqm.pl>
Acked-by: Grant Likely <grant.likely@secretlab.ca>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-02-06 12:18:56 -08:00
Alexandre Courbot 476171ce78 gpiolib: add missing braces in gpio_direction_show
Add missing braces in an if..else condition.

Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2013-02-04 21:46:56 +01:00
Alexandre Courbot 710b40eac4 gpiolib: remove gpiochip_reserve()
gpiochip_reserve() has no user and stands in the way of the removal of
the static gpio_desc[] array. Remove this function as well as the now
unneeded RESERVED flag of struct gpio_desc.

Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2013-02-04 21:41:46 +01:00
Linus Torvalds b0885d01f9 GPIO follow up patch and type change for v3.5 merge window
Primarily device driver additions, features and bug fixes. Not much
 touching gpio common subsystem support. Should not be scary.
 -----BEGIN PGP SIGNATURE-----
 Version: GnuPG v1.4.11 (GNU/Linux)
 
 iQIcBAABAgAGBQJQx2nHAAoJEEFnBt12D9kBKnIP/0y/0LMUUMVp1LN/UeCyPdq+
 rqWdI57a+ToAiGcdSG2INR5fjC8duPP1UOSgQXQFsAdF1qy7vN7ejPqmoAGcVoRW
 P9O64s8eYQprabx3fSiqAOhav6ZUpxyfri9z/sz8JaTlpJrbiqf1MrxFQ/0oXZa9
 KqOFAJvKn+iqWjcpFkmeIvNsFT2lTeURyXhvYWUFig/VVuS335+FZYX0Ic1C69YM
 tf0Z+a6XO8JnAKgC13GsyJ6ctXA1kg1oKLnLHEekr3Qhkic3MTFKS2dPExzGjnbi
 NY4ev2SxAq74CFwSJDuhPiPk20FpveHKHLsptFdNpCR9lMG038oRnqAnYyw3gV/w
 z4GufpIZGK/xemIgHqNHejxS+tcH4Ax1wU++TkmIvsPJDq7uZPX/Gu9/+BMpeKxJ
 oJJV+mRCKDcjxXcxtrybF9+t8WdVZfW2qSt1K7LRO3eRV2n9Y+20R6iGKXhYxHaj
 TaQTtXIbc4q5ANg72O+c8htBhy0a2H1O5CtrXwwxBBHHsRachyHT6V9AD+7AKZ6e
 YElRV+v8dOviuUcj+nbf2riA7KnwtBLYfwdVQzTfbD1Fq8RUvMEjq2XQXYKhrMSw
 r8gp1sUnFmAVOikJFqVgYN8NyToVEyw1i2LH8skzCUnE0PPi+kT8CtaY+tTMuF3v
 mBixcMEKKhzsFtYmAqU+
 =2XeO
 -----END PGP SIGNATURE-----

Merge tag 'gpio-for-linus' of git://git.secretlab.ca/git/linux-2.6

Pull GPIO updates from Grant Likely:
 "GPIO follow up patch and type change for v3.5 merge window

  Primarily device driver additions, features and bug fixes.  Not much
  touching gpio common subsystem support.  Should not be scary."

* tag 'gpio-for-linus' of git://git.secretlab.ca/git/linux-2.6: (34 commits)
  gpio: Provide the STMPE GPIO driver with its own IRQ Domain
  gpio: add TS-5500 DIO blocks support
  gpio: pcf857x: use client->irq for gpio_to_irq()
  gpio: stmpe: Add DT support for stmpe gpio
  gpio: pl061 depends on ARM
  gpio/pl061: remove old comment
  gpio: SPEAr: add spi chipselect control driver
  gpio: gpio-max710x: Support device tree probing
  gpio: twl4030: Use only TWL4030_MODULE_LED for LED configuration
  gpio: tegra: read output value when gpio is set in direction_out
  gpio: pca953x: Add compatible strings to gpio-pca953x driver
  gpio: pca953x: Register an IRQ domain
  gpio: mvebu: Set free callback for gpio_chip
  gpio: tegra: Drop exporting static functions
  gpio: tegra: Staticize non-exported symbols
  gpio: tegra: fix suspend/resume apis
  gpio-pch: Set parent dev for gpio chip
  gpio: em: Fix build errors
  GPIO: clps711x: use platform_device_unregister in gpio_clps711x_init()
  gpio/tc3589x: convert to use the simple irqdomain
  ...
2012-12-11 13:00:56 -08:00
Axel Lin b4d4b1f087 gpiolib: Fix use after free in gpiochip_add_pin_range
This is introduced by commit 9ab6e988
"gpiolib: return any error code from range creation".

Signed-off-by: Axel Lin <axel.lin@ingics.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2012-11-21 10:08:05 +01:00
Linus Walleij 316511c013 gpiolib: rename pin range arguments
To be crystal clear on what the arguments mean in this
funtion dealing with both GPIO and PIN ranges with confusing
naming, we now have gpio_offset and pin_offset and we are
on the clear that these are offsets into the specific GPIO
and pin controller respectively. The GPIO chip itself will
of course keep track of the base offset into the global
GPIO number space.

Reviewed-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2012-11-21 10:07:48 +01:00
Linus Walleij 8f23ca1a73 gpiolib: return any error code from range creation
If we try to create a range for a certain GPIO chip and the
target pin controller is not yet available it may return
a probe deferral error code, so handle this all the way
our by checking the error code.

Reviewed-by: Stephen Warren <swarren@nvidia.com>
Reviewed-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2012-11-21 08:55:11 +01:00
Linus Walleij 192c369c61 gpiolib: rename find_pinctrl_*
Rename the function find_pinctrl_and_add_gpio_range()
to pinctrl_find_and_add_gpio_range() so as to be consistent
with the rest of the functions.

Reviewed-by: Stephen Warren <swarren@nvidia.com>
Reviewed-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2012-11-21 08:55:10 +01:00
Linus Walleij 3f0f867060 gpiolib: let gpiochip_add_pin_range() specify offset
Like with commit 3c739ad0df
it is not always enough to specify all the pins of a gpio_chip
from offset zero to be added to a pin map range, since the
mapping from GPIO to pin controller may not be linear at all,
but need to be broken into a few consecutive sub-ranges or
1-pin entries for complicated cases. The ranges may also be
sparse.

This alters the signature of the function to accept offsets
into both the GPIO-chip local pinspace and the pin controller
local pinspace.

Reviewed-by: Stephen Warren <swarren@nvidia.com>
Reviewed-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2012-11-21 08:55:03 +01:00
Linus Walleij 1e63d7b936 gpiolib: separation of pin concerns
The fact that of_gpiochip_add_pin_range() and
gpiochip_add_pin_range() share too much code is fragile and
will invariably mean that bugs need to be fixed in two places
instead of one.

So separate the concerns of gpiolib.c and gpiolib-of.c and
have the latter call the former as back-end. This is necessary
also when going forward with other device descriptions such
as ACPI.

This is done by:

- Adding a return code to gpiochip_add_pin_range() so we can
  reliably check whether this succeeds.

- Get rid of the custom of_pinctrl_add_gpio_range() from
  pinctrl. Instead create of_pinctrl_get() to just retrive the
  pin controller per se from an OF node. This composite
  function was just begging to be deleted, it was way to
  purpose-specific.

- Use pinctrl_dev_get_name() to get the name of the retrieved
  pin controller and use that to call back into the generic
  gpiochip_add_pin_range().

Now the pin range is only allocated and tied to a pin
controller from the core implementation in gpiolib.c.

Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2012-11-11 19:06:07 +01:00
Linus Walleij 9ef0d6f762 gpiolib: call pin removal in chip removal function
This makes us call gpiochio_remove_pin_ranges() in the
gpiochip_remove() function, so we get rid of ranges when
freeing the chip.

Reviewed-by: Stephen Warren <swarren@nvidia.com>
Reviewed-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2012-11-11 19:06:06 +01:00
Linus Walleij 165adc9c17 gpiolib: fix up function prototypes etc
Commit 69e1601bca88809dc118abd1becb02c15a02ec71
"gpiolib: provide provision to register pin ranges"

Got most of it's function prototypes wrong, so fix this up by:

- Moving the void declarations into static inlines in
  <linux/gpio.h> (previously the actual prototypes were declared
  here...)

- Declare the gpiochip_add_pin_range() and
  gpiochip_remove_pin_ranges() functions in <asm-generic/gpio.h>
  together with the pin range struct declaration itself.

- Actually only implement these very functions in gpiolib.c
  if CONFIG_PINCTRL is set.

- Additionally export the symbols since modules will need to
  be able to do this.

Reviewed-by: Stephen Warren <swarren@nvidia.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2012-11-11 19:06:04 +01:00
Shiraz Hashim f23f1516b6 gpiolib: provide provision to register pin ranges
pinctrl subsystem needs gpio chip base to prepare set of gpio
pin ranges, which a given pinctrl driver can handle. This is
important to handle pinctrl gpio request calls in order to
program a given pin properly for gpio operation.

As gpio base is allocated dynamically during gpiochip
registration, presently there exists no clean way to pass this
information to the pinctrl subsystem.

After few discussions from [1], it was concluded that may be
gpio controller reporting the pin range it supports, is a
better way than pinctrl subsystem directly registering it.

[1] http://comments.gmane.org/gmane.linux.ports.arm.kernel/184816

Cc: Grant Likely <grant.likely@secretlab.ca>
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Shiraz Hashim <shiraz.hashim@st.com>
[Edited documentation a bit]
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2012-11-11 19:06:00 +01:00
Dan Carpenter 529f2ad5e3 gpiolib: unlock on error in gpio_export()
We need to unlock here before returning.

Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2012-10-26 09:35:17 +02:00
Mathias Nyman ad2fab36d7 gpiolib: Don't return -EPROBE_DEFER to sysfs, or for invalid gpios
gpios requested with invalid numbers, or gpios requested from userspace via sysfs
should not try to be deferred on failure.

Cc: stable@kernel.org
Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2012-10-26 09:25:10 +02:00
Mathias Nyman 80b0a60292 gpiolib: add gpio get direction callback support
Add .get_direction callback to gpio_chip. This allows gpiolib
to check the current direction of a gpio.
Used to show the correct gpio direction in sysfs and debug entries.

If callback is not set then gpiolib will work as previously;
e.g. guessing everything is input until a direction is set.

Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2012-10-26 09:18:55 +02:00
Ryan Mallon fc4e251499 gpiolib: Refactor gpio_export
The gpio_export function uses nested if statements and the status
variable to handle the failure cases. This makes the function logic
difficult to follow. Refactor the code to abort immediately on failure
using goto. This makes the code slightly longer, but significantly
reduces the nesting and number of split lines and makes the code easier
to read.

Signed-off-by: Ryan Mallon <rmallon@gmail.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2012-10-23 00:13:36 +02:00
Thierry Reding f9c4a31f61 gpiolib: Use seq_file's iterator interface
When dumping a collection of items via seq_file, it is recommended to
use the iterator interface. For the gpiolib debugfs interface this can
be done to dump each GPIO chip in turn.

Note that for gpiolib this is a little cumbersome because it does not
provide a list of registered GPIO chips and the only way to iterate is
over each GPIO individually. Once a chip is found, the number of GPIOs
it provides can be skipped as a small optimization.

This patch was requested by Arnd Bergmann here:

	http://article.gmane.org/gmane.linux.ports.tegra/3535

Signed-off-by: Thierry Reding <thierry.reding@avionic-design.de>
Cc: Linus Walleij <linus.walleij@stericsson.com>
Cc: Grant Likely <grant.likely@secretlab.ca>
Cc: linux-kernel@vger.kernel.org
Reviewed-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2012-08-17 07:35:41 +02:00
Mark Brown e935457630 gpiolib: Defer failed gpio requests by default
Since users must be explicitly provided with a GPIO number in order to
request one the overwhelmingly common case for failing to request will
be that the required GPIO driver has not yet registered and we should
therefore defer until it has registered.

In order to avoid having to code this logic in individual drivers have
gpio_request() return -EPROBE_DEFER when failing to look up the GPIO.
Drivers which don't want this behaviour can override it if they desire.

Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2012-07-17 21:00:20 +02:00
Grant Likely 07ce8ec730 gpiolib: Remove 'const' from data argument of gpiochip_find()
Commit 3d0f7cf0 "gpio: Adjust of_xlate API to support multiple GPIO
chips" changed the api of gpiochip_find to drop const from the data
parameter of the match hook, but didn't also drop const from data
causing a build warning.

Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
2012-05-18 23:01:05 -06:00
H Hartley Sweeten ee1c1e7d64 gpiolib: quiet gpiochip_add boot message noise
The pr_info message in gpiochip_add gets displayed for every
gpiochip registered. When first bringing up a system this
information could be helpful but for normal use it's just a
bunch of noise. Change the message to a pr_debug.

Signed-off-by: H Hartley Sweeten <hsweeten@visionengravers.com>
Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
2012-05-18 22:12:50 -06:00
Grant Likely 3d0f7cf0f3 gpio: Adjust of_xlate API to support multiple GPIO chips
This patch changes the of_xlate API to make it possible for multiple
gpio_chips to refer to the same device tree node.  This is useful for
banked GPIO controllers that use multiple gpio_chips for a single
device.  With this change the core code will try calling of_xlate on
each gpio_chip that references the device_node and will return the
gpio number for the first one to return 'true'.

Tested-by: Roland Stigge <stigge@antcom.de>
Acked-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
2012-05-18 16:48:36 -06:00
Wolfram Sang fc3a1f04f5 gpio: add flags to export GPIOs when requesting
Introduce new flags to automatically export GPIOs when using the convenience
functions gpio_request_one() or gpio_request_array(). This eases support for
custom boards where lots of GPIOs need to be exported for customer
applications.

Signed-off-by: Wolfram Sang <w.sang@pengutronix.de>
Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
2012-04-05 21:24:06 -07:00
Mark Brown e4e449e828 gpiolib: Add comments explaining the _cansleep() WARN_ON()s
I've seen users getting very confused by the WARN_ON()s for can_sleep
GPIOs in the atomic-safe paths, the discoverability of the non-atomic
version of the API seems to be hampered by the fact that it's defined
in a header file not the .c file where the warnings are.

Add a couple of comments next to the warnings to help people on their
way.

Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Reviwed-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
2012-03-05 08:05:08 -07:00
Laxman Dewangan 25553ff075 gpio: gpiolib: Support for open source/emitter gpios
Adding support for the open source gpio on which client
can specify the open source property through GPIO flag
GPIOF_OPEN_SOURCE at the time of gpio request.
The open source pins are normally pulled low and it
cannot be driven to output with value of 0 and so
when client request for setting the pin to LOW, the
gpio will be set to input direction to make pin in tristate
and hence PULL-DOWN on pins will make the state to LOW.
The open source pin can be driven to HIGH by setting output
with value of 1.

Signed-off-by: Laxman Dewangan <ldewangan@nvidia.com>
Reviwed-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
2012-03-05 07:49:44 -07:00
Laxman Dewangan aca5ce14eb gpio: gpiolib: Support for open drain/collector gpios
Adding support for the open drain gpio on which client
can specify the open drain property through GPIO flag
GPIOF_OPEN_DRAIN at the time of gpio request.
The open drain pins are normally pulled high and it
cannot be driven to output with value of 1 and so
when client request for setting the pin to HIGH, the
gpio will be set to input direction to make pin in tristate
and hence PULL-UP on pins will make the state to HIGH.
The open drain pin can be driven to LOW by setting output
with value of 0.

Signed-off-by: Laxman Dewangan <ldewangan@nvidia.com>
Reviwed-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
2012-03-05 07:49:44 -07:00
Grant Likely 6e2cf65140 gpio: constify the data parameter to gpiochip_find()
Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
2012-03-02 15:56:03 -07:00
Ming Lei 864533ceb6 Fix circular locking dependency (3.3-rc2)
Hi,

On Wed, Feb 8, 2012 at 8:41 PM, Felipe Balbi <balbi@ti.com> wrote:
> Hi guys,
>
> I have just triggered the folllowing:
>
> [   84.860321] ======================================================
> [   84.860321] [ INFO: possible circular locking dependency detected ]
> [   84.860321] 3.3.0-rc2-00026-ge4e8a39 #474 Not tainted
> [   84.860321] -------------------------------------------------------
> [   84.860321] bash/949 is trying to acquire lock:
> [   84.860321]  (sysfs_lock){+.+.+.}, at: [<c0275358>] gpio_value_store+0x24/0xcc
> [   84.860321]
> [   84.860321] but task is already holding lock:
> [   84.860321]  (s_active#22){++++.+}, at: [<c016996c>] sysfs_write_file+0xdc/0x184
> [   84.911468]
> [   84.911468] which lock already depends on the new lock.
> [   84.911468]
> [   84.920043]
> [   84.920043] the existing dependency chain (in reverse order) is:
> [   84.920043]
> [   84.927886] -> #1 (s_active#22){++++.+}:
> [   84.927886]        [<c008f640>] check_prevs_add+0xdc/0x150
> [   84.927886]        [<c008fc18>] validate_chain.clone.24+0x564/0x694
> [   84.927886]        [<c0090cdc>] __lock_acquire+0x49c/0x980
> [   84.951660]        [<c0091838>] lock_acquire+0x98/0x100
> [   84.951660]        [<c016a8e8>] sysfs_deactivate+0xb0/0x100
> [   84.962982]        [<c016b1b4>] sysfs_addrm_finish+0x2c/0x6c
> [   84.962982]        [<c016b8bc>] sysfs_remove_dir+0x84/0x98
> [   84.962982]        [<c02590d8>] kobject_del+0x10/0x78
> [   84.974670]        [<c02c29e8>] device_del+0x140/0x170
> [   84.974670]        [<c02c2a24>] device_unregister+0xc/0x18
> [   84.985382]        [<c0276894>] gpio_unexport+0xbc/0xdc
> [   84.985382]        [<c02768c8>] gpio_free+0x14/0xfc
> [   85.001708]        [<c0276a28>] unexport_store+0x78/0x8c
> [   85.001708]        [<c02c5af8>] class_attr_store+0x18/0x24
> [   85.007293]        [<c0169990>] sysfs_write_file+0x100/0x184
> [   85.018981]        [<c0109d48>] vfs_write+0xb4/0x148
> [   85.018981]        [<c0109fd0>] sys_write+0x40/0x70
> [   85.018981]        [<c0013cc0>] ret_fast_syscall+0x0/0x3c
> [   85.035003]
> [   85.035003] -> #0 (sysfs_lock){+.+.+.}:
> [   85.035003]        [<c008f54c>] check_prev_add+0x680/0x698
> [   85.035003]        [<c008f640>] check_prevs_add+0xdc/0x150
> [   85.052093]        [<c008fc18>] validate_chain.clone.24+0x564/0x694
> [   85.052093]        [<c0090cdc>] __lock_acquire+0x49c/0x980
> [   85.052093]        [<c0091838>] lock_acquire+0x98/0x100
> [   85.069885]        [<c047e280>] mutex_lock_nested+0x3c/0x2f4
> [   85.069885]        [<c0275358>] gpio_value_store+0x24/0xcc
> [   85.069885]        [<c02c18dc>] dev_attr_store+0x18/0x24
> [   85.087158]        [<c0169990>] sysfs_write_file+0x100/0x184
> [   85.087158]        [<c0109d48>] vfs_write+0xb4/0x148
> [   85.098297]        [<c0109fd0>] sys_write+0x40/0x70
> [   85.098297]        [<c0013cc0>] ret_fast_syscall+0x0/0x3c
> [   85.109069]
> [   85.109069] other info that might help us debug this:
> [   85.109069]
> [   85.117462]  Possible unsafe locking scenario:
> [   85.117462]
> [   85.117462]        CPU0                    CPU1
> [   85.128417]        ----                    ----
> [   85.128417]   lock(s_active#22);
> [   85.128417]                                lock(sysfs_lock);
> [   85.128417]                                lock(s_active#22);
> [   85.142486]   lock(sysfs_lock);
> [   85.151794]
> [   85.151794]  *** DEADLOCK ***
> [   85.151794]
> [   85.151794] 2 locks held by bash/949:
> [   85.158020]  #0:  (&buffer->mutex){+.+.+.}, at: [<c01698b8>] sysfs_write_file+0x28/0x184
> [   85.170349]  #1:  (s_active#22){++++.+}, at: [<c016996c>] sysfs_write_file+0xdc/0x184
> [   85.170349]
> [   85.178588] stack backtrace:
> [   85.178588] [<c001b824>] (unwind_backtrace+0x0/0xf0) from [<c008de64>] (print_circular_bug+0x100/0x114)
> [   85.193023] [<c008de64>] (print_circular_bug+0x100/0x114) from [<c008f54c>] (check_prev_add+0x680/0x698)
> [   85.193023] [<c008f54c>] (check_prev_add+0x680/0x698) from [<c008f640>] (check_prevs_add+0xdc/0x150)
> [   85.212524] [<c008f640>] (check_prevs_add+0xdc/0x150) from [<c008fc18>] (validate_chain.clone.24+0x564/0x694)
> [   85.212524] [<c008fc18>] (validate_chain.clone.24+0x564/0x694) from [<c0090cdc>] (__lock_acquire+0x49c/0x980)
> [   85.233306] [<c0090cdc>] (__lock_acquire+0x49c/0x980) from [<c0091838>] (lock_acquire+0x98/0x100)
> [   85.233306] [<c0091838>] (lock_acquire+0x98/0x100) from [<c047e280>] (mutex_lock_nested+0x3c/0x2f4)
> [   85.242614] [<c047e280>] (mutex_lock_nested+0x3c/0x2f4) from [<c0275358>] (gpio_value_store+0x24/0xcc)
> [   85.261840] [<c0275358>] (gpio_value_store+0x24/0xcc) from [<c02c18dc>] (dev_attr_store+0x18/0x24)
> [   85.261840] [<c02c18dc>] (dev_attr_store+0x18/0x24) from [<c0169990>] (sysfs_write_file+0x100/0x184)
> [   85.271240] [<c0169990>] (sysfs_write_file+0x100/0x184) from [<c0109d48>] (vfs_write+0xb4/0x148)
> [   85.290008] [<c0109d48>] (vfs_write+0xb4/0x148) from [<c0109fd0>] (sys_write+0x40/0x70)
> [   85.298400] [<c0109fd0>] (sys_write+0x40/0x70) from [<c0013cc0>] (ret_fast_syscall+0x0/0x3c)
> -bash: echo: write error: Operation not permitted
>
> the way to trigger is:
>
> root@legolas:~# cd /sys/class/gpio/
> root@legolas:/sys/class/gpio# echo 2 > export
> root@legolas:/sys/class/gpio# echo 2 > unexport
> root@legolas:/sys/class/gpio# echo 2 > export
> root@legolas:/sys/class/gpio# cd gpio2/
> root@legolas:/sys/class/gpio/gpio2# echo 1 > value

Looks 'sysfs_lock' needn't to be held for unregister, so the patch below may
fix the problem.

Acked-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
2012-02-15 13:06:07 -07:00
Grant Likely 1a2d397a6e gpio/powerpc: Eliminate duplication of of_get_named_gpio_flags()
A large chunk of qe_pin_request() is unnecessarily cut-and-paste
directly from of_get_named_gpio_flags().  This patch cuts out the
duplicate code and replaces it with a call to of_get_gpio().

v2: fixed compile error due to missing gpio_to_chip()

Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Kumar Gala <galak@kernel.crashing.org>
2011-12-12 13:40:16 -07:00
Grant Likely 64842aad5e 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>
2011-12-12 13:40:16 -07:00
Lars-Peter Clausen 7c295975a8 gpio: make gpio_{request,free}_array gpio array parameter const
gpio_{request,free}_array should not (and do not) modify the passed gpio
array, so make the parameter const.

Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Acked-by: Eric Miao <eric.y.miao@gmail.com>
Acked-by: Wolfram Sang <w.sang@pengutronix.de>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
2011-05-27 17:56:45 -06:00