Commit cb464a88e1ed ("gpio: make the gpiochip a real device") call
gpiochip_sysfs_unregister after the gpiochip is empty. It lead to the
following crash:
Quan Nguyen [Wed, 17 Feb 2016 13:15:07 +0000 (20:15 +0700)]
gpio: xgene: Enable X-Gene standby GPIO as interrupt controller
Enable X-Gene standby GPIO controller as interrupt controller to provide
its own resources. This avoids ambiguity where GIC interrupt resource is
use as X-Gene standby GPIO interrupt resource in user driver.
Signed-off-by: Y Vo <yvo@apm.com> Signed-off-by: Quan Nguyen <qnguyen@apm.com> Acked-by: Marc Zyngier <marc.zyngier@arm.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Linus Walleij [Fri, 12 Feb 2016 21:25:22 +0000 (22:25 +0100)]
gpio: add userspace ABI for GPIO line information
This adds a GPIO line ABI for getting name, label and a few select
flags from the kernel.
This hides the kernel internals and only tells userspace what it
may need to know: the different in-kernel consumers are masked
behind the flag "kernel" and that is all userspace needs to know.
However electric characteristics like active low, open drain etc
are reflected to userspace, as this is important information.
We provide information on all lines on all chips, later on we will
likely add a flag for the chardev consumer so we can filter and
display only the lines userspace actually uses in e.g. lsgpio,
but then we first need an ABI for userspace to grab and use
(get/set/select direction) a GPIO line.
Sample output from "lsgpio" on ux500:
GPIO chip: gpiochip7, "8011e000.gpio", 32 GPIO lines
line 0: unnamed unlabeled
line 1: unnamed unlabeled
(...)
line 25: unnamed "SFH7741 Proximity Sensor" [kernel output open-drain]
line 26: unnamed unlabeled
(...)
Tested-by: Michael Welling <mwelling@ieee.org> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Linus Walleij [Fri, 12 Feb 2016 13:48:23 +0000 (14:48 +0100)]
gpio: store reflect the label to userspace
The gpio_chip label is useful for userspace to understand what
kind of GPIO chip it is dealing with. Let's store a copy of this
label in the gpio_device, add it to the struct passed to userspace
for GPIO_GET_CHIPINFO_IOCTL and modify lsgpio to show it.
Arnd Bergmann [Tue, 16 Feb 2016 15:40:36 +0000 (16:40 +0100)]
gpio: ks8695: remove irq_to_gpio function
The ks8695 gpio driver has its own copy of the irq_to_gpio()
function. This is completely unused in the mainline kernel
after we converted all remaining users several years ago,
so we can remove the definition as well.
Josh Cartwright [Wed, 17 Feb 2016 22:44:15 +0000 (16:44 -0600)]
gpio: use kzalloc to allocate gpio_device
The use of kmalloc() to allocate the gpio_device leaves the contained struct
device object in an unknown state. Calling dev_set_name() on a struct device
of unknown state can trigger the free() of an invalid pointer, as seen in the
following backtrace (collected by Tony Lindgren):
Linus Walleij [Tue, 16 Feb 2016 14:41:42 +0000 (15:41 +0100)]
gpio: create an API to detect open drain/source on lines
My left hand merges code to privatize the descriptor handling
while my right hand merges drivers that poke around and
disrespect with the same gpiolib internals.
So let's expose the proper APIs for drivers to ask the gpiolib
core if a line is marked as open drain or open source and
get some order around things so this driver compiles again.
Reported-by: Stephen Rothwell <sfr@canb.auug.org.au> Cc: Nicolas Saenz Julienne <nicolassaenzj@gmail.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Nicholas Krause [Wed, 3 Feb 2016 00:17:59 +0000 (19:17 -0500)]
gpio: davinci: Fix possible NULL pointer deference
This fixes a possible NULL pointer deference in the function,
davinci_gpio_probe due to the function, gpio2regs being able
to return a NULL pointer if it rans to get the registers for
the gpio devices on a davinci board. Furthermore if this does
arise return -ENXIO to signal callers that this case has arisen
and avoiding setting the regs or other pointer values on the
Bjorn Helgaas [Tue, 2 Feb 2016 19:53:30 +0000 (13:53 -0600)]
gpio: Remove unused asm/gpio.h files
asm/gpio.h is included only by linux/gpio.h, and then only when the arch
selects ARCH_HAVE_CUSTOM_GPIO_H. Only the following arches select it: arm
avr32 blackfin m68k (COLDFIRE only) sh unicore32.
Remove the unused asm/gpio.h files for the arches that do not select
ARCH_HAVE_CUSTOM_GPIO_H.
This is a follow-on to 7563bbf89d06 ("gpiolib/arches: Centralise
bolierplate asm/gpio.h").
Bjorn Helgaas [Tue, 2 Feb 2016 19:53:23 +0000 (13:53 -0600)]
gpio: Include linux/gpio.h instead of asm/gpio.h
Most arches have an asm/gpio.h that merely includes linux/gpio.h. The
others select ARCH_HAVE_CUSTOM_GPIO_H, and when that's selected,
linux/gpio.h includes asm/gpio.h.
Therefore, code should include linux/gpio.h instead of including asm/gpio.h
directly.
Remove includes of asm/gpio.h, adding an include of linux/gpio.h when
necessary.
This is a follow-on to 7563bbf89d06 ("gpiolib/arches: Centralise
bolierplate asm/gpio.h").
Julien Grossholtz [Wed, 10 Feb 2016 17:20:34 +0000 (12:20 -0500)]
gpio: TS-4800: remove useless bgpio_init flags
No flags are required for bgpio_init in the TS-4800 gpio driver. This
patch set zero instead. The driver will have the same behaviour since
the & operator between the flags already resulted to zero.
Linus Walleij [Thu, 11 Feb 2016 10:37:48 +0000 (11:37 +0100)]
gpio: move the subdriver data pointer into gpio_device
We move to manage this pointer under gpiolib control rather than
leave it in the subdevice's gpio_chip. We can not NULL it after
gpiochip_remove so at to keep things tight.
Linus Walleij [Thu, 11 Feb 2016 10:03:06 +0000 (11:03 +0100)]
gpio: move the pin ranges into gpio_device
Instead of keeping this reference to the pin ranges in the
client driver-supplied gpio_chip, move it to the internal
gpio_device as the drivers have no need to inspect this.
Linus Walleij [Fri, 12 Feb 2016 08:22:11 +0000 (09:22 +0100)]
pinctrl: sirf/atlas7: stop poking around in GPIO internals
This code is poking around in the gpio_chip:s internal structures
to achieve some kind of pin to GPIO mappings.
- It is wrong to poke around in these structs and the pinctrl
maintainer was stupid to let it pass unnoticed, mea culpa.
- The right interface to use is gpiochip_add_pin_range()
- The code appears unused: the pin control part of the driver
is not adding any ranges, so we're iterating over an empty
list. Maybe it is poking around in some other pin controllers
GPIO ranges, and that's just totally wrong, again use
gpiochip_add_pin_range() and specify the right pin
controller.
Cc: Barry Song <baohua@kernel.org> Cc: Guoying Zhang <Guoying.Zhang@csr.com> Cc: Wei Chen <Wei.Chen@csr.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
William Breathitt Gray [Wed, 3 Feb 2016 20:17:50 +0000 (15:17 -0500)]
gpio: ws16c48: Use devm_request_region
By the time request_region is called in the WinSystems WS16C48 GPIO
driver, a corresponding device structure has already been allocated. The
devm_request_region function should be used to help simplify the cleanup
code and reduce the possible points of failure.
William Breathitt Gray [Wed, 3 Feb 2016 20:17:40 +0000 (15:17 -0500)]
gpio: sch311x: Use devm_request_region
By the time request_region is called in the SMSC SCH311x GPIO driver, a
corresponding device structure has already been allocated. The
devm_request_region function should be used to help simplify the cleanup
code and reduce the possible points of failure.
William Breathitt Gray [Wed, 3 Feb 2016 20:17:27 +0000 (15:17 -0500)]
gpio: ich: Use devm_request_region
By the time request_region is called in the Intel ICH series GPIO
driver, a corresponding device structure has already been allocated. The
devm_request_region function should be used to help simplify the cleanup
code and reduce the possible points of failure.
Cc: Peter Tyser <ptyser@xes-inc.com> Signed-off-by: William Breathitt Gray <vilhelm.gray@gmail.com> Reviewed-by: Alexandre Courbot <acourbot@nvidia.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
William Breathitt Gray [Wed, 3 Feb 2016 20:17:13 +0000 (15:17 -0500)]
gpio: amd8111: Use devm_request_region
By the time request_region is called in the AMD 8111 GPIO driver, a
corresponding device structure has already been allocated. The
devm_request_region function should be used to help simplify the cleanup
code and reduce the possible points of failure.
William Breathitt Gray [Wed, 3 Feb 2016 20:17:02 +0000 (15:17 -0500)]
gpio: 104-idio-16: Use devm_request_region
By the time request_region is called in the ACCES 104-IDIO-16 GPIO
driver, a corresponding device structure has already been allocated. The
devm_request_region function should be used to help simplify the cleanup
code and reduce the possible points of failure.
William Breathitt Gray [Wed, 3 Feb 2016 20:15:22 +0000 (15:15 -0500)]
gpio: 104-idi-48: Use devm_request_region
By the time request_region is called in the ACCES 104-IDI-48 GPIO
driver, a corresponding device structure has already been allocated. The
devm_request_region function should be used to help simplify the cleanup
code and reduce the possible points of failure.
William Breathitt Gray [Wed, 3 Feb 2016 20:15:21 +0000 (15:15 -0500)]
gpio: 104-dio-48e: Use devm_request_region
By the time request_region is called in the ACCES 104-DIO-48E GPIO
driver, a corresponding device structure has already been allocated. The
devm_request_region function should be used to help simplify the cleanup
code and reduce the possible points of failure.
William Breathitt Gray [Mon, 1 Feb 2016 23:51:49 +0000 (18:51 -0500)]
gpio: misc: Pass correct license string to MODULE_LICENSE
The GPIO driver copyright boilerplate lacks the "or
later" verbiage regarding GPL compliant distribution. The MODULE_LICENSE
string should reflect the actual copyright license terms used.
Signed-off-by: William Breathitt Gray <vilhelm.gray@gmail.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Linus Walleij [Thu, 11 Feb 2016 09:28:44 +0000 (10:28 +0100)]
gpio: reference count the gpio device for each desc
Every time a descriptor is retrieved from the gpiolib, we issue
module_get() to reference count the module supplying the GPIOs.
We also need to call device_get() and device_put() as we also
reference the backing gpio_device when doing this.
Since the sysfs GPIO interface is using gpiod_get() this will
also reference count the sysfs requests until all GPIOs are
unexported.