- 19 Feb, 2016 21 commits
-
-
Linus Walleij authored
This makes the driver use the data pointer added to the gpio_chip to store a pointer to the state container instead of relying on container_of(). Cc: linux-mips@linux-mips.org Acked-by:
Ralf Baechle <ralf@linux-mips.org> Signed-off-by:
Linus Walleij <linus.walleij@linaro.org>
-
Linus Walleij authored
We're planning to remove the gpiochip_add() function to swith to gpiochip_add_data() with NULL for data argument. Cc: linux-mips@linux-mips.org Acked-by:
-
Linus Walleij authored
This makes the driver use the data pointer added to the gpio_chip to store a pointer to the state container instead of relying on container_of(). Cc: linux-mips@linux-mips.org Acked-by:
-
Linus Walleij authored
We're planning to remove the gpiochip_add() function to swith to gpiochip_add_data() with NULL for data argument. Cc: linux-mips@linux-mips.org Acked-by:
-
Linus Walleij authored
This makes the driver use the data pointer added to the gpio_chip to store a pointer to the state container instead of relying on container_of(). Cc: linux-mips@linux-mips.org Cc: Alban Bedel <albeu@free.fr> Acked-by:
-
Linus Walleij authored
We're planning to remove the gpiochip_add() function to swith to gpiochip_add_data() with NULL for data argument. Cc: linux-mips@linux-mips.org Acked-by:
-
Linus Walleij authored
We're planning to remove the gpiochip_add() function to swith to gpiochip_add_data() with NULL for data argument. Cc: Geert Uytterhoeven <geert@linux-m68k.org> Acked-by:
Greg Ungerer <gerg@uclinux.org> Signed-off-by:
-
Linus Walleij authored
We're planning to remove the gpiochip_add() function to swith to gpiochip_add_data() with NULL for data argument. Cc: Sonic Zhang <sonic.zhang@analog.com> Cc: Steven Miao <realmz6@gmail.com> Cc: adi-buildroot-devel@lists.sourceforge.net Signed-off-by: -
Linus Walleij authored
We're planning to remove the gpiochip_add() function to swith to gpiochip_add_data() with NULL for data argument. Cc: Sonic Zhang <sonic.zhang@analog.com> Cc: Steven Miao <realmz6@gmail.com> Cc: adi-buildroot-devel@lists.sourceforge.net Acked-by:
Sonic Zhang <sonic.zhang@analog.com> Signed-off-by:
-
Linus Walleij authored
This makes the driver use the data pointer added to the gpio_chip to store a pointer to the state container instead of relying on container_of(). Cc: arm@kernel.org Acked-by:
Olof Johansson <olof@lixom.net> Signed-off-by:
-
Linus Walleij authored
This makes the driver use the data pointer added to the gpio_chip to store a pointer to the state container instead of relying on container_of(). Cc: arm@kernel.org Acked-by:
-
Linus Walleij authored
We're planning to remove the gpiochip_add() function to swith to gpiochip_add_data() with NULL for data argument. Cc: arm@kernel.org Acked-by:
-
Linus Walleij authored
We're planning to remove the gpiochip_add() function to swith to gpiochip_add_data() with NULL for data argument. Cc: arm@kernel.org Acked-by:
-
Linus Walleij authored
We're planning to remove the gpiochip_add() function to swith to gpiochip_add_data() with NULL for data argument. Cc: arm@kernel.org Acked-by:
-
Linus Walleij authored
We're planning to remove the gpiochip_add() function to swith to gpiochip_add_data() with NULL for data argument. Cc: arm@kernel.org Acked-by:
-
Linus Walleij authored
We're planning to remove the gpiochip_add() function to swith to gpiochip_add_data() with NULL for data argument. Cc: arm@kernel.org Acked-by:
-
Linus Walleij authored
This makes the driver use the data pointer added to the gpio_chip to store a pointer to the state container instead of relying on container_of(). Cc: arm@kernel.org Cc: Richard Purdie <rpurdie@rpsys.net> Acked-by:
-
Linus Walleij authored
This makes the driver use the data pointer added to the gpio_chip to store a pointer to the state container instead of relying on container_of(). Cc: bcm-kernel-feedback-list@broadcom.com Cc: Scott Branden <sbranden@broadcom.com> Cc: Jon Mason <jonmason@broadcom.com> Acked-by:
Ray Jui <rjui@broadcom.com> Signed-off-by:
-
Linus Walleij authored
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 authored
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. Signed-off-by: -
Linus Walleij authored
Just as it says: after adding the proper interfaces to gpiolib, this is no longer needed. Suggested-by:
Nicolas Saenz Julienne <nicolassaenzj@gmail.com> Signed-off-by:
-
- 18 Feb, 2016 5 commits
-
-
Arnd Bergmann authored
The ARM version of asm/gpio.h basically just contains the same definitions as the gpiolib version, with the exception of ARCH_NR_GPIOS. This adds the option for overriding the constant through Kconfig to the architecture-independent header, so we can remove the ARM specific file later. Signed-off-by:
Arnd Bergmann <arnd@arndb.de> Signed-off-by:
-
Arnd Bergmann authored
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. Signed-off-by:
-
Arnd Bergmann authored
gpiolib has removed the irq_to_gpio() API several years ago, but the global header still provided a non-working stub. To prevent new users of this broken function from showing up, let's remove the stubs as well. Signed-off-by:
-
Ralf Baechle authored
This is fallout from commit 832f5dac ("MIPS: Remove all the uses of custom gpio.h"). Signed-off-by:
Lars-Peter Clausen <lars@metafoo.de>
-
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:
Tony Lindgren <tony@atomide.com> Tested-by:
Josh Cartwright <joshc@ni.com> Signed-off-by:
-
- 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:
-
Axel Lin authored
The .direction_output callback should set proper output level. Signed-off-by:
Axel Lin <axel.lin@ingics.com> Signed-off-by:
-
Axel Lin authored
The .direction_output callback should set proper output level. Signed-off-by:
-
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:
-
- 15 Feb, 2016 10 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:
-
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:
-
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:
-
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 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 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 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: -
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:
-
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 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:
-
