- 18 Feb, 2016 1 commit
-
-
Josh Cartwright authored
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): kfree kobject_set_name_vargs dev_set_name gpiochip_add_data omap_gpio_probe platform_drv_probe ... Reported-by: Geert Uytterhoeven <geert+renesas@glider.be> Reported-by: Michael Welling <mwelling@ieee.org> Reported-by: Tony Lindgren <tony@atomide.com> Tested-by: Michael Welling <mwelling@ieee.org> Tested-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Josh Cartwright <joshc@ni.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
-
- 16 Feb, 2016 4 commits
-
-
Insu Yun authored
Since devm_kzalloc can be failed in memory pressure, it needs to check and return -ENOMEM Signed-off-by: Insu Yun <wuninsu@gmail.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
-
Axel Lin authored
The .direction_output callback should set proper output level. Signed-off-by: Axel Lin <axel.lin@ingics.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
-
Axel Lin authored
The .direction_output callback should set proper output level. Signed-off-by: Axel Lin <axel.lin@ingics.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
-
Linus Walleij authored
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>
-
- 15 Feb, 2016 15 commits
-
-
Nicholas Krause authored
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 Signed-off-by: Nicholas Krause <xerofoify@gmail.com> Reviewed-by: Alexandre Courbot <acourbot@nvidia.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
-
Bjorn Helgaas authored
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 7563bbf8 ("gpiolib/arches: Centralise bolierplate asm/gpio.h"). Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Acked-by: Thomas Gleixner <tglx@linutronix.de> Acked-by: Arnd Bergmann <arnd@arndb.de> Acked-by: Alexandre Courbot <acourbot@nvidia.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
-
Bjorn Helgaas authored
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 7563bbf8 ("gpiolib/arches: Centralise bolierplate asm/gpio.h"). Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Acked-by: Thomas Gleixner <tglx@linutronix.de> Acked-by: Arnd Bergmann <arnd@arndb.de> Acked-by: Alexandre Courbot <acourbot@nvidia.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
-
Julien Grossholtz authored
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. Fixes: 5041e791 ("gpio: add TS-4800 fpga GPIO support") Signed-off-by: Julien Grossholtz <julien.grossholtz@savoirfairelinux.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
-
Linus Walleij authored
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. Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
-
Linus Walleij authored
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. Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
-
Linus Walleij authored
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 authored
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. 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 authored
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. 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 authored
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 authored
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. 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 authored
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. 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 authored
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. 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 authored
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. 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 authored
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>
-
- 11 Feb, 2016 7 commits
-
-
Linus Walleij authored
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. Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
-
Linus Walleij authored
Some information about the GPIO chip need to stay around also after the gpio_chip has been removed and only the gpio_device persist. The base and ngpio are such things, for example we don't want a new chip arriving to overlap the number space of a dangling gpio_device, and the chardev may still query the device for the number of lines etc. Note that the code that assigns base and insert gpio_device into the global list no longer check for a missing gpio_chip: we respect the number space allocated by any other gpio_device. As a consequence of the gdev being referenced directly from the gpio_desc, we need to verify it differently from all in-kernel API calls that fall through to direct queries to the gpio_chip vtable: we first check that desc is !NULL, then that desc->gdev is !NULL, then, if desc->gdev->chip is NULL, we *BAIL OUT* without any error, so as to manage the case where operations are requested on a device that is gone. These checks were non-uniform and partly missing in the past: so to simplify: create the macros VALIDATE_DESC() that will return -EINVAL if the desc or desc->gdev is missing and just 0 if the chip is gone, and conversely VALIDATE_DESC_VOID() for the case where the function does not return an error. By using these macros, we get warning messages about missing gdev with reference to the right function in the kernel log. Despite the macro business this simplifies the code and make it more readable than if we copy/paste the same descriptor checking code into all code ABI call sites (IMHO). Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
-
Linus Walleij authored
This kind of hacks disturbs the refactoring of the gpiolib. The descriptor table belongs to the gpiolib, if we want to know something about something in it, use or define the proper accessor functions. Let's add this gpiochip_lins_is_irq() to do what the sunxi driver is trying at so we can privatize the descriptors properly. Cc: Maxime Ripard <maxime.ripard@free-electrons.com> Cc: Chen-Yu Tsai <wens@csie.org> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
-
Linus Walleij authored
We need gpio_device to hold the descriptors so that they can be lifecycled with the struct gpio_device held from userspace. Move the descriptor array into gpio_device. Also rename it from "desc" (singularis) to "descs" (pluralis) to reflect the fact that it is an array. Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
-
Linus Walleij authored
Since gpio_device is the struct that survives if the backing gpio_chip is removed, move the sysfs mock device to this state container so it becomes part of the dangling state of the GPIO device on removal. Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
-
Linus Walleij authored
When the device core reference count for the device goes to 0 and it calls .release() we free resources and so can also finally free up the GPIO state container, struct gpio_device. Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
-
Nicolas Saenz Julienne authored
Driver for the GPIO block found in ti's tps65218 pmics. The device has two GPIOs and one GPO pin which can be configured as follows: GPIO1: -general-purpose, open-drain output controlled by GPO1 user bit and/or sequencer -DDR3 reset input signal from SOC. Signal is either latched or passed-trough to GPO2 pin. See below for details. GPO2: -general-purpose output controlled by GPO2 user bit -DDR3 reset output signal. Signal is controlled by GPIO1 and PGOOD. See below for details. -Output buffer can be configured as open-drain or push-pull. GPIO3: -general-purpose, open-drain output controlled by GPO3 user bit and/or sequencer -reset input-signal for DCDC1 and DCDC2. The input configurations are not meant to be used by the user so the driver only offers GPOs. v2: Added request routine that evaluates the fw config flags and removed module owner v3: Added .direction_input() routine, and took care of all Linus Walleij suggestions (clamp to bool, use proper include) Signed-off-by: Nicolas Saenz Julienne <nicolassaenzj@gmail.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
-
- 10 Feb, 2016 7 commits
-
-
Andrew F. Davis authored
Add driver for TI TPIC2810 8-Bit LED Driver with I2C Interface. The TPIC2810 has 8 open-drain outputs that can but used to drive LEDs and other low-side switched resistive loads. Signed-off-by: Andrew F. Davis <afd@ti.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
-
Andrew F. Davis authored
Add generic parallel-in/serial-out shift register GPIO driver. This includes SPI compatible devices like SN74165 serial-out shift registers and the SN65HVS88x series of industrial serializers that can be read over the SPI bus and used for GPI (General Purpose Input). Signed-off-by: Andrew F. Davis <afd@ti.com> Tested-by: Sean Nyekjaer <sean.nyekjaer@prevas.dk> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
-
Alban Bedel authored
Add myself to the copyright list and remove the reference to Atheros' BSP as nothing is left of this code. Signed-off-by: Alban Bedel <albeu@free.fr> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
-
Alban Bedel authored
Add support for the interrupt controller using GPIOLIB_IRQCHIP. Both edges isn't supported by the chip and has to be emulated by switching the polarity on each interrupt. Signed-off-by: Alban Bedel <albeu@free.fr> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
-
Alban Bedel authored
As we now allow the driver to be built as a module it should be removable. Signed-off-by: Alban Bedel <albeu@free.fr> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
-
Alban Bedel authored
To allow building the driver in compile tests we must drop the dependency on asm/mach-ath79/ar71xx_regs.h. For this we replace the include with local definition of the registers needed for this driver. Signed-off-by: Alban Bedel <albeu@free.fr> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
-
Alban Bedel authored
Drop most of the code in favor of the generic MMIO GPIO driver. As the driver now depend on CONFIG_GPIO_GENERIC also add a Kconfig entry to make the driver optional. We leave the base pointer and lock in the data struct because they are needed for the IRQ support. Signed-off-by: Alban Bedel <albeu@free.fr> Acked-by: Alexandre Courbot <acourbot@nvidia.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
-
- 09 Feb, 2016 6 commits
-
-
Linus Walleij authored
-
Linus Walleij authored
This marks the (optional) sysfs GPIO ABI as obsolete and schedules it for removal in 2020. Cc: Johan Hovold <johan@kernel.org> Cc: Michael Welling <mwelling@ieee.org> Cc: Markus Pargmann <mpa@pengutronix.de> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
-
Linus Walleij authored
Put in some documentation for the new character device ABI so we can properly etch it in stone. Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
-
Linus Walleij authored
This creates GPIO tools under tools/gpio/* and adds a single example program to list the GPIOs on a system. When proper devices are created it provides this minimal output: Cc: Johan Hovold <johan@kernel.org> Cc: Michael Welling <mwelling@ieee.org> Cc: Markus Pargmann <mpa@pengutronix.de> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
-
Linus Walleij authored
A new chardev that is to be used for userspace GPIO access is added in this patch. It is intended to gradually replace the horribly broken sysfs ABI. Using a chardev has many upsides: - All operations are per-gpiochip, which is the actual device underlying the GPIOs, making us tie in to the kernel device model properly. - Hotpluggable GPIO controllers can come and go, as this kind of problem has been know to userspace for character devices since ages, and if a gpiochip handle is held in userspace we know we will break something, whereas the sysfs is stateless. - The one-value-per-file rule of sysfs is really hard to maintain when you want to twist more than one knob at a time, for example have in-kernel APIs to switch several GPIO lines at the same time, and this will be possible to do with a single ioctl() from userspace, saving a lot of context switching. We also need to add a new bus type for GPIO. This is necessary for example for userspace coldplug, where sysfs is traversed to find the boot-time device nodes and create the character devices in /dev. This new chardev ABI is *non* *optional* and can be counted on to be present in the future, emphasizing the preference of this ABI. The ABI only implements one single ioctl() to get the name and number of GPIO lines of a chip. Even this is debatable: see it as a minimal example for review. This ABI shall be ruthlessly reviewed and etched in stone. The old /sys/class/gpio is still optional to compile in, but will be deprecated. Unique device IDs are created using IDR, which is overkill and insanely scalable, but also well tested. Cc: Johan Hovold <johan@kernel.org> Cc: Michael Welling <mwelling@ieee.org> Cc: Markus Pargmann <mpa@pengutronix.de> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
-
Linus Walleij authored
We use the new struct device inside gpio_chip to related debug prints and warnings, and we also add it to the debugfs dump. Cc: Johan Hovold <johan@kernel.org> Cc: Michael Welling <mwelling@ieee.org> Cc: Markus Pargmann <mpa@pengutronix.de> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
-