This patch includes the following amendments:
1) use "?" as a label when the last one is not defined in gpiod_*;
2) whenever it's possible gpiod_* are used;
3) print a function name, if it's already used in other messages.
Additionally it fixes an indentation in few places.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Acked-by: Alexandre Courbot <acourbot@nvidia.com>
Reviewed-by: Alexandre Courbot <acourbot@nvidia.com>
Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Change the format of the platform GPIO lookup tables to make them less
confusing and improve lookup efficiency.
The previous format was a single linked-list that required to compare
the device name and function ID of every single GPIO defined for each
lookup. Switch that to a list of per-device tables, so that the lookup
can be done in two steps, omitting the GPIOs that are not relevant for a
particular device.
The matching rules are now defined as follows:
- The device name must match *exactly*, and can be NULL for GPIOs not
assigned to a particular device,
- If the function ID in the lookup table is NULL, the con_id argument of
gpiod_get() will not be used for lookup. However, if it is defined, it
must match exactly.
- The index must always match.
Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
Acked-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
This switches the two members of struct gpio_chip that were
defined as unsigned foo:1 to bool, because that is indeed what
they are. Switch all users in the gpio and pinctrl subsystems
to assign these values with true/false instead of 0/1. The
users outside these subsystems will survive since true/false
is 1/0, atleast we set some kind of more strict typing example.
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
gpiochip_offset_to_desc() was using gpio_to_desc(), which directly
addresses the global GPIO array we are hoping to get rid of someday.
Reimplement it using the descriptor array of the chip itself, after
checking the requested offset is within the valid bounds of the chip.
Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
It's the drivers responsibility to react on failure to get
the gpio descriptors and not the frameworks. Since there are
some common peripherals that may or may not have certain
pins connected to gpio lines, depending on the platform,
printing the warning there may end up generating useless bug
reports.
Signed-off-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
For platforms that use device tree or ACPI as the standard way to look
GPIOs up, allow the platform-defined GPIO mappings to be used as a
fallback. This may be useful for platforms that need extra GPIOs mappings
not defined by the firmware.
Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
The prototype for static GPIO lookup functions has been updated to use
an explicit type for GPIO lookup flags. Unfortunately the definition of
of_find_gpio() when CONFIG_OF is not defined has been omitted, which
triggers a warning. This patch fixes this.
Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
GPIO mapping properties were defined using the GPIOF_* flags, which are
declared in linux/gpio.h. This file is not included when using the
GPIO descriptor interface.
This patch declares the flags that can be used as GPIO mappings
properties in linux/gpio/driver.h, and uses them in gpiolib, so that no
deprecated declarations are used by the GPIO descriptor interface.
This patch also allows GPIO_OPEN_DRAIN and GPIO_OPEN_SOURCE to be
specified as GPIO mapping properties.
Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
find_chip_by_name() was incorrectly implemented by using
gpio_lookup_list instead of gpiod_chips to iterate through all the
registered GPIO controllers. This patch reimplements it by using
gpiochip_find() with a custom search function, which simplifies the code
on top of fixing the mistake.
Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Modify struct acpi_dev_node to contain a pointer to struct acpi_device
associated with the given device object (that is, its ACPI companion
device) instead of an ACPI handle corresponding to it. Introduce two
new macros for manipulating that pointer in a CONFIG_ACPI-safe way,
ACPI_COMPANION() and ACPI_COMPANION_SET(), and rework the
ACPI_HANDLE() macro to take the above changes into account.
Drop the ACPI_HANDLE_SET() macro entirely and rework its users to
use ACPI_COMPANION_SET() instead. For some of them who used to
pass the result of acpi_get_child() directly to ACPI_HANDLE_SET()
introduce a helper routine acpi_preset_companion() doing an
equivalent thing.
The main motivation for doing this is that there are things
represented by struct acpi_device objects that don't have valid
ACPI handles (so called fixed ACPI hardware features, such as
power and sleep buttons) and we would like to create platform
device objects for them and "glue" them to their ACPI companions
in the usual way (which currently is impossible due to the
lack of valid ACPI handles). However, there are more reasons
why it may be useful.
First, struct acpi_device pointers allow of much better type checking
than void pointers which are ACPI handles, so it should be more
difficult to write buggy code using modified struct acpi_dev_node
and the new macros. Second, the change should help to reduce (over
time) the number of places in which the result of ACPI_HANDLE() is
passed to acpi_bus_get_device() in order to obtain a pointer to the
struct acpi_device associated with the given "physical" device,
because now that pointer is returned by ACPI_COMPANION() directly.
Finally, the change should make it easier to write generic code that
will build both for CONFIG_ACPI set and unset without adding explicit
compiler directives to it.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Tested-by: Mika Westerberg <mika.westerberg@linux.intel.com> # on Haswell
Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Reviewed-by: Aaron Lu <aaron.lu@intel.com> # for ATA and SDIO part
- Merged the GPIO descriptor API from Alexandre Courbot.
This is a first step toward trying to get rid of the
global GPIO numberspace for the future.
- Add an API so that driver can flag that a certain GPIO
line is being used by a irqchip backend for generating
IRQs, so that we can enforce checks, like not allowing
users to switch that line to an output at runtime, since
this makes no sense. Implemented corresponding calls
in a few select drivers.
- ACPI GPIO cleanups, refactorings and switch to using the
descriptor-based interface.
- Support for the TPS80036 Palmas GPIO variant.
- A new driver for the Broadcom Kona GPIO SoC IP block.
- Device tree support for the PCF857x driver.
- A set of ARM GPIO refactorings with the goal of getting
rid of a bunch of custom GPIO implementations from the
arch/arm/* tree:
- Move the IOP GPIO driver to the GPIO subsystem and
fix all users to use the gpiolib API for accessing
GPIOs. Delete the old custom GPIO implementation.
- Delete the unused custom PXA GPIO implemention.
- Convert all users of the IXP4 custom GPIO
implementation to use gpiolib and delete the custom
implementation.
- Delete the custom Gemini GPIO implementation, also
completely unused.
- Various cleanups and renamings.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.15 (GNU/Linux)
iQIcBAABAgAGBQJSgNF3AAoJEEEQszewGV1zPiwP/RdQTL8KTe2ULL2QpKAj2TSP
wuqbvSfW0AOUVf7SvUwXYctxnA718orH2rFKRM9UjK2XFEYgNrtsL4e2Igtbo057
uZ1sr+dytxgLC67CqkbYTfFxQZZ97ZCO3j8VWtVRxcpMEpoE10Y09ZW7nzvF3Lhq
0lRd+Cf4KirurOAVfQOVA0Fv+zKuSKSD0i8FLq60li/5EaxXPrYlene4SNY/B+ue
IWvLJfeDRkv8dR11LYdI/WIET7ljMfIb4MEA5FQ0hae0SSlQtZHQBQi8PjnWnHX0
n+kxFBFMhWPqBDVwbheD4u6U0RFrm8IVfgdVG94G7wlIQXd5TY4d9Nzd2Y5+bzDF
THHZiM9PdzU2rjV2QN5gV+AHJuLw/7tSB9pBpcAtKbwb0FFholUDImWI45YoJAdx
d949YAblh7QZ2nFJJtNgzerco0XAT6BA5/Bs9TPx3L4tij2e+YZzhJbW/EeNmICo
rE98wUdpV9pk6siv56bsoLowCjNOwaWmI6aYErBdh21mTNx65kwd40xWb3ylM3sy
X1QC/oLhqxc7Il/KvF9DbGvpgg5QUB1mY9eb2B+gOhRO0cg+qiWvvvqi0dcTHkaT
aqg7BPXVGUMO73qSsV1x7hmOWsqSFxCBSkVFyWJO7GxqarmWvsXiVh72E85pK60P
RSyJ/5TghCiGAPFWsg/7
=881E
-----END PGP SIGNATURE-----
Merge tag 'gpio-v3.13-1' of git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-gpio
Pull GPIO changes from Linus Walleij:
"Here is the bulk of GPIO changes for the v3.13 development cycle.
I've got ACKs for the things that affect other subsystems (or it's my
own subsystem, like pinctrl). Most of that pertain to an attempt from
my side to consolidate and get rid of custom GPIO implementations in
the ARM tree. I will continue doing this.
The main change this time is the new GPIO descriptor API, background
for this can be found in Corbet's summary from this january in LWN:
http://lwn.net/Articles/533632/
Summary:
- Merged the GPIO descriptor API from Alexandre Courbot. This is a
first step toward trying to get rid of the global GPIO numberspace
for the future.
- Add an API so that driver can flag that a certain GPIO line is
being used by a irqchip backend for generating IRQs, so that we can
enforce checks, like not allowing users to switch that line to an
output at runtime, since this makes no sense. Implemented
corresponding calls in a few select drivers.
- ACPI GPIO cleanups, refactorings and switch to using the
descriptor-based interface.
- Support for the TPS80036 Palmas GPIO variant.
- A new driver for the Broadcom Kona GPIO SoC IP block.
- Device tree support for the PCF857x driver.
- A set of ARM GPIO refactorings with the goal of getting rid of a
bunch of custom GPIO implementations from the arch/arm/* tree:
* Move the IOP GPIO driver to the GPIO subsystem and fix all users
to use the gpiolib API for accessing GPIOs. Delete the old
custom GPIO implementation.
* Delete the unused custom PXA GPIO implemention.
* Convert all users of the IXP4 custom GPIO implementation to use
gpiolib and delete the custom implementation.
* Delete the custom Gemini GPIO implementation, also completely
unused.
- Various cleanups and renamings"
* tag 'gpio-v3.13-1' of git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-gpio: (85 commits)
gpio: gpio-mxs: Remove unneeded dt checks
gpio: pl061: don't depend on CONFIG_ARM
gpio: bcm-kona: add missing .owner to struct gpio_chip
gpiolib: provide a declaration of seq_file in gpio/driver.h
gpiolib: include gpio/consumer.h in of_gpio.h for desc_to_gpio()
gpio: provide stubs for devres gpio functions
gpiolib: devres: add missing headers
gpiolib: make GPIO_DEVRES depend on GPIOLIB
gpiolib: devres: fix devm_gpiod_get_index()
gpiolib / ACPI: document the GPIO descriptor based interface
gpiolib / ACPI: allow passing GPIOF_ACTIVE_LOW for GpioInt resources
gpiolib / ACPI: add ACPI support for gpiod_get_index()
gpiolib / ACPI: convert to gpiod interfaces
gpiolib: add gpiod_get() and gpiod_put() functions
gpiolib: port of_ functions to use gpiod
gpiolib: export descriptor-based GPIO interface
Fixup "MAINTAINERS: GPIO-INTEL-MID: add maintainer"
gpio: bcm281xx: Don't print addresses of GPIO area in probe()
gpio: tegra: use new gpio_lock_as_irq() API
gpio: rcar: Include linux/of.h header
...
- Blackfin ADI pin control driver, we move yet another
architecture under this subsystem umbrella.
- Incremental updates to the Renesas Super-H PFC pin control
driver. New subdriver for the r8a7791 SoC.
- Non-linear GPIO ranges from the gpiolib side of things,
this enabled simplified device tree bindings by referring
entire groups of pins on some pin controller to act as
back-end for a certain GPIO-chip driver.
- Add the Abilis TB10x pin control driver used on the ARC
architecture. Also the corresponding GPIO driver is merged
through this tree, so the ARC has full support for pins
and GPIOs after this.
- Subdrivers for Freescale i.MX1, i.MX27 and i.MX50 pin
controller instances. The i.MX1 and i.MX27 is an entirely
new family (silicon) of controllers whereas i.MX50 is
a variant of the previous supported controller.
- Then the usual slew of fixes, cleanups and incremental
updates.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.15 (GNU/Linux)
iQIcBAABAgAGBQJSgHrbAAoJEEEQszewGV1zX/gP/R4mAl5rixzu7RDC0nlUHz2S
F7zf3nhtsAM9GnvJjh9lE43nrisDdCnnBMFeqb7fEr3sp3j+BjQZLp4w/gbkakfY
6xx6dQ+1+fGojd/gqZI9Le6afpBasAz2E8trariOXW5TmET9ai1y9JCmE2l9K3xA
jX3h138iUZ4SihBW7c/Ib46TWfe7vaeAF0WKpfNie/uMHYyc+nXQXNNvtzxtk+N3
+MMuxr9io+d3OyORHD5PlbwWs+jhEPKXfy/isudlkeGbPrA+CMxTCmRc5iu8AvTv
L0wE6FnBhrdbTUHp9fGmdo1sxmIsijYbbc16yVQOn5kAr/hZvmltjV8efBytEep/
268ruds2l3TWypaPotuj8Z3Fxm0Jr/+tcQ9Ck8CTMdrGG3J5D78U8fLwVKTcfzJ5
QjaG0c39MYBbDPO29wfr93MJF7BoNm0D4AyypOCQiH17jL0Q7sXMpeW2WYqlgFf7
uIWnN3Vsh5V4DcYSCrXoHtts1Wn7i8QEkjyj5gQYvXBU47vGToX5xO6Llvr34lVV
VGMhivC3f5Z1UmTImwhi+FkfdDVwBYEuiAo3J9ezGvls4Ywq4AjZV/QZB563CztE
riZ/Xpw3djrxMLKMjGvebTRGpFHcVoh9XV3FetIk+2SCyK7DK1jyYRE1+tvKudAF
TEIV8476kb7xIVbKt8Oy
=z9SM
-----END PGP SIGNATURE-----
Merge tag 'pinctrl-for-v3.13-1' of git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-pinctrl
Pull pin control updates from Linus Walleij:
"Main pin control pull request for the v3.13 cycle.
The changes hitting arch/blackfin are ACKed by the Blackfin
maintainer, and the device tree bindings are ACKed to the extent
possible by someone from the device tree maintainers group.
- Blackfin ADI pin control driver, we move yet another architecture
under this subsystem umbrella.
- Incremental updates to the Renesas Super-H PFC pin control driver.
New subdriver for the r8a7791 SoC.
- Non-linear GPIO ranges from the gpiolib side of things, this
enabled simplified device tree bindings by referring entire groups
of pins on some pin controller to act as back-end for a certain
GPIO-chip driver.
- Add the Abilis TB10x pin control driver used on the ARC
architecture. Also the corresponding GPIO driver is merged through
this tree, so the ARC has full support for pins and GPIOs after
this.
- Subdrivers for Freescale i.MX1, i.MX27 and i.MX50 pin controller
instances. The i.MX1 and i.MX27 is an entirely new family
(silicon) of controllers whereas i.MX50 is a variant of the
previous supported controller.
- Then the usual slew of fixes, cleanups and incremental updates"
The ARC DT changes are apparently still pending, that hopefully gets
sorted out in a timely manner.
* tag 'pinctrl-for-v3.13-1' of git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-pinctrl: (48 commits)
pinctrl: imx50: add pinctrl support code for the IMX50 SoC
pinctrl: at91: copy define to driver
pinctrl: remove minor dead code
pinctrl: imx: fix using pin->input_val wrongly
pinctrl: imx1: fix return value check in imx1_pinctrl_core_probe()
gpio: tb10x: fix return value check in tb10x_gpio_probe()
gpio: tb10x: use module_platform_driver to simplify the code
pinctrl: imx27: imx27 pincontrol driver
pinctrl: imx1 core driver
pinctrl: sh-pfc: r8a7791 PFC support
sh-pfc: r8a7778: Add CAN pin groups
gpio: add TB10x GPIO driver
pinctrl: at91: correct a few typos
pinctrl: mvebu: remove redundant of_match_ptr
pinctrl: tb10x: use module_platform_driver to simplify the code
pinctrl: tb10x: fix the error handling in tb10x_pinctrl_probe()
pinctrl: add documentation for pinctrl_get_group_pins()
pinctrl: rockchip: emulate both edge triggered interrupts
pinctrl: rockchip: add rk3188 specifics
pinctrl: rockchip: remove redundant check
...
The ACPI GpioInt resources contain polarity field that is used to specify
whether the interrupt is active high or low. Since gpiolib supports
GPIOF_ACTIVE_LOW we can pass this information in the flags field in
acpi_find_gpio(), analogous to the DeviceTree version.
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Reviewed-by: Alexandre Courbot <acourbot@nvidia.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
gpiod_get_index() and gpiod_get() are now the new preferred way to request
GPIOs. Add support for finding the corresponding GPIO descriptor from ACPI
namespace.
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Reviewed-by: Alexandre Courbot <acourbot@nvidia.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Add gpiod_get(), gpiod_get_index() and gpiod_put() functions that
provide safer management of GPIOs.
These functions put the GPIO framework in line with the conventions of
other frameworks in the kernel, and help ensure every GPIO is declared
properly and valid while it is used.
Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
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: Alexandre Courbot <acourbot@nvidia.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
This patch adds the infrastructure required to register non-linear gpio
ranges through gpiolib and the standard GPIO device tree bindings.
Signed-off-by: Christian Ruppert <christian.ruppert@abilis.com>
Signed-off-by: Linus 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: Alexandre Courbot <acourbot@nvidia.com>
Reviewed-by: Stephen Warren <swarren@nvidia.com>
Reviewed-by: Javier Martinez Canillas <javier.martinez@collabora.co.uk>
Signed-off-by: Linus 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: Alexandre Courbot <acourbot@nvidia.com>
Reported-by: Dr. H. Nikolaus Schaller <hns@goldelico.com>
Signed-off-by: Linus 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: Alexandre Courbot <acourbot@nvidia.com>
Reported-by: Dr. H. Nikolaus Schaller <hns@goldelico.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
The pre-existing sysfs interfaces which take explicit namespace
argument are weird in that they place the optional @ns in front of
@name which is contrary to the established convention. For example,
we end up forcing vast majority of sysfs_get_dirent() users to do
sysfs_get_dirent(parent, NULL, name), which is silly and error-prone
especially as @ns and @name may be interchanged without causing
compilation warning.
This renames sysfs_get_dirent() to sysfs_get_dirent_ns() and swap the
positions of @name and @ns, and sysfs_get_dirent() is now a wrapper
around sysfs_get_dirent_ns(). This makes confusions a lot less
likely.
There are other interfaces which take @ns before @name. They'll be
updated by following patches.
This patch doesn't introduce any functional changes.
v2: EXPORT_SYMBOL_GPL() wasn't updated leading to undefined symbol
error on module builds. Reported by build test robot. Fixed.
Signed-off-by: Tejun Heo <tj@kernel.org>
Cc: Eric W. Biederman <ebiederm@xmission.com>
Cc: Kay Sievers <kay@vrfy.org>
Cc: Fengguang Wu <fengguang.wu@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.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: Alexandre Courbot <acourbot@nvidia.com>
Signed-off-by: Linus 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: Mark Brown <broonie@linaro.org>
Signed-off-by: Linus 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: Mark Brown <broonie@linaro.org>
Acked-by: Alexandre Courbot <acourbot@nvidia.com>
Signed-off-by: Linus 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: Linus 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: 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>
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>
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>
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>
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>
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>
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()
...
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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
...
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
This patch allows to trace gpio operations using ftrace
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
Export function gpiochip_find so that modules can use it.
Signed-off-by: Jean Delvare <khali@linux-fr.org>
Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
gpiolib plus two gpio implementations in arm fiddle in the guts of
irq_desc in a racy and buggy way. Remove the stuff. I already told the
gpio folks that we can provide that information in a proper way if
necessary.
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Acked-by: Grant Likely <grant.likely@secretlab.ca>
LKML-Reference: <20110324212508.931638262@linutronix.de>
If GPIO request succeeds, but configuration fails, it should be released.
Signed-off-by: Aaro Koskinen <aaro.koskinen@nokia.com>
Acked-by: Eric Miao <eric.miao@canonical.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
The pca953x driver requires the use of threaded irqs as its irq
demultiplexer can sleep. Our irq handler can be called from any context,
so use request_any_context_irq to allow threaded irqs as well.
Signed-off-by: Daniel Gl?ckner <dg@emlix.com>
Reported-by: Ian Jeffray <ian@jeffray.co.uk>
Cc: David Brownell <david-b@pacbell.net>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
As sysfs_notify_dirent has been made irq safe, there is no reason to not
call it directly from irq. With the work_struct removed, the remaining
element in poll_desc is a sysfs_dirent pointer which may not be NULL. We
can therefore store it directly in the idr and pass it as context to the
irq handler.
Most part of the patch deals with renaming defines and variables to
reflect their new use without functional change.
I also took the opportunity to initialize the idr statically.
Signed-off-by: Daniel Gl?ckner <dg@emlix.com>
Cc: David Brownell <david-b@pacbell.net>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Be more consistent about runtime programming interface abuse warnings,
which can reduce some confusion and trigger bugfixes. Based on an
observation and patch from Jani Nikula.
Also update doc to highlight some sleeping-call issues and to match some
recent changes.
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Cc: Jani Nikula <ext-jani.1.nikula@nokia.com>
Cc: "Ryan Mallon" <ryan@bluewatersys.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
* 'next-devicetree' of git://git.secretlab.ca/git/linux-2.6: (63 commits)
of/platform: Register of_platform_drivers with an "of:" prefix
of/address: Clean up function declarations
of/spi: call of_register_spi_devices() from spi core code
of: Provide default of_node_to_nid() implementation.
of/device: Make of_device_make_bus_id() usable by other code.
of/irq: Fix endian issues in parsing interrupt specifiers
of: Fix phandle endian issues
of/flattree: fix of_flat_dt_is_compatible() to match the full compatible string
of: remove of_default_bus_ids
of: make of_find_device_by_node generic
microblaze: remove references to of_device and to_of_device
sparc: remove references to of_device and to_of_device
powerpc: remove references to of_device and to_of_device
of/device: Replace of_device with platform_device in includes and core code
of/device: Protect against binding of_platform_drivers to non-OF devices
of: remove asm/of_device.h
of: remove asm/of_platform.h
of/platform: remove all of_bus_type and of_platform_bus_type references
of: Merge of_platform_bus_type with platform_bus_type
drivercore/of: Add OF style matching to platform bus
...
Fix up trivial conflicts in arch/microblaze/kernel/Makefile due to just
some obj-y removals by the devicetree branch, while the microblaze
updates added a new file.
When freeing a gpio that has not been exported, gpio_unexport() prints a
debug message when it should just fall through silently.
Example spurious message:
gpio_unexport: gpio0 status -22
Signed-off-by: Jon Povey <jon.povey@racelogic.co.uk>
Cc: David Brownell <david-b@pacbell.net>
Acked-by: Uwe Kleine-K?nig <u.kleine-koenig@pengutronix.de>
Cc: Gregory Bean <gbean@codeaurora.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
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
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
Hopefully it makes the code look nicer and makes it easier to extend
this function.
Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
CC: devicetree-discuss@lists.ozlabs.org
CC: linux-kernel@vger.kernel.org
A few architectures, like OMAP, allow you to set a debouncing time for the
gpio before generating the IRQ. Teach gpiolib about that.
Mark said:
: This would be generally useful for embedded systems, especially where
: the interrupt concerned is a wake source. It allows drivers to avoid
: spurious interrupts from noisy sources so if the hardware supports it
: the driver can avoid having to explicitly wait for the signal to become
: stable and software has to cope with fewer events. We've lived without
: it for quite some time, though.
David said:
: I looked at adding debounce support to the generic GPIO calls (and thus
: gpiolib) some time back, but decided against it. I forget why at this
: time (check list archives) but it wasn't because of lack of utility in
: certain contexts.
:
: One thing to watch out for is just how variable the hardware capabilities
: are. Atmel GPIOs have something like a fixed number of 32K clock cycles
: for debounce, twl4030 had something odd, OMAPs were more like the Atmel
: chips but with a different clock. In some cases debouncing had to be
: ganged, not per-GPIO. And so forth.
Signed-off-by: Felipe Balbi <felipe.balbi@nokia.com>
Cc: Tony Lindgren <tony@atomide.com>
Cc: David Brownell <david-b@pacbell.net>
Reviewed-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
The current message, 'not registered' is confusing as it implies it was
not registered with something, whereas printing 'failed to register'
implies it was the gpiochip_add() call that did not work correctly.
Signed-off-by: Ben Dooks <ben-linux@fluff.org>
Cc: David Brownell <david-b@pacbell.net>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
gpiolib doesn't need to modify the names and I assume most initializers
use string constants that shouldn't be modified anyhow.
[akpm@linux-foundation.org: fix drivers/gpio/cs5535-gpio.c]
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Cc: Kevin Wells <kevin.wells@nxp.com>
Cc: David Brownell <david-b@pacbell.net>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
The problem. When implementing a network namespace I need to be able
to have multiple network devices with the same name. Currently this
is a problem for /sys/class/net/*, /sys/devices/virtual/net/*, and
potentially a few other directories of the form /sys/ ... /net/*.
What this patch does is to add an additional tag field to the
sysfs dirent structure. For directories that should show different
contents depending on the context such as /sys/class/net/, and
/sys/devices/virtual/net/ this tag field is used to specify the
context in which those directories should be visible. Effectively
this is the same as creating multiple distinct directories with
the same name but internally to sysfs the result is nicer.
I am calling the concept of a single directory that looks like multiple
directories all at the same path in the filesystem tagged directories.
For the networking namespace the set of directories whose contents I need
to filter with tags can depend on the presence or absence of hotplug
hardware or which modules are currently loaded. Which means I need
a simple race free way to setup those directories as tagged.
To achieve a reace free design all tagged directories are created
and managed by sysfs itself.
Users of this interface:
- define a type in the sysfs_tag_type enumeration.
- call sysfs_register_ns_types with the type and it's operations
- sysfs_exit_ns when an individual tag is no longer valid
- Implement mount_ns() which returns the ns of the calling process
so we can attach it to a sysfs superblock.
- Implement ktype.namespace() which returns the ns of a syfs kobject.
Everything else is left up to sysfs and the driver layer.
For the network namespace mount_ns and namespace() are essentially
one line functions, and look to remain that.
Tags are currently represented a const void * pointers as that is
both generic, prevides enough information for equality comparisons,
and is trivial to create for current users, as it is just the
existing namespace pointer.
The work needed in sysfs is more extensive. At each directory
or symlink creating I need to check if the directory it is being
created in is a tagged directory and if so generate the appropriate
tag to place on the sysfs_dirent. Likewise at each symlink or
directory removal I need to check if the sysfs directory it is
being removed from is a tagged directory and if so figure out
which tag goes along with the name I am deleting.
Currently only directories which hold kobjects, and
symlinks are supported. There is not enough information
in the current file attribute interfaces to give us anything
to discriminate on which makes it useless, and there are
no potential users which makes it an uninteresting problem
to solve.
Signed-off-by: Eric W. Biederman <ebiederm@xmission.com>
Signed-off-by: Benjamin Thery <benjamin.thery@bull.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Smatch found a potential null dereference in gpio_setup_irq(). The
"pdesc" variable is allocated with idr_find() that can return NULL. If
gpio_setup_irq() is called with 0 as gpio_flags and "pdesc" is null, it
would OOPs here.
Signed-off-by: Dan Carpenter <error27@gmail.com>
Cc: David Brownell <david-b@pacbell.net>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
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>
Passing the attribute to the low level IO functions allows all kinds
of cleanups, by sharing low level IO code without requiring
an own function for every piece of data.
Also drivers can extend the attributes with own data fields
and use that in the low level function.
This makes the class attributes the same as sysdev_class attributes
and plain attributes.
This will allow further cleanups in drivers.
Full tree sweep converting all users.
Signed-off-by: Andi Kleen <ak@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
gpio_request() without initial configuration of the GPIO is normally
useless, introduce gpio_request_one() together with GPIOF_ flags for
input/output direction and initial output level.
gpio_{request,free}_array() for multiple GPIOs.
Signed-off-by: Eric Miao <eric.y.miao@gmail.com>
Cc: David Brownell <dbrownell@users.sourceforge.net>
Cc: Ben Nizette <bn@niasdigital.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Previously enabled poll(2) support on one edge was never reconfigured when
sysfs polarity change was triggered from kernel, because 'struct device
*dev' shadowed an earlier definition.
Found by sparse, which I should've run much earlier.
Signed-off-by: Jani Nikula <ext-jani.1.nikula@nokia.com>
Cc: David Brownell <david-b@pacbell.net>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Drivers may use gpiolib sysfs as part of their public user space
interface. The GPIO number and polarity might change from board to
board. The gpio_export_link() call can be used to hide the GPIO number
from user space. Add support for also hiding the GPIO line polarity
changes from user space.
Signed-off-by: Jani Nikula <ext-jani.1.nikula@nokia.com>
Cc: David Brownell <david-b@pacbell.net>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
In case of failure, device_create() returns not NULL but the error code.
The current code checks for non-NULL though which causes kernel oops in
sysfs_create_group() when device_create() fails. Check for error using
IS_ERR() and propagate the error value using PTR_ERR() instead of fixed
-ENODEV code returned now...
Signed-off-by: Sergei Shtylyov <sshtylyov@ru.mvista.com>
Cc: David Brownell <david-b@pacbell.net>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Many gpio chips allow to generate interrupts when the value of a pin
changes. This patch gives usermode application the opportunity to make
use of this feature by calling poll(2) on the /sys/class/gpio/gpioN/value
sysfs file. The edge to trigger can be set in the edge file in the same
directory. Possible values are "none", "rising", "falling", and "both".
Using level triggers is not possible with current sysfs since nothing
changes the GPIO value (and the IRQ keeps triggering). Edge triggering
will "just work". Note that if there was an event between read() and
poll(), the poll() returns immediately.
Also note that this version only supports true GPIO interrupts. Some
later patch might be able to synthesize this behavior by timer-driven
polling; some systems seem to need that.
[dbrownell@users.sourceforge.net: align ids to 16 bit ids; whitespace]
Signed-off-by: Daniel Glöckner <dg@emlix.com>
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Commit 926b663ce8 (gpiolib: allow GPIOs to
be named) already provides naming on the chip level. This patch provides
more flexibility by allowing multiple names where ever in sysfs on a per
GPIO basis.
Adapted from David Brownell's comments on a similar concept:
http://lkml.org/lkml/2009/4/20/203.
[randy.dunlap@oracle.com: fix build for CONFIG_GENERIC_GPIO=n]
Signed-off-by: Jani Nikula <ext-jani.1.nikula@nokia.com>
Acked-by: David Brownell <david-b@pacbell.net>
Cc: Daniel Silverstone <dsilvers@simtec.co.uk>
Signed-off-by: Randy Dunlap <randy.dunlap@oracle.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
We want to phase out the GPIO "autorequest" mechanism in gpiolib and
require all callers to use gpio_request().
- Update feature-removal-schedule
- Update the documentation now
- Convert the relevant pr_warning() in gpiolib to a WARN()
so folk using this mechanism get a noisy stack dump
Some drivers and board init code will probably need to change.
Implementations not using gpiolib will still be fine; they are already
required to implement gpio_{request,free}() stubs.
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Allow GPIOs in GPIOLIB chips to be named. This name is then used when the
GPIO is exported to sysfs, although it could be used elsewhere if deemed
useful.
Signed-off-by: Daniel Silverstone <dsilvers@simtec.co.uk>
Cc: David Brownell <david-b@pacbell.net>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
There are already various drivers having bigger label than 12 bytes. Most
of them fit well under 20 bytes but make column width exact so that
oversized labels don't mess up output alignment.
Signed-off-by: Jarkko Nikula <jarkko.nikula@nokia.com>
Acked-by: David Brownell <david-b@pacbell.net>
Cc: <stable@kernel.org> [2.6.26.x, 2.6.26.x, 2.6.27.x]
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
This merges branches irq/genirq, irq/sparseirq-v4, timers/hpet-percpu
and x86/uv.
The sparseirq branch is just preliminary groundwork: no sparse IRQs are
actually implemented by this tree anymore - just the new APIs are added
while keeping the old way intact as well (the new APIs map 1:1 to
irq_desc[]). The 'real' sparse IRQ support will then be a relatively
small patch ontop of this - with a v2.6.29 merge target.
* 'genirq-v28-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip: (178 commits)
genirq: improve include files
intr_remapping: fix typo
io_apic: make irq_mis_count available on 64-bit too
genirq: fix name space collisions of nr_irqs in arch/*
genirq: fix name space collision of nr_irqs in autoprobe.c
genirq: use iterators for irq_desc loops
proc: fixup irq iterator
genirq: add reverse iterator for irq_desc
x86: move ack_bad_irq() to irq.c
x86: unify show_interrupts() and proc helpers
x86: cleanup show_interrupts
genirq: cleanup the sparseirq modifications
genirq: remove artifacts from sparseirq removal
genirq: revert dynarray
genirq: remove irq_to_desc_alloc
genirq: remove sparse irq code
genirq: use inline function for irq_to_desc
genirq: consolidate nr_irqs and for_each_irq_desc()
x86: remove sparse irq from Kconfig
genirq: define nr_irqs for architectures with GENERIC_HARDIRQS=n
...
We can get the following oops from gpio_get_value_cansleep() when a GPIO
controller doesn't provide a get() callback:
Unable to handle kernel paging request for instruction fetch
Faulting instruction address: 0x00000000
Oops: Kernel access of bad area, sig: 11 [#1]
[...]
NIP [00000000] 0x0
LR [c0182fb0] gpio_get_value_cansleep+0x40/0x50
Call Trace:
[c7b79e80] [c0183f28] gpio_value_show+0x5c/0x94
[c7b79ea0] [c01a584c] dev_attr_show+0x30/0x7c
[c7b79eb0] [c00d6b48] fill_read_buffer+0x68/0xe0
[c7b79ed0] [c00d6c54] sysfs_read_file+0x94/0xbc
[c7b79ef0] [c008f24c] vfs_read+0xb4/0x16c
[c7b79f10] [c008f580] sys_read+0x4c/0x90
[c7b79f40] [c0013a14] ret_from_syscall+0x0/0x38
It's OK to request the value of *any* GPIO; most GPIOs are bidirectional,
so configuring them as outputs just enables an output driver and doesn't
disable the input logic.
So the problem is that gpio_get_value_cansleep() isn't making the same
sanity check that gpio_get_value() does: making sure this GPIO isn't one
of the atypical "no input logic" cases.
Reported-by: Anton Vorontsov <avorontsov@ru.mvista.com>
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Cc: <stable@kernel.org> [2.6.27.x, 2.6.26.x, 2.6.25.x]
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
gpiolib can export GPIOs to userspace via sysfs. This patch modifies the
gpio_value_show() so that any non-zero value is explicitly printed as "1",
rather than whatever numerical value the lower-level driver returns.
Signed-off-by: Steve Falco <sfalco@harris.com>
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Add a new internal mechanism to gpiolib to support low power
operations by letting gpio_chip instances see when their GPIOs
are in use. When no GPIOs are active, chips may be able to
enter lower powered runtime states by disabling clocks and/or
power domains.
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Cc: "Magnus Damm" <magnus.damm@gmail.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Add a new gpiolib mechanism: gpio_chip instances can provide mappings
between their (input) GPIOs and any associated IRQs. This makes it easier
for platforms to support IRQs that are provided by board-specific external
chips instead of as part of their core (such as SOC-integrated GPIOs).
Also update the irq_to_gpio() description, saying to avoid it because it's
not always supported.
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
According to the documentation gpio_free should only be called from task
context only. To make this more explicit add a might sleep to all
implementations.
This is the generic part which changes gpiolib and the fallback
implementation only.
Signed-off-by: Uwe Kleine-König <ukleinek@informatik.uni-freiburg.de>
Cc: David Brownell <david-b@pacbell.net>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
add CONFIG_HAVE_SPARSE_IRQ to for use condensed array.
Get rid of irq_desc[] array assumptions.
Preallocate 32 irq_desc, and irq_desc() will try to get more.
( No change in functionality is expected anywhere, except the odd build
failure where we missed a code site or where a crossing commit itroduces
new irq_desc[] usage. )
v2: according to Eric, change get_irq_desc() to irq_desc()
Signed-off-by: Yinghai Lu <yhlu.kernel@gmail.com>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
This adds a simple sysfs interface for GPIOs.
/sys/class/gpio
/export ... asks the kernel to export a GPIO to userspace
/unexport ... to return a GPIO to the kernel
/gpioN ... for each exported GPIO #N
/value ... always readable, writes fail for input GPIOs
/direction ... r/w as: in, out (default low); write high, low
/gpiochipN ... for each gpiochip; #N is its first GPIO
/base ... (r/o) same as N
/label ... (r/o) descriptive, not necessarily unique
/ngpio ... (r/o) number of GPIOs; numbered N .. N+(ngpio - 1)
GPIOs claimed by kernel code may be exported by its owner using a new
gpio_export() call, which should be most useful for driver debugging.
Such exports may optionally be done without a "direction" attribute.
Userspace may ask to take over a GPIO by writing to a sysfs control file,
helping to cope with incomplete board support or other "one-off"
requirements that don't merit full kernel support:
echo 23 > /sys/class/gpio/export
... will gpio_request(23, "sysfs") and gpio_export(23);
use /sys/class/gpio/gpio-23/direction to (re)configure it,
when that GPIO can be used as both input and output.
echo 23 > /sys/class/gpio/unexport
... will gpio_free(23), when it was exported as above
The extra D-space footprint is a few hundred bytes, except for the sysfs
resources associated with each exported GPIO. The additional I-space
footprint is about two thirds of the current size of gpiolib (!). Since
no /dev node creation is involved, no "udev" support is needed.
Related changes:
* This adds a device pointer to "struct gpio_chip". When GPIO
providers initialize that, sysfs gpio class devices become children of
that device instead of being "virtual" devices.
* The (few) gpio_chip providers which have such a device node have
been updated.
* Some gpio_chip drivers also needed to update their module "owner"
field ... for which missing kerneldoc was added.
* Some gpio_chips don't support input GPIOs. Those GPIOs are now
flagged appropriately when the chip is registered.
Based on previous patches, and discussion both on and off LKML.
A Documentation/ABI/testing/sysfs-gpio update is ready to submit once this
merges to mainline.
[akpm@linux-foundation.org: a few maintenance build fixes]
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Cc: Guennadi Liakhovetski <g.liakhovetski@pengutronix.de>
Cc: Greg KH <greg@kroah.com>
Cc: Kay Sievers <kay.sievers@vrfy.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
The last gpio belonging to a chip is chip->base + chip->ngpios - 1. Some
places in the code, but not all, forgot the critical minus one.
Signed-off-by: Trent Piepho <xyzzy@speakeasy.org>
Acked-by: David Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
__FUNCTION__ is gcc-specific, use __func__
Signed-off-by: Harvey Harrison <harvey.harrison@gmail.com>
Cc: Ben Dooks <ben-linux@fluff.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Add a new function gpiochip_reserve() to reserve ranges of gpios that platform
code has pre-allocated. That is, this marks gpio numbers which will be
claimed by drivers that haven't yet been loaded, and thus are not available
for dynamic gpio number allocation.
[akpm@linux-foundation.org: remove unneeded __must_check]
[david-b@pacbell.net: don't export gpiochip_reserve (section fix)]
Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
If gpio_chip->base is negative during registration, gpiolib performs dynamic
base allocation. This is useful for devices that aren't always present, such
as GPIOs on hotplugged devices rather than mainboards. (This behavior was
previously specified but not implemented.)
To avoid using any numbers that may have been explicitly assigned but not yet
registered, this dynamic allocation assigns GPIO numbers from the biggest
number on down, instead of from the smallest on up.
Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Introduce a gpio_is_valid() predicate; use it in gpiolib.
Signed-off-by: Guennadi Liakhovetski <g.liakhovetski@pengutronix.de>
[ use inline function; follow the gpio_* naming convention;
work without gpiolib; all programming interfaces need docs ]
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
As long as one or more GPIOs on a gpio chip are used its driver should not be
unloaded. The existing mechanism (gpiochip_remove failure) doesn't address
that, since rmmod can no longer be made to fail by having the cleanup code
report errors. Module usecounts are the solution.
Assuming standard "initialize struct to zero" policies, this change won't
affect SOC platform drivers. However, drivers for external chips (on I2C and
SPI busses) should be updated if they can be built as modules.
Signed-off-by: Guennadi Liakhovetski <g.liakhovetski@pengutronix.de>
[ gpio_ensure_requested() needs to update module usecounts too ]
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Provide new implementation infrastructure that platforms may choose to use
when implementing the GPIO programming interface. Platforms can update their
GPIO support to use this. In many cases the incremental cost to access a
non-inlined GPIO should be less than a dozen instructions, with the memory
cost being about a page (total) of extra data and code. The upside is:
* Providing two features which were "want to have (but OK to defer)" when
GPIO interfaces were first discussed in November 2006:
- A "struct gpio_chip" to plug in GPIOs that aren't directly supported
by SOC platforms, but come from FPGAs or other multifunction devices
using conventional device registers (like UCB-1x00 or SM501 GPIOs,
and southbridges in PCs with more open specs than usual).
- Full support for message-based GPIO expanders, where registers are
accessed through sleeping I/O calls. Previous support for these
"cansleep" calls was just stubs. (One example: the widely used
pcf8574 I2C chips, with 8 GPIOs each.)
* Including a non-stub implementation of the gpio_{request,free}() calls,
making those calls much more useful. The diagnostic labels are also
recorded given DEBUG_FS, so /sys/kernel/debug/gpio can show a snapshot
of all GPIOs known to this infrastructure.
The driver programming interfaces introduced in 2.6.21 do not change at all;
this infrastructure is entirely below those covers.
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Cc: Sam Ravnborg <sam@ravnborg.org>
Cc: Jean Delvare <khali@linux-fr.org>
Cc: Eric Miao <eric.miao@marvell.com>
Cc: Haavard Skinnemoen <hskinnemoen@atmel.com>
Cc: Philipp Zabel <philipp.zabel@gmail.com>
Cc: Russell King <rmk@arm.linux.org.uk>
Cc: Ben Gardner <bgardner@wabtec.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
