When requesting own descriptors through hogs, it is useful to
get some details about what's going on if we encounter problems.
Acked-by: Alexandre Courbot <acourbot@nvidia.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
These error messages are helpful to see that we fail to get
hogs. Promote them to real errors so they appear in the boot
crawl.
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
There have been concerns that the function names gpiod_set_array() and
gpiod_get_array() might be confusing to users. One might expect
gpiod_get_array() to return array values, while it is actually the array
counterpart of gpiod_get(). To be consistent with the single descriptor API
we could rename gpiod_set_array() to gpiod_set_array_value(). This makes
some function names a bit lengthy: gpiod_set_raw_array_value_cansleep().
Signed-off-by: Rojhalat Ibrahim <imr@rtschenk.de>
Acked-by: Alexandre Courbot <acourbot@nvidia.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Clean up chained handler and handler data if they were set by
gpiochip_set_chained_irqchip().
Signed-off-by: Dmitry Eremin-Solenikov <dbaryshkov@gmail.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Make sure to free any hogged gpios on errors in gpiochip_add.
Also move all forward declarations to the top of the file.
Fixes: f625d46017 ("gpio: add GPIO hogging mechanism")
Signed-off-by: Johan Hovold <johan@kernel.org>
Reviewed-by: Alexandre Courbot <acourbot@nvidia.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Rename the gpio-chip export/unexport functions to the more descriptive
names gpiochip_sysfs_register and gpiochip_sysfs_unregister.
Signed-off-by: Johan Hovold <johan@kernel.org>
Reviewed-by: Alexandre Courbot <acourbot@nvidia.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Clean up gpiochip_remove somewhat and only output warning about removing
chip with GPIOs requested once.
Signed-off-by: Johan Hovold <johan@kernel.org>
Reviewed-by: Alexandre Courbot <acourbot@nvidia.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
If dev is NULL in __gpiod_get_index() and both ACPI and OF are
enabled, it will be checked twice before the code decides to give
up with DT/ACPI lookup, so avoid that.
Also use the observation that ACPI_COMPANION() is much more efficient
than ACPI_HANDLE(), because the latter uses the former and carries out
a check and a pointer dereference on top of it, so replace the
ACPI_HANDLE() check with an ACPI_COMPANION() one which does not
require the additional IS_ENABLED(CONFIG_ACPI) check too.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Reviewed-by: Hanjun Guo <hanjun.guo@linaro.org>
Acked-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Introduce new functions for conveniently obtaining and disposing of
an entire array of GPIOs with one function call.
ACPI parts tested by Mika Westerberg, DT parts tested by Rojhalat
Ibrahim.
Change log:
v5: move the ACPI functions to gpiolib-acpi.c
v4: - use shorter names for members of struct gpio_descs
- rename lut_gpio_count to platform_gpio_count for clarity
- add check for successful memory allocation
- use ERR_CAST()
v3: - rebase on current linux-gpio devel branch
- fix ACPI GPIO counting
- allow for zero-sized arrays
- make the flags argument mandatory for the new functions
- clarify documentation
v2: change interface
Suggested-by: Alexandre Courbot <acourbot@nvidia.com>
Signed-off-by: Rojhalat Ibrahim <imr@rtschenk.de>
Reviewed-by: Alexandre Courbot <acourbot@nvidia.com>
Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Tested-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Tested-by: Rojhalat Ibrahim <imr@rtschenk.de>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Avoid multiple identical definitions of the gpio suffix strings by putting
them into a global constant array.
Signed-off-by: Rojhalat Ibrahim <imr@rtschenk.de>
Reviewed-by: Alexandre Courbot <acourbot@nvidia.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Based on Boris Brezillion's work this is a reworked patch
of his initial GPIO hogging mechanism.
This patch provides a way to initially configure specific GPIO
when the GPIO controller is probed.
The actual DT scanning to collect the GPIO specific data is performed
as part of gpiochip_add().
The purpose of this is to allow specific GPIOs to be configured
without any driver specific code.
This is particularly useful because board design are getting
increasingly complex and given SoC pins can now have more
than 10 mux values, a lot of connections are now dependent on
external IO muxes to switch various modes.
Specific drivers should not necessarily need to be aware of
what accounts to a specific board implementation. This board level
"description" should be best kept as part of the dts file.
Signed-off-by: Benoit Parrot <bparrot@ti.com>
Reviewed-by: Alexandre Courbot <acourbot@nvidia.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
- GPIOLIB core changes:
- Create and use of_mm_gpiochip_remove() for removing
memory-mapped OF GPIO chips
- GPIO MMIO library suppports bgpio_set_multiple for
switching several lines at once, a feature merged in
the last cycle.
- New drivers:
- New driver for the APM X-gene standby GPIO controller
- New driver for the Fujitsu MB86S7x GPIO controller
- Cleanups:
- Moved rcar driver to use gpiolib irqchip
- Moxart converted to the GPIO MMIO library
- GE driver converted to GPIO MMIO library
- Move sx150x to irqdomain
- Move max732x to irqdomain
- Move vx855 to use managed resources
- Move dwapb to use managed resources
- Clean tc3589x from platform data
- Clean stmpe driver to use device tree only probe
- New subtypes:
- sx1506 support in the sx150x driver
- Quark 1000 SoC support in the SCH driver
- Support X86 in the Xilinx driver
- Support PXA1928 in the PXA driver
- Extended drivers:
- max732x supports device tree probe
- sx150x supports device tree probe
- Various minor cleanups and bug fixes
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQIcBAABAgAGBQJU2W1HAAoJEEEQszewGV1zuRkQAKBukQwx46zQuFH8oalSuxmy
H2/ESMnDmRlBI0zX+dAGDg4HlkO9VwIrdcyzMMe7uO8EFUu9d4/mu2E1f8cY2mxu
kwUSntVaYGVPVj/Vok3kzq1wW/pUQ9E2iMbNeDVZJH/cqEvylPPa2LZ3hZVri57J
orJzaYtZWf640y3McGTUDwIQokgxxdMMyWfm26P1iZkByjofUaYRHS1NIxhKVSVC
Y6uA/Ivvh56ezlPQykc7m6YEjoUS91AMllJca1A3KF3+qvQ3Hnc+i9mB7hAQbJ8L
6Iv2qCD4TgtWT5YXgP0eZsfSV/19kvlVlGX7QQT6o7uIFOLVNOmX9FJAc4n3SGNI
HbxsDdlF9XHVFh0XyKcBQfg0uUmRWUDQ/LsXn9KL6Yrpyx3QZGH/PTYl/XoCj1IO
IL6Bw51FCBXvCvLP5alXMouosAxrc19YpljcAuAMmjVTXe6RoULOZJs+lhTHMhvj
S6FWr6l0XDr4yKb0SXTOGI4hvRJvL8SWnIt5ezZrNrTKLsklL3Bi/o3BoKzzxmqS
6l/rxvcVUov455IrfqJ0ZEM6ZxC9/cvGec0RFyglopNSlKeTQsgWRNa6Pw2xZVk8
orT+G3L4jZ1+0hcjcSwfvHng5Nv6DuhIfUNPbLF/ZzmJcBPqGc/DuhGkFqOrBaXg
ey7Lua6+l+8zcDtugRRG
=yWrB
-----END PGP SIGNATURE-----
Merge tag 'gpio-v3.20-1' of git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-gpio
Pull GPIO changes from Linus Walleij:
"This is the GPIO bulk changes for the v3.20 series:
GPIOLIB core changes:
- Create and use of_mm_gpiochip_remove() for removing memory-mapped
OF GPIO chips
- GPIO MMIO library suppports bgpio_set_multiple for switching
several lines at once, a feature merged in the last cycle.
New drivers:
- New driver for the APM X-gene standby GPIO controller
- New driver for the Fujitsu MB86S7x GPIO controller
Cleanups:
- Moved rcar driver to use gpiolib irqchip
- Moxart converted to the GPIO MMIO library
- GE driver converted to GPIO MMIO library
- Move sx150x to irqdomain
- Move max732x to irqdomain
- Move vx855 to use managed resources
- Move dwapb to use managed resources
- Clean tc3589x from platform data
- Clean stmpe driver to use device tree only probe
New subtypes:
- sx1506 support in the sx150x driver
- Quark 1000 SoC support in the SCH driver
- Support X86 in the Xilinx driver
- Support PXA1928 in the PXA driver
Extended drivers:
- max732x supports device tree probe
- sx150x supports device tree probe
Various minor cleanups and bug fixes"
* tag 'gpio-v3.20-1' of git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-gpio: (61 commits)
gpio: kconfig: replace PPC_OF with PPC
gpio: pxa: add PXA1928 gpio type support
dt/bindings: gpio: add compatible string for marvell,pxa1928-gpio
gpio: pxa: remove mach IRQ includes
gpio: max732x: use an inline function for container cast
gpio: use sizeof() instead of hardcoded values
gpio: max732x: add set_multiple function
gpio: sch: Consolidate similar algorithms
gpio: tz1090-pdc: Use resource_size to fix off-by-one resource size calculation
gpio: ge: Convert to use devm_kstrdup
gpio: correctly use const char * const
gpio: sx150x: fixup OF support
gpio: mpc8xxx: Use of_mm_gpiochip_remove
gpio: Add Fujitsu MB86S7x GPIO driver
gpio: mpc8xxx: Convert to platform device interface.
gpio: zevio: Use of_mm_gpiochip_remove
gpio: gpio-mm-lantiq: Use of_mm_gpiochip_remove
gpio: gpio-mm-lantiq: Use of_property_read_u32
gpio: gpio-mm-lantiq: Do not replicate code
gpio :gpio-mm-lantiq: Use devm_kzalloc
...
gpiolib uses a fixed string for the suffixes and defines it at 32 bytes.
Later in the code snprintf is used with this fixed value of 32. Using
sizeof() is safer in case the size for the suffixes is ever changed.
Signed-off-by: Olliver Schinagl <oliver@schinagl.nl>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
On my previous patch I was overly hasty and made the suffixes string
array
const char const *suffixes, instaed of const char * const suffixes. This
patch corrects that
Signed-off-by: Olliver Schinagl <oliver@schinagl.nl>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Checkpatch complains, and probably with good reason that we should use
const char const * for the static constant array that never gets
changed.
Signed-off-by: Olliver Schinagl <oliver@schinagl.nl>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Unregister gpiochip device (used to export information through sysfs)
before removing it internally. This way removal will reverse addition.
Signed-off-by: Johan Hovold <johan@kernel.org>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Move direct and indirect calls to gpiochip_remove_pin_ranges outside of
spin lock as they can end up taking a mutex in pinctrl_remove_gpio_range.
Note that the pin ranges are already added outside of the lock.
Fixes: 9ef0d6f762 ("gpiolib: call pin removal in chip removal function")
Fixes: f23f1516b6 ("gpiolib: provide provision to register pin ranges")
Cc: stable <stable@vger.kernel.org>
Signed-off-by: Johan Hovold <johan@kernel.org>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Fix memory leak and sleep-while-atomic in gpiochip_remove.
The memory leak was introduced by afa82fab5e ("gpio / ACPI: Move event
handling registration to gpiolib irqchip helpers") that moved the
release of acpi interrupt resources to gpiochip_irqchip_remove, but by
then the resources are no longer accessible as the acpi_gpio_chip has
already been freed by acpi_gpiochip_remove.
Note that this also fixes a few potential sleep-while-atomics, which has
been around since 1425052097 ("gpio: add IRQ chip helpers in gpiolib")
when the call to gpiochip_irqchip_remove while holding a spinlock was
added (a couple of irq-domain paths can end up grabbing mutexes).
Fixes: afa82fab5e ("gpio / ACPI: Move event handling registration to
gpiolib irqchip helpers")
Fixes: 1425052097 ("gpio: add IRQ chip helpers in gpiolib")
Cc: stable <stable@vger.kernel.org>
Signed-off-by: Johan Hovold <johan@kernel.org>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Fix potential corruption of gpio-chip list due to failure to remove the
chip from the list before returning in gpiochip_add error path.
The chip could be long gone when the global list is next traversed,
something which could lead to a null-pointer dereference. In the best
case (chip not deallocated) we are just leaking the gpio range.
Fixes: 14e85c0e69 ("gpio: remove gpio_descs global array")
Signed-off-by: Johan Hovold <johan@kernel.org>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Memory allocated and references taken by of_gpiochip_add and
acpi_gpiochip_add were never released on errors in gpiochip_add (e.g.
failure to find free gpio range).
Fixes: 391c970c0d ("of/gpio: add default of_xlate function if device
has a node pointer")
Fixes: 664e3e5ac6 ("gpio / ACPI: register to ACPI events
automatically")
Cc: stable <stable@vger.kernel.org>
Signed-off-by: Johan Hovold <johan@kernel.org>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
- A new API that allows setting more than one GPIO at the
time. This is implemented for the new descriptor-based
API only and makes it possible to e.g. toggle a clock and
data line at the same time, if the hardware can do this
with a single register write. Both consumers and drivers
need new calls, and the core will fall back to driving
individual lines where needed. Implemented for the MPC8xxx
driver initially.
- Patched the mdio-mux-gpio and the serial mctrl driver
that drives modems to use the new multiple-setting API
to set several signals simultaneously.
- Get rid of the global GPIO descriptor array, and instead
allocate descriptors dynamically for each GPIO on a certain
GPIO chip. This moves us closer to getting rid of the
limitation of using the global, static GPIO numberspace.
- New driver and device tree bindings for 74xx ICs.
- New driver and device tree bindings for the VF610 Vybrid.
- Support the RCAR r8a7793 and r8a7794.
- Guidelines for GPIO device tree bindings trying to get
things a bit more strict with the advent of combined
device properties.
- Suspend/resume support for the MVEBU driver.
- A slew of minor fixes and improvements.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQIcBAABAgAGBQJUjgQ7AAoJEEEQszewGV1zuJ8P+wamlDNhJbsgqXPcSCZZFgeP
1O22VRYqoo/i8mAzNCRi2h6NogO9Da6rCRhHdH35TsuNzIbusHE+btMukj248qJ7
WYOf25I0ImyUP8kulogW4/+7lYibRLHnN2BSLuAkApofmxDvODPS1KNWHulcOcxl
VaVsA8wvFzQO1s1Wjv94ctVfs5rqk7mBfPwk61zHuLeETecmKg0e52p0Uzqlq6gi
UKi9uK3sjQ7kI/+xa+qDrF9GRwRR22oJfD/9zNj8g94iU9iMs5Oh+Zp3RJcvYUSD
y5BIb+IY2ATy20ZkijWmeP8LJz6pja+C9Ne7lKM0jkv7geGeHGAoavz0n3oUq4oz
IvUNz6hCAP9PcxWc5a9FFqqORLWrRew6GmZmJvIkmC9K+3UQcWhkzO3vLpfl6Q9h
S728XexkIlhxG9NcER21bFXV2dw3z/X9dm5mQ473TqJm+wQmRuYcPRg053NbqMcx
juvkweCksx8qlpnjo/1QXQcVwFM8kuR7xAlVo7zdMDOU5F8pdxRnsTl0cUdx5cPv
DKeMRg8+FYcHmIoe/EodemIh7cAZtEpijZNNAr9cDmAjifeBjWhCb+zri5SIc96x
0jKVTXyY4jnHXBVoA0FIl1d2t54yVjh3PYiu0MjeLJ9tyB+Px/nOxW8FrdlFnPJ/
oP5WK13c8h3bMkxUzsvL
=ZAhA
-----END PGP SIGNATURE-----
Merge tag 'gpio-v3.19-2' of git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-gpio
Pull take two of the GPIO updates:
"Same stuff as last time, now with a fixup patch for the previous
compile error plus I ran a few extra rounds of compile-testing.
This is the bulk of GPIO changes for the v3.19 series:
- A new API that allows setting more than one GPIO at the time. This
is implemented for the new descriptor-based API only and makes it
possible to e.g. toggle a clock and data line at the same time, if
the hardware can do this with a single register write. Both
consumers and drivers need new calls, and the core will fall back
to driving individual lines where needed. Implemented for the
MPC8xxx driver initially
- Patched the mdio-mux-gpio and the serial mctrl driver that drives
modems to use the new multiple-setting API to set several signals
simultaneously
- Get rid of the global GPIO descriptor array, and instead allocate
descriptors dynamically for each GPIO on a certain GPIO chip. This
moves us closer to getting rid of the limitation of using the
global, static GPIO numberspace
- New driver and device tree bindings for 74xx ICs
- New driver and device tree bindings for the VF610 Vybrid
- Support the RCAR r8a7793 and r8a7794
- Guidelines for GPIO device tree bindings trying to get things a bit
more strict with the advent of combined device properties
- Suspend/resume support for the MVEBU driver
- A slew of minor fixes and improvements"
* tag 'gpio-v3.19-2' of git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-gpio: (33 commits)
gpio: mcp23s08: fix up compilation error
gpio: pl061: document gpio-ranges property for bindings file
gpio: pl061: hook request if gpio-ranges avaiable
gpio: mcp23s08: Add option to configure IRQ output polarity as active high
gpio: fix deferred probe detection for legacy API
serial: mctrl_gpio: use gpiod_set_array function
mdio-mux-gpio: Use GPIO descriptor interface and new gpiod_set_array function
gpio: remove const modifier from gpiod_get_direction()
gpio: remove gpio_descs global array
gpio: mxs: implement get_direction callback
gpio: em: Use dynamic allocation of GPIOs
gpio: Check if base is positive before calling gpio_is_valid()
gpio: mcp23s08: Add simple IRQ support for SPI devices
gpio: mcp23s08: request a shared interrupt
gpio: mcp23s08: Do not free unrequested interrupt
gpio: rcar: Add r8a7793 and r8a7794 support
gpio-mpc8xxx: add mpc8xxx_gpio_set_multiple function
gpiolib: allow simultaneous setting of multiple GPIO outputs
gpio: mvebu: add suspend/resume support
gpio: gpio-davinci: remove duplicate check on resource
..
Commit 14e85c0e69 ("gpio: remove gpio_descs global array") changed
gpio_to_desc()'s behavior to return NULL not only for GPIOs numbers
not in the valid range, but also for all GPIOs whose controller has not
been probed yet. Although this behavior is more correct (nothing hints
that these GPIO numbers will be populated later), this affects
gpio_request() and gpio_request_one() which call gpiod_request() with a
NULL descriptor, causing it to return -EINVAL instead of the expected
-EPROBE_DEFER for a non-probed GPIO.
gpiod_request() is only called with a descriptor obtained from
gpio_to_desc() from these two functions, so address the issue there.
Other ways to obtain GPIOs rely on well-defined mappings and can thus
return -EPROBE_DEFER only for relevant GPIOs, and are thus not affected
by this issue.
Reported-by: Geert Uytterhoeven <geert@linux-m68k.org>
Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
Tested-by: Geert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Although gpiod_get_direction() can be considered side-effect free for
consumers, its internals involve setting or clearing bits in the
affected GPIO descriptor, for which we need to force-cast the const
descriptor variable to non-const. This could lead to incorrect behavior
if the compiler decides to optimize here, so remove this const
attribute. The intent is to make gpiod_get_direction() private anyway,
so it does not really matter.
Reported-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
Acked-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Replace the ARCH_NR_GPIOS-sized static array of GPIO descriptors by
dynamically-allocated arrays for each GPIO chip.
This change makes gpio_to_desc() perform in O(n) (where n is the number
of GPIO chips registered) instead of O(1), however since n is rarely
bigger than 1 or 2 no noticeable performance issue is expected.
Besides this provides more incentive for GPIO consumers to move to the
gpiod interface. One could use a O(log(n)) structure to link the GPIO
chips together, but considering the low limit of n the hypothetical
performance benefit is probably not worth the added complexity.
This patch uses kcalloc() in gpiochip_add(), which removes the ability
to add a chip before kcalloc() can operate. I am not aware of such
cases, but if someone bisects up to this patch then I will be proven
wrong...
Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
It doesn't make much sense to make some (possible expensive) calls to
gpio_is_valid() first, and to ignore the result if the base number is
negative. Check for a positive base number first.
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Reviewed-by: Alexandre Courbot <acourbot@nvidia.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Introduce new functions gpiod_set_array & gpiod_set_raw_array to the consumer
interface which allow setting multiple outputs with just one function call.
Also add an optional set_multiple function to the driver interface. Without an
implementation of that function in the chip driver outputs are set
sequentially.
Implementing the set_multiple function in a chip driver allows for:
- Improved performance for certain use cases. The original motivation for this
was the task of configuring an FPGA. In that specific case, where 9 GPIO
lines have to be set many times, configuration time goes down from 48 s to
20 s when using the new function.
- Simultaneous glitch-free setting of multiple pins on any kind of parallel
bus attached to GPIOs provided they all reside on the same chip and bank.
Limitations:
Performance is only improved for normal high-low outputs. Open drain and
open source outputs are always set separately from each other. Those kinds
of outputs could probably be accelerated in a similar way if we could
forgo the error checking when setting GPIO directions.
Change log:
v6: - rebase on current linux-gpio devel branch
v5: - check can_sleep property per chip
- remove superfluous checks
- supplement documentation
v4: - add gpiod_set_array function for setting logical values
- change interface of the set_multiple driver function to use
unsigned long as type for the bit fields
- use generic bitops (which also use unsigned long for bit fields)
- do not use ARCH_NR_GPIOS any more
v3: - add documentation
- change commit message
v2: - use descriptor interface
- allow arbitrary groups of GPIOs spanning multiple chips
Signed-off-by: Rojhalat Ibrahim <imr@rtschenk.de>
Reviewed-by: Alexandre Courbot <acourbot@nvidia.com>
Reviewed-by: Mark Brown <broonie@linaro.org>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Some drivers need to deal with only firmware representation of its
GPIOs. An example would be a GPIO button array driver where each button
is described as a separate firmware node in device tree. Typically these
child nodes do not have physical representation in the Linux device
model.
In order to help device drivers to handle such firmware child nodes we
add dev[m]_get_named_gpiod_from_child() that takes a child firmware
node pointer as its second argument (the first one is the parent device
itself), finds the GPIO using whatever is the underlying firmware
method, and requests the GPIO properly.
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Acked-by: Alexandre Courbot <acourbot@nvidia.com>
Acked-by: Grant Likely <grant.likely@linaro.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
With release of ACPI 5.1 and _DSD method we can finally name GPIOs (and
other things as well) returned by _CRS. Previously we were only able to
use integer index to find the corresponding GPIO, which is pretty error
prone if the order changes.
With _DSD we can now query GPIOs using name instead of an integer index,
like the below example shows:
// Bluetooth device with reset and shutdown GPIOs
Device (BTH)
{
Name (_HID, ...)
Name (_CRS, ResourceTemplate ()
{
GpioIo (Exclusive, PullUp, 0, 0, IoRestrictionInputOnly,
"\\_SB.GPO0", 0, ResourceConsumer) {15}
GpioIo (Exclusive, PullUp, 0, 0, IoRestrictionInputOnly,
"\\_SB.GPO0", 0, ResourceConsumer) {27, 31}
})
Name (_DSD, Package ()
{
ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"),
Package ()
{
Package () {"reset-gpio", Package() {^BTH, 1, 1, 0 }},
Package () {"shutdown-gpio", Package() {^BTH, 0, 0, 0 }},
}
})
}
The format of the supported GPIO property is:
Package () { "name", Package () { ref, index, pin, active_low }}
ref - The device that has _CRS containing GpioIo()/GpioInt() resources,
typically this is the device itself (BTH in our case).
index - Index of the GpioIo()/GpioInt() resource in _CRS starting from zero.
pin - Pin in the GpioIo()/GpioInt() resource. Typically this is zero.
active_low - If 1 the GPIO is marked as active_low.
Since ACPI GpioIo() resource does not have field saying whether it is
active low or high, the "active_low" argument can be used here. Setting
it to 1 marks the GPIO as active low.
In our Bluetooth example the "reset-gpio" refers to the second GpioIo()
resource, second pin in that resource with the GPIO number of 31.
This patch implements necessary support to gpiolib for extracting GPIOs
using _DSD device properties.
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Acked-by: Grant Likely <grant.likely@linaro.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
This function actually operates on a gpio_chip, so its prefix should
reflect that fact for consistency with other functions defined in
gpio/driver.h.
Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
cycle:
- Increase the default ARCH_NR_GPIO from 256 to 512. This
was done to avoid having a custom <asm/gpio.h> header for
the x86 architecture - GPIO is custom and complicated
enough as it is already! We want to move to a radix to
store the descriptors going forward, and finally get rid
of this fixed array size altogether.
- Endgame patching of the gpio_remove() semantics initiated
by Abdoulaye Berthe. It is not accepted by the system that
the removal of a GPIO chip fails during e.g. reboot or
shutdown, and therefore the return value has now painfully
been refactored away. For special cases like GPIO expanders
on a hot-pluggable bus like USB, we may later add some
gpiochip_try_remove() call, but for the cases we have now,
return values are moot.
- Some incremental refactoring of the gpiolib core and ACPI
GPIO library for more descriptor usage.
- Refactor the chained IRQ handler set-up method to handle
also threaded, nested interrupts and set up the parent IRQ
correctly. Switch STMPE and TC3589x drivers to use this
registration method.
- Add a .irq_not_threaded flag to the struct gpio_chip, so
that also GPIO expanders that block but are still not
using threaded IRQ handlers.
- New drivers for the ARM64 X-Gene SoC GPIO controller.
- The syscon GPIO driver has been improved to handle the
"DSP GPIO" found on the TI Keystone 2 SoC:s.
- ADNP driver switched to use gpiolib irqchip helpers.
- Refactor the DWAPB driver to support being instantiated
from and MFD cell (platform device).
- Incremental feature improvement in the Zynq, MCP23S08,
DWAPB, OMAP, Xilinx and Crystalcove drivers.
- Various minor fixes.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQIcBAABAgAGBQJUNOr0AAoJEEEQszewGV1z9toP/2ISXRnsi3+jlqVmEGm/y6EA
PPwJOiYnOhZR2/fTCHIF0PNbIi9pw7xKnzxttYCu4uCz7geHX+FfTwUZ2/KWMfqi
ZJ9kEoOVVKzKjmL/m2a2tO4IRSBHqJ8dF3yvaNjS3AL7EDfG6F5STErQurdLEynK
SeJZ2OwM/vRFCac6F7oDlqAUTu3xYGbVD8+zI0H0V/ReocosFlEwcbl2S8ctDWUd
h98M+gY+A8rxkvVMnmQ/k7rUTme/glDQ3z5xVx+uHbS2/a5M1jSM/71cXE6YnSrR
it0CK7CHomq2RzHsKf7oH7GD4kFkukMwFKeMoqz75JWz3352VZPTF53chCIqRSgO
hrgGwZ7WF6pUUUhsn1ZdZsnBPA2Fou2uwslyLSAiE+OYEH2/NSVIOUcorjQcWqU/
0Kix5yb8X1ZzRMhR+TVrTD5V0jguqp2buXq+0P2XlU6MoO2vy7iNf2eXvPg8sF8C
anjTCKgmkzy7eyT2uzfDaNZAyfSBKb1TiKiR9zA0SRChJkCi1ErJEXDGeHiptvSA
+D2k68Ils2LqsvdrnEd2XvVFMllh0iq7b+16o7D+Els0WRbnHpfYCaqfOuF5F4U0
SmeyI0ruawNDc5e9EBKXstt0/R9AMOetyTcTu29U2ZVo90zGaT1ofT8+R1jJ0kGa
bPARJZrgecgv1E9Qnnnd
=8InA
-----END PGP SIGNATURE-----
Merge tag 'gpio-v3.18-1' of git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-gpio
Pull GPIO changes from Linus Walleij:
"This is the bulk of GPIO changes for the v3.18 development cycle:
- Increase the default ARCH_NR_GPIO from 256 to 512. This was done
to avoid having a custom <asm/gpio.h> header for the x86
architecture - GPIO is custom and complicated enough as it is
already! We want to move to a radix to store the descriptors going
forward, and finally get rid of this fixed array size altogether.
- Endgame patching of the gpio_remove() semantics initiated by
Abdoulaye Berthe. It is not accepted by the system that the
removal of a GPIO chip fails during eg reboot or shutdown, and
therefore the return value has now painfully been refactored away.
For special cases like GPIO expanders on a hot-pluggable bus like
USB, we may later add some gpiochip_try_remove() call, but for the
cases we have now, return values are moot.
- Some incremental refactoring of the gpiolib core and ACPI GPIO
library for more descriptor usage.
- Refactor the chained IRQ handler set-up method to handle also
threaded, nested interrupts and set up the parent IRQ correctly.
Switch STMPE and TC3589x drivers to use this registration method.
- Add a .irq_not_threaded flag to the struct gpio_chip, so that also
GPIO expanders that block but are still not using threaded IRQ
handlers.
- New drivers for the ARM64 X-Gene SoC GPIO controller.
- The syscon GPIO driver has been improved to handle the "DSP GPIO"
found on the TI Keystone 2 SoC:s.
- ADNP driver switched to use gpiolib irqchip helpers.
- Refactor the DWAPB driver to support being instantiated from and
MFD cell (platform device).
- Incremental feature improvement in the Zynq, MCP23S08, DWAPB, OMAP,
Xilinx and Crystalcove drivers.
- Various minor fixes"
* tag 'gpio-v3.18-1' of git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-gpio: (52 commits)
gpio: pch: Build context save/restore only for PM
pinctrl: abx500: get rid of unused variable
gpio: ks8695: fix 'else should follow close brace '}''
gpio: stmpe: add verbose debug code
gpio: stmpe: fix up interrupt enable logic
gpio: staticize xway_stp_init()
gpio: handle also nested irqchips in the chained handler set-up
gpio: set parent irq on chained handlers
gpiolib: irqchip: use irq_find_mapping while removing irqchip
gpio: crystalcove: support virtual GPIO
pinctrl: bcm281xx: make Kconfig dependency more strict
gpio: kona: enable only on BCM_MOBILE or for compile testing
gpio, bcm-kona, LLVMLinux: Remove use of __initconst
gpio: Fix ngpio in gpio-xilinx driver
gpio: dwapb: fix pointer to integer cast
gpio: xgene: Remove unneeded #ifdef CONFIG_OF guard
gpio: xgene: Remove unneeded forward declation for struct xgene_gpio
gpio: xgene: Fix missing spin_lock_init()
gpio: ks8695: fix switch case indentation
gpiolib: add irq_not_threaded flag to gpio_chip
...
To unify how we connect cascaded IRQ chips to parent IRQs, if
NULL us passed as handler to the gpiochip_set_chained_irqchip()
function, assume the chips is nested rather than chained, and
we still get the parent set up correctly by way of this function
call.
Alter the drivers for tc3589x and stmpe to use this to set up
their chained handlers as a demonstration of the usage.
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
If the IRQ from the parent is nested the IRQ may need to be
resent under certain conditions. Currently the chained IRQ
handler in gpiolib does not handle connecting nested IRQs
but it is conceptually correct to indicate the actual parent
IRQ.
Reported-by: Grygorii Strashko <grygorii.strashko@ti.com>
Reported-by: Lothar Waßmann <LW@karo-electronics.de>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
There is no guarantee that VIRQs will be allocated sequentially
for gpio irqchip in gpiochip_irqchip_add().
Therefore, it's unsafe to dispose VIRQ in gpiochip_irqchip_remove()
basing on index relatively to stored irq_base value.
Hence, use irq_find_mapping for VIRQ finding in gpiochip_irqchip_remove()
instead of irq_base + index.
Reported-by: Wang, Yalin <Yalin.Wang@sonymobile.com>
Signed-off-by: Grygorii Strashko <grygorii.strashko@ti.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Some GPIO chips (e.g. the DLN2 USB adapter) have blocking get/set
operation but do not need a threaded irq handler.
Signed-off-by: Octavian Purdila <octavian.purdila@intel.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
There is possibility with misconfigured pins that interrupt occurs instantly
after setting irq_set_chained_handler() in gpiochip_set_chained_irqchip().
Now if handler gets called before irq_set_handler_data() the handler gets
NULL handler data.
Fix this by moving irq_set_handler_data() call before
irq_set_chained_handler() in gpiochip_set_chained_irqchip().
Cc: Stable <stable@vger.kernel.org> # 3.15+
Reviewed-by: Alexandre Courbot <acourbot@nvidia.com>
Signed-off-by: Jarkko Nikula <jarkko.nikula@linux.intel.com>
GPIO direction flags are not getting set because
an 'if' statement is the wrong way around.
Cc: Stable <stable@vger.kernel.org> # 3.15+
Signed-off-by: Adrian Hunter <adrian.hunter@intel.com>
Acked-by: Alexandre Courbot <acourbot@nvidia.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
The current prototype of gpiochip_request_own_desc() requires to obtain
a pointer to a descriptor. This is in contradiction to all other GPIO
request schemes, and imposes an extra step of obtaining a descriptor to
drivers. Most drivers actually cannot even perform that step since the
function that does it (gpichip_get_desc()) is gpiolib-private.
Change gpiochip_request_own_desc() to return a descriptor from a
(chip, hwnum) tuple and update users of this function (currently
gpiolib-acpi only).
Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
Tested-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
The huge majority of GPIOs have their direction and initial value set
right after being obtained by one of the gpiod_get() functions. The
integer GPIO API had gpio_request_one() that took a convenience flags
parameter allowing to specify an direction and value applied to the
returned GPIO. This feature greatly simplifies client code and ensures
errors are always handled properly.
A similar feature has been requested for the gpiod API. Since setting
the direction of a GPIO is so often the very next action done after
obtaining its descriptor, we prefer to extend the existing functions
instead of introducing new functions that would raise the
number of gpiod getters to 16 (!).
The drawback of this approach is that all gpiod clients need to be
updated. To limit the pain, temporary macros are introduced that allow
gpiod_get*() to be called with or without the extra flags argument. They
will be removed once all consumer code has been updated.
Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
Reviewed-by: Mark Brown <broonie@linaro.org>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Since now we have irqchip helpers that the GPIO chip drivers are supposed
to use if possible, we can move the registration of ACPI events to happen
in these helpers. This seems to be more natural place and might encourage
GPIO chip driver writers to take advantage of the irqchip helpers.
We make the functions available to GPIO chip drivers via private gpiolib.h,
just in case generic irqchip helpers are not suitable.
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
As per example from the regulator subsystem: put all defines and
functions related to registering board info for GPIO descriptors
into a separate <linux/gpio/machine.h> header.
Cc: Andrew Victor <linux@maxim.org.za>
Cc: Nicolas Ferre <nicolas.ferre@atmel.com>
Cc: Jean-Christophe Plagniol-Villard <plagnioj@jcrosoft.com>
Cc: Ralf Baechle <ralf@linux-mips.org>
Cc: Thierry Reding <thierry.reding@gmail.com>
Acked-by: Stephen Warren <swarren@wwwdotorg.org>
Reviewed-by: Alexandre Courbot <gnurou@gmail.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Both functions were introduced to let gpio drivers request their own
gpio pins. Without exporting the functions, this can however only be
used by gpio drivers built into the kernel.
Secondary impact is that the functions can not currently be used by
platform initialization code associated with the gpio-pca953x driver.
This code permits auto-export of gpio pins through platform data, but
if this functionality is used, the module can no longer be unloaded due
to the problem solved with the introduction of gpiochip_request_own_desc
and gpiochip_free_own_desc.
Export both function so they can be used from modules and from
platform initialization code.
Reviewed-by: Alexandre Courbot <acourbot@nvidia.com>
Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
gpio_ensure_requested() only makes sense when using the integer-based
GPIO API, so make sure it is called from there instead of the gpiod
API which we know cannot be called with a non-requested GPIO anyway.
The uses of gpio_ensure_requested() in the gpiod API were kind of
out-of-place anyway, so putting them in gpio-legacy.c helps clearing the
code.
Actually, considering the time this ensure_requested mechanism has been
around, maybe we should just turn this patch into "remove
gpio_ensure_requested()" if we know for sure that no user depend on it
anymore?
Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
gpio_lock/unlock_as_irq() are working with (chip, offset) arguments and
are thus not using the old integer namespace. Therefore, there is no
reason to have gpiod variants of these functions working with
descriptors, especially since the (chip, offset) tuple is more suitable
to the users of these functions (GPIO drivers, whereas GPIO descriptors
are targeted at GPIO consumers).
Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
As GPIO descriptors are not going to remain unique anymore, having this
function public is not safe. Restrain its use to gpiolib since we have
no user outside of it.
Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
The old integer GPIO interface is, in effect, a privileged user of the
gpiod interface. Reflect this fact further by moving legacy GPIO support
into its own source file. This makes the code clearer and will allow us
to disable legacy GPIO support in the (far) future.
Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
sysfs support is currently entangled within the core GPIO support, while
it should relly just be a (privileged) user of the integer GPIO API.
This patch is a first step towards making the gpiolib code more readable
by splitting it into logical parts.
Move all sysfs support to their own source file, and share static
members of gpiolib that need to be in the private gpiolib.h file. In
the future we will want to put some of them back into gpiolib.c, but this
first patch let us at least identify them.
Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Compiling out GPIO labels results in a space gain so small that it can
hardly be justified. Labels can also be useful for printing debug
messages, so always keep them around.
Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Commit dd34c37aa3 (gpio: of: Allow -gpio suffix for property names)
added parsing for both -gpio and -gpios suffix but also changed
the handling for deferred probe unintentionally. Because of the
looping the second name will now return -ENOENT instead of
-EPROBE_DEFER. Fix the issue by breaking out of the loop if
-EPROBE_DEFER is encountered.
Signed-off-by: Tony Lindgren <tony@atomide.com>
Reviewed-by: Thierry Reding <treding@nvidia.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Introduce gpiod_get_optional() and gpiod_get_index_optional() helpers
that make it easier for drivers to handle optional GPIOs.
Currently in order to handle optional GPIOs, a driver needs to special
case error handling for -ENOENT, such as this:
gpio = gpiod_get(dev, "foo");
if (IS_ERR(gpio)) {
if (PTR_ERR(gpio) != -ENOENT)
return PTR_ERR(gpio);
gpio = NULL;
}
if (gpio) {
/* set up GPIO */
}
With these new helpers the above is reduced to:
gpio = gpiod_get_optional(dev, "foo");
if (IS_ERR(gpio))
return PTR_ERR(gpio);
if (gpio) {
/* set up GPIO */
}
While at it, device-managed variants of these functions are also
provided.
Signed-off-by: Thierry Reding <treding@nvidia.com>
Reviewed-by: Alexandre Courbot <acourbot@nvidia.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
The function is called gpiod_get(), not gpio_get(). Fix the kernel-doc
comment to match the name.
Signed-off-by: Thierry Reding <treding@nvidia.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Many bindings use the -gpio suffix in property names. Support this in
addition to the -gpios suffix when requesting GPIOs using the new
descriptor-based API.
Signed-off-by: Thierry Reding <treding@nvidia.com>
Acked-by: Alexandre Courbot <acourbot@nvidia.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
of_find_gpio() is always called under an IS_ENABLED(CONFIG_OF), so the
dummy implementation provided for !OF configurations is not needed.
Signed-off-by: Thierry Reding <treding@nvidia.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Some GPIO irqchip drivers exploit the irqdomain mapping
function to set up the IRQ default type in the hardware,
make sure that if we pass IRQ_TYPE_NONE, no hardware setup
whatsoever takes place (this should be the norm) until
later when the IRQ gets utilized.
Cc: Ezequiel Garcia <ezequiel.garcia@free-electrons.com>
Cc: Santosh Shilimkar <santosh.shilimkar@ti.com>
Cc: linux-omap <linux-omap@vger.kernel.org>
Tested-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
Tested-by: Javier Martinez Canillas <javier@dowhile0.org>
Tested-by: Nishanth Menon <nm@ti.com>
Acked-by: Nishanth Menon <nm@ti.com>
Tested-by: Tony Lindgren <tony@atomide.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Another feature that is duplicated in a number of GPIO irqchips
is that these cascades IRQs are assigned their own lock class
so as to avoid warnings about lockdep recursions. Do this also
in the generic GPIO irqchip helpers for smooth transition to
this core infrastructure.
Cc: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Some off-chip GPIO expanders need to be communicated by I2C or
SPI traffic, but may still support IRQs. By the sleeping nature
of such buses, such IRQ handlers need to be threaded. Support
such handlers in the gpiochip irqchip helpers by flagging IRQs
as threaded if the .can_sleep property of the gpiochip is
true.
Helpfully deny registration of chained IRQ handlers if the
.can_sleep property is set, as such chips will invariably need
a nested handler rather than a chained handler.
Cc: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
During irq mapping, in irq_set_chip_and_handler() the process
of setting this up may incur calls to lock the irqchip, which
in turn may need to dereference and use the chip data. So set
the data first, then set the chip and handler.
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
When using the irqchip helper inside the gpiolib, make sure
the IRQs are unmapped/disposed before the irqdomain is removed
as part of removing the gpiochip.
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
This provides a function gpiochip_irqchip_add() to set
up an irqchip for a GPIO controller, and a function
gpiochip_set_chained_irqchip() to chain it to a parent
irqchip.
Most GPIOs are of the type where a number of lines form
a cascaded interrupt controller chained onto
the primary system interrupt controller (or further down the
chain) so let's add this helper and factor the code to
request the lines to be used as IRQs, the .to_irq() function
and the irqdomain into the core as well.
Acked-by: Thomas Gleixner <tglx@linutronix.de>
Acked-by: Alexandre Courbot <acourbot@nvidia.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Nothing prevents GPIO drivers from returning values outside the
boolean range, and as it turns out a few drivers are actually doing so.
These values were passed as-is to unsuspecting consumers and created
confusion.
This patch makes the internal _gpiod_get_raw_value() function return a
bool, effectively clamping the GPIO value to the boolean range no
matter what the driver does.
While we are at it, we also change the value parameter of
_gpiod_set_raw_value() to bool type before drivers start doing funny
things with it as well.
Another way to fix this would be to change the prototypes of the driver
interface to use bool directly, but this would require a huge
cross-systems patch so this simpler solution is preferred.
Changes since v1:
- Change local variable type to bool as well, use boolean values in
code
- Also change prototype of open drain/open source setting functions
since they are only called from _gpiod_set_raw_value()
This probably calls for a larger booleanization of gpiolib, but let's
keep that for a latter change - right now we need to address the issue
of non-boolean values returned by drivers.
Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
The current ACPI GPIO event handling code was never tested against real
hardware with functioning GPIO triggered events (at the time such hardware
wasn't available). Thus it misses certain things like requesting the GPIOs
properly, passing correct flags to the interrupt handler and so on.
This patch reworks ACPI GPIO event handling so that we:
1) Use struct acpi_gpio_event for all GPIO signaled events.
2) Switch to use GPIO descriptor API and request GPIOs by calling
gpiochip_request_own_desc() that we added in a previous patch.
3) Pass proper flags from ACPI GPIO resource to request_threaded_irq().
Also instead of open-coding the _AEI iteration loop we can use
acpi_walk_resources(). This simplifies the code a bit and fixes memory leak
that was caused by missing kfree() for buffer returned by
acpi_get_event_resources().
Since the remove path now calls gpiochip_free_own_desc() which takes GPIO
spinlock we need to call acpi_gpiochip_remove() outside of that lock
(analogous to acpi_gpiochip_add() path where the lock is released before
those funtions are called).
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Reviewed-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Sometimes it is useful to allow GPIO chips themselves to request GPIOs they
own through gpiolib API. One use case is ACPI ASL code that should be able
to toggle GPIOs through GPIO operation regions.
We can't use gpio_request() because it will pin the module to the kernel
forever (it calls try_module_get()). To solve this we move module refcount
manipulation to gpiod_request() and let __gpiod_request() handle the actual
request. This changes the sequence a bit as now try_module_get() is called
outside of gpio_lock (I think this is safe, try_module_get() handles
serialization it needs already).
Then we provide gpiolib internal functions gpiochip_request/free_own_desc()
that do the same as gpio_request() but don't manipulate module refrence
count. This allows the GPIO chip driver to request and free descriptors it
owns without being pinned to the kernel forever.
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Reviewed-by: Alexandre Courbot <acourbot@nvidia.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
It is currently debated where the functions to lock a certain
GPIO line as used for IRQs should be called. Delete all
misleading documentation.
Reported-by: Thomas Gleixner <tglx@linutronix.de>
Cc: Jean-Jacques Hiblot <jjhiblot@traphandler.com>
Acked-by: Alexandre Courbot <acourbot@nvidia.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Some drivers dealing with a gpio_chip might need to act on its
descriptors directly; one example is pinctrl drivers that need to lock a
GPIO for being used as IRQ using gpiod_lock_as_irq().
This patch exports a gpiochip_get_desc() function that returns the
GPIO descriptor at the requested index. It also sweeps the
gpio_to_chip() function out of the consumer interface since any holder
of a gpio_chip reference can manipulate its GPIOs way beyond what a
consumer should be allowed to do.
As a result, gpio_chip is not visible anymore to simple GPIO consumers.
Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Reviewed-by: Jean-Jacques Hiblot <jjhiblot@traphandler.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
The documentation was not clear about whether
gpio_direction_output should take a logical value or the physical
level on the output line, i.e. whether the ACTIVE_LOW status
would be taken into account.
This converts gpiod_direction_output to use the logical level
and adds a new gpiod_direction_output_raw for the raw value.
Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
Reviewed-by: Alexandre Courbot <acourbot@nvidia.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
A big set this merge window, as we have much going on in
this subsystem. Major changes this time:
- Some core improvements and cleanups to the new GPIO
descriptor API. This seems to be working now so we can
start the exodus to this API, moving gradually away from
the global GPIO numberspace.
- Incremental improvements to the ACPI GPIO core, and move
the few GPIO ACPI clients we have to the GPIO descriptor
API right *now* before we go any further. We actually
managed to contain this *before* we started to litter
the kernel with yet another hackish global numberspace for
the ACPI GPIOs, which is a big win.
- The RFkill GPIO driver and all platforms using it have
been migrated to use the GPIO descriptors rather than
fixed number assignments. Tegra machine has been migrated
as part of this.
- New drivers for MOXA ART, Xtensa GPIO32 and SMSC SCH311x.
Those should be really good examples of how I expect a
nice GPIO driver to look these days.
- Do away with custom GPIO implementations on a major
part of the ARM machines: ks8695, lpc32xx, mv78xx0.
Make a first step towards the same in the horribly
convoluted Samsung S3C include forest. We expect to
continue to clean this up as we move forward.
- Flag GPIO lines used for IRQ on adnp, bcm-kona, em,
intel-mid and lynxpoint.
This makes the GPIOlib core aware that a certain GPIO line
is used for IRQs and can then enforce some semantics such
as disallowing a GPIO line marked as in use for IRQ to be
switched to output mode.
- Drop all use of irq_set_chip_and_handler_name().
The name provided in these cases were just unhelpful
tags like "mux" or "demux".
- Extend the MCP23s08 driver to handle interrupts.
- Minor incremental improvements for rcar, lynxpoint, em
74x164 and msm drivers.
- Some non-urgent bug fixes here and there, duplicate
#includes and that usual kind of cleanups.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQIcBAABAgAGBQJS3i/MAAoJEEEQszewGV1zVB8P/Rjzgx8To0gQPn49M4u/A1Mk
mAzpUoKa05ILTKBm/bpWPYZPpg9PDqUxOYPsIDEAkc70BKMPTXxrYiE+LSfIzwaJ
a8IRwOzNL7Iwc+zPNS/GrmRJyxymb4lmMD/fypk/YaumZ6j4Hbo+9R8Zct9gbZ5Q
ZbKtz6kLhbkbNCc71bVMgk6yacSBx1ak8Xpd12HlW85NgOCoBj7/DI1Lb61x1ImY
NYpSpmtfGGTkQLtBl5dTLefZOvL1dKSct9TMOsA2jzNqf3zA1YA6XOxPGHK/qtjq
3s9cN1sIVF/g7sm1+qoKXe0OTQrXHT7SX8BH9/tb3MiKO8ItactlQUJlYNR3WFSN
zm1PNe5zWr+GWzV0iUrqoMN4XX8nThiFDOxZpOwBTZcUD6qtDFIZp41M3qxwFTbJ
hCtSQ8gUO1Ce+xtOQYYOwEkRS7FZa1Z+p/lendTFuGDh6DcXy97SrKkTktM4Q98B
LhqrwUzCdES0ecNDi2+P5y4Fc7M0cMMn9SnFvbSBObLB89TF9uzMIn8jUBCZMvrM
eAeZlRBYk8F+6F12higaWqZyiBKIEubXo/Z8T0L2KEDm/z/ddJvhQgBKvWlf3rqi
RToD446rda+RhFBnxLZ3mTui5nZ2WyKTOqhVqeBuriJhE/cTUaQHUBUrbOwx20kE
Xb9mQ2n3GRk2157n1CLY
=lW2i
-----END PGP SIGNATURE-----
Merge tag 'gpio-v3.14-1' of git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-gpio
Pull GPIO tree bulk changes from Linus Walleij:
"A big set this merge window, as we have much going on in this
subsystem. The changes to other subsystems (notably a slew of ARM
machines as I am doing away with their custom APIs) have all been
ACKed to the extent possible.
Major changes this time:
- Some core improvements and cleanups to the new GPIO descriptor API.
This seems to be working now so we can start the exodus to this
API, moving gradually away from the global GPIO numberspace.
- Incremental improvements to the ACPI GPIO core, and move the few
GPIO ACPI clients we have to the GPIO descriptor API right *now*
before we go any further. We actually managed to contain this
*before* we started to litter the kernel with yet another hackish
global numberspace for the ACPI GPIOs, which is a big win.
- The RFkill GPIO driver and all platforms using it have been
migrated to use the GPIO descriptors rather than fixed number
assignments. Tegra machine has been migrated as part of this.
- New drivers for MOXA ART, Xtensa GPIO32 and SMSC SCH311x. Those
should be really good examples of how I expect a nice GPIO driver
to look these days.
- Do away with custom GPIO implementations on a major part of the ARM
machines: ks8695, lpc32xx, mv78xx0. Make a first step towards the
same in the horribly convoluted Samsung S3C include forest. We
expect to continue to clean this up as we move forward.
- Flag GPIO lines used for IRQ on adnp, bcm-kona, em, intel-mid and
lynxpoint.
This makes the GPIOlib core aware that a certain GPIO line is used
for IRQs and can then enforce some semantics such as disallowing a
GPIO line marked as in use for IRQ to be switched to output mode.
- Drop all use of irq_set_chip_and_handler_name(). The name provided
in these cases were just unhelpful tags like "mux" or "demux".
- Extend the MCP23s08 driver to handle interrupts.
- Minor incremental improvements for rcar, lynxpoint, em 74x164 and
msm drivers.
- Some non-urgent bug fixes here and there, duplicate #includes and
that usual kind of cleanups"
Fix up broken Kconfig file manually to make this all compile.
* tag 'gpio-v3.14-1' of git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-gpio: (71 commits)
gpio: mcp23s08: fix casting caused build warning
gpio: mcp23s08: depend on OF_GPIO
gpio: mcp23s08: Add irq functionality for i2c chips
ARM: S5P[v210|c100|64x0]: Fix build error
gpio: pxa: clamp gpio get value to [0,1]
ARM: s3c24xx: explicit dependency on <plat/gpio-cfg.h>
ARM: S3C[24|64]xx: move includes back under <mach/> scope
Documentation / ACPI: update to GPIO descriptor API
gpio / ACPI: get rid of acpi_gpio.h
gpio / ACPI: register to ACPI events automatically
mmc: sdhci-acpi: convert to use GPIO descriptor API
ARM: s3c24xx: fix build error
gpio: f7188x: set can_sleep attribute
gpio: samsung: Update documentation
gpio: samsung: Remove hardware.h inclusion
gpio: xtensa: depend on HAVE_XTENSA_GPIO32
gpio: clps711x: Enable driver compilation with COMPILE_TEST
gpio: clps711x: Use of_match_ptr()
net: rfkill: gpio: convert to descriptor-based GPIO interface
leds: s3c24xx: Fix build failure
...
Now that all users of acpi_gpio.h have been moved to use either the GPIO
descriptor interface or to the internal gpiolib.h we can get rid of
acpi_gpio.h entirely.
Once this is done the only interface to get GPIOs to drivers enumerated
from ACPI namespace is the descriptor based interface.
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Acked-by: Alexandre Courbot <acourbot@nvidia.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Instead of asking each driver to register to ACPI events we can just call
acpi_gpiochip_register_interrupts() for each chip that has an ACPI handle.
The function checks chip->to_irq and if it is set to NULL (a GPIO driver
that doesn't do interrupts) the function does nothing.
We also add the a new header drivers/gpio/gpiolib.h that is used for
functions internal to gpiolib and add ACPI GPIO chip registering functions
to that header.
Once that is done we can remove call to acpi_gpiochip_register_interrupts()
from its only user, pinctrl-baytrail.c
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Some devices drivers make use of optional GPIO parameters. For such
drivers, it is important to discriminate between the case where no
GPIO mapping has been defined for the function they are requesting, and
the case where a mapping exists but an error occured while resolving it
or when acquiring the GPIO.
This patch changes the family of gpiod_get() functions such that they
will return -ENOENT if and only if no GPIO mapping is defined for the
requested function. Other error codes are used when an actual error
occured during the GPIO resolution.
Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
kernfs has just been separated out from sysfs and we're already in
full conflict mode. Nothing can make the situation any worse. Let's
take the chance to name things properly.
This patch performs the following renames.
* s/sysfs_elem_dir/kernfs_elem_dir/
* s/sysfs_elem_symlink/kernfs_elem_symlink/
* s/sysfs_elem_attr/kernfs_elem_file/
* s/sysfs_dirent/kernfs_node/
* s/sd/kn/ in kernfs proper
* s/parent_sd/parent/
* s/target_sd/target/
* s/dir_sd/parent/
* s/to_sysfs_dirent()/rb_to_kn()/
* misc renames of local vars when they conflict with the above
Because md, mic and gpio dig into sysfs details, this patch ends up
modifying them. All are sysfs_dirent renames and trivial. While we
can avoid these by introducing a dummy wrapping struct sysfs_dirent
around kernfs_node, given the limited usage outside kernfs and sysfs
proper, I don't think such workaround is called for.
This patch is strictly rename only and doesn't introduce any
functional difference.
- mic / gpio renames were missing. Spotted by kbuild test robot.
Signed-off-by: Tejun Heo <tj@kernel.org>
Cc: Neil Brown <neilb@suse.de>
Cc: Linus Walleij <linus.walleij@linaro.org>
Cc: Ashutosh Dixit <ashutosh.dixit@intel.com>
Cc: kbuild test robot <fengguang.wu@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The patch just accents that @dev could be NULL.
There is no functional change.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
In several places we are printing messages with prefix based on chip->label.
Introduced macros help us to do this easier and in uniform way.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Reviewed-by: Alexandre Courbot <acourbot@nvidia.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
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>
