This patch exports the gpiod_* family of API functions, a safer
alternative to the legacy GPIO interface. Differences between the gpiod
and legacy gpio APIs are:

- gpio works with integers, whereas gpiod operates on opaque handlers
  which cannot be forged or used before proper acquisition
- gpiod get/set functions are aware of the active low state of a GPIO
- gpio consumers should now include <linux/gpio/consumer.h> to access
  the new interface, whereas chips drivers will use
  <linux/gpio/driver.h>

The legacy gpio API is now built as inline functions on top of gpiod.
Signed-off-by: NAlexandre Courbot <acourbot@nvidia.com>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

It is currently often possible in many GPIO drivers to request
a GPIO line to be used as IRQ after calling gpio_to_irq() and,
as the gpiolib is not aware of this, set the same line to
output and start driving it, with undesired side effects.

As it is a bogus usage scenario to request a line flagged as
output to used as IRQ, we introduce APIs to let gpiolib track
the use of a line as IRQ, and also set this flag from the
userspace ABI.

The API is symmetric so that lines can also be flagged from
.irq_enable() and unflagged from IRQ by .irq_disable().
The debugfs file is altered so that we see if a line is
reserved for IRQ.

Cc: Enric Balletbo i Serra <eballetbo@gmail.com>
Cc: Grant Likely <grant.likely@linaro.org>
Cc: Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>
Cc: Santosh Shilimkar <santosh.shilimkar@ti.com>
Acked-by: NAlexandre Courbot <acourbot@nvidia.com>
Reviewed-by: NStephen Warren <swarren@nvidia.com>
Reviewed-by: NJavier Martinez Canillas <javier.martinez@collabora.co.uk>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

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: NAlexandre Courbot <acourbot@nvidia.com>
Reported-by: NDr. H. Nikolaus Schaller <hns@goldelico.com>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

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: NAlexandre Courbot <acourbot@nvidia.com>
Reported-by: NDr. H. Nikolaus Schaller <hns@goldelico.com>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

gpiod_get/set functions share common code between their regular and
cansleep variants. The exporting of the gpiod interface will make
the situation worse. This patch factorizes the common code to avoid code
redundancy.
Signed-off-by: NAlexandre Courbot <acourbot@nvidia.com>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

Provide the human readable label for the GPIO as well as the number when
we are recording it in order to improve the readability of log messages.
Signed-off-by: NMark Brown <broonie@linaro.org>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

Currently many but not all GPIO log messages log the GPIO number and the
formats vary. Ensure that this is done consistently by defining logging
helpers which take the GPIO descriptor.

The will help people pattern matching on logs and providing the number
makes the log messages that omitted it more useful.
Signed-off-by: NMark Brown <broonie@linaro.org>
Acked-by: NAlexandre Courbot <acourbot@nvidia.com>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

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: NLinus Walleij <linus.walleij@linaro.org>

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: NAlexandre Courbot <acourbot@nvidia.com>
Acked-by: NAlexandre Courbot <acourbot@nvidia.com>
Reviewed-by: NFrank Rowand <frank.rowand@sonymobile.com>
Cc: Tim Bird <tim.bird@sonymobile.com>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

The usage of strict_strtol() is not preferred, because
strict_strtol() is obsolete. Thus, kstrtol() should be
used.
Signed-off-by: NJingoo Han <jg1.han@samsung.com>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

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: NZhangfei Gao <zhangfei.gao@linaro.org>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

This comment applies to gpio_to_chip(), not gpiod_to_chip().
Signed-off-by: NAlexandre Courbot <acourbot@nvidia.com>
Signed-off-by: NGrant Likely <grant.likely@secretlab.ca>

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: NAlexandre Courbot <acourbot@nvidia.com>
Signed-off-by: NGrant Likely <grant.likely@secretlab.ca>

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: NAlexandre Courbot <acourbot@nvidia.com>
Cc: Ryan Mallon <rmallon@gmail.com>
Signed-off-by: NGrant Likely <grant.likely@secretlab.ca>

Convert to the much saner new idr interface.
Signed-off-by: NTejun Heo <tj@kernel.org>
Acked-by: NLinus Walleij <linus.walleij@linaro.org>
Cc: Grant Likely <grant.likely@secretlab.ca>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

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: NGrant Likely <grant.likely@secretlab.ca>

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: NAlexandre Courbot <acourbot@nvidia.com>
Reviewed-by: NLinus Walleij <linus.walleij@linaro.orh>
Signed-off-by: NGrant Likely <grant.likely@secretlab.ca>

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: NAlexandre Courbot <acourbot@nvidia.com>
Reviewed-by: NLinus Walleij <linus.walleij@linaro.org>
[grant.likely: Squash in fix for link error when CONFIG_SYSFS=n]
Signed-off-by: NGrant Likely <grant.likely@secretlab.ca>

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: NAlexandre Courbot <acourbot@nvidia.com>
[grant.likely: Added comment about assignment policy]
Signed-off-by: NGrant Likely <grant.likely@secretlab.ca>

This makes the code both simpler and faster compared to parsing the GPIO
number space.
Signed-off-by: NAlexandre Courbot <acourbot@nvidia.com>
Signed-off-by: NGrant Likely <grant.likely@secretlab.ca>

Using the GPIO chips list is much faster than parsing the entire GPIO
number space.
Signed-off-by: NAlexandre Courbot <acourbot@nvidia.com>
Reviewed-by: NLinus Walleij <linus.walleij@linaro.org>
Signed-off-by: NGrant Likely <grant.likely@secretlab.ca>

Use the small list of GPIO chips instead of parsing the whole GPIO
number space.
Signed-off-by: NAlexandre Courbot <acourbot@nvidia.com>
Reviewed-by: NLinus Walleij <linus.walleij@linaro.org>
Signed-off-by: NGrant Likely <grant.likely@secretlab.ca>

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: NAlexandre Courbot <acourbot@nvidia.com>
Reviewed-by: NLinus Walleij <linus.walleij@linaro.org>
Signed-off-by: NGrant Likely <grant.likely@secretlab.ca>

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: NMichał Mirosław <mirq-linux@rere.qmqm.pl>
Acked-by: NGrant Likely <grant.likely@secretlab.ca>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Add missing braces in an if..else condition.
Signed-off-by: NAlexandre Courbot <acourbot@nvidia.com>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

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: NAlexandre Courbot <acourbot@nvidia.com>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

This is introduced by commit 9ab6e988
"gpiolib: return any error code from range creation".
Signed-off-by: NAxel Lin <axel.lin@ingics.com>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

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: NViresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

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: NStephen Warren <swarren@nvidia.com>
Reviewed-by: NViresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

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: NStephen Warren <swarren@nvidia.com>
Reviewed-by: NViresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

Like with commit 3c739ad0
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: NStephen Warren <swarren@nvidia.com>
Reviewed-by: NViresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

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: NLinus Walleij <linus.walleij@linaro.org>

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: NStephen Warren <swarren@nvidia.com>
Reviewed-by: NViresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

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: NStephen Warren <swarren@nvidia.com>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

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: NViresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: NShiraz Hashim <shiraz.hashim@st.com>
[Edited documentation a bit]
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

We need to unlock here before returning.
Signed-off-by: NDan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

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: NMathias Nyman <mathias.nyman@linux.intel.com>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

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: NMathias Nyman <mathias.nyman@linux.intel.com>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

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: NRyan Mallon <rmallon@gmail.com>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

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/3535Signed-off-by: NThierry 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: NArnd Bergmann <arnd@arndb.de>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>