aboutsummaryrefslogtreecommitdiff
path: root/include/linux/gpio/driver.h
AgeCommit message (Collapse)AuthorFilesLines
2016-02-11gpio: move descriptors into gpio_deviceLinus Walleij1-2/+0
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 <[email protected]>
2016-02-11gpio: move sysfs mock device to the gpio_deviceLinus Walleij1-2/+0
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 <[email protected]>
2016-02-09gpio: make the gpiochip a real deviceLinus Walleij1-3/+4
GPIO chips have been around for years, but were never real devices, instead they were piggy-backing on a parent device (such as a platform_device or amba_device) but this was always optional. GPIO chips could also exist without any device at all, with its struct device *parent (ex *dev) pointer being set to null. When sysfs was in use, a mock device would be created, with the optional parent assigned, or just floating orphaned with NULL as parent. If sysfs is active, it will use this device as parent. We now create a gpio_device struct containing a real struct device and move the subsystem over to using that. The list of struct gpio_chip:s is augmented to hold struct gpio_device:s and we find gpio_chips:s by first looking up the struct gpio_device. The struct gpio_device is designed to stay around even if the gpio_chip is removed, so as to satisfy users in userspace that need a backing data structure to hold the state of the session initiated with e.g. a character device even if there is no physical chip anymore. From this point on, gpiochips are devices. Cc: Johan Hovold <[email protected]> Cc: Michael Welling <[email protected]> Cc: Markus Pargmann <[email protected]> Signed-off-by: Linus Walleij <[email protected]>
2016-01-13gpio: generic: make bgpio_pdata always visibleArnd Bergmann1-2/+2
Board files that define their own bgpio_pdata are broken when CONFIG_GPIO_GENERIC is disabled and the bgpio_pdata structure definition is hidden by the #ifdef: arch/arm/mach-clps711x/board-autcpu12.c:148:15: error: variable 'autcpu12_mmgpio_pdata' has initializer but incomplete type static struct bgpio_pdata autcpu12_mmgpio_pdata __initdata = { arch/arm/mach-clps711x/board-autcpu12.c:149:2: error: unknown field 'base' specified in initializer .base = AUTCPU12_MMGPIO_BASE, Since the board files should generally not care what drivers are enabled, this makes the structure definition visible again. Signed-off-by: Arnd Bergmann <[email protected]> Fixes: 0f4630f3720e ("gpio: generic: factor into gpio_chip struct") Signed-off-by: Linus Walleij <[email protected]>
2016-01-05gpio: generic: factor into gpio_chip structLinus Walleij1-0/+54
The separate struct bgpio_chip has been a pain to handle, both by being confusingly similar in name to struct gpio_chip and for being contained inside a struct so that struct gpio_chip is contained in a struct contained in a struct, making several steps of dereferencing necessary. Make things simpler: include the fields directly into <linux/gpio/driver.h>, #ifdef:ed for CONFIG_GENERIC_GPIO, and get rid of the <linux/basic_mmio_gpio.h> altogether. Prefix some of the member variables with bgpio_* and add proper kerneldoc while we're at it. Modify all users to handle the change and use a struct gpio_chip directly. And while we're at it: replace all container_of() dereferencing by gpiochip_get_data() and registering the gpio_chip with gpiochip_add_data(). Cc: [email protected] Cc: Alexander Shiyan <[email protected]> Cc: Shawn Guo <[email protected]> Cc: Sascha Hauer <[email protected]> Cc: Kukjin Kim <[email protected]> Cc: Alexandre Courbot <[email protected]> Cc: Brian Norris <[email protected]> Cc: Florian Fainelli <[email protected]> Cc: Sudeep Holla <[email protected]> Cc: Lorenzo Pieralisi <[email protected]> Cc: Nicolas Pitre <[email protected]> Cc: Olof Johansson <[email protected]> Cc: Vladimir Zapolskiy <[email protected]> Cc: Rabin Vincent <[email protected]> Cc: [email protected] Cc: [email protected] Cc: [email protected] Cc: [email protected] Acked-by: Gregory Fong <[email protected]> Acked-by: Liviu Dudau <[email protected]> Acked-by: H Hartley Sweeten <[email protected]> Acked-by: Tony Lindgren <[email protected]> Acked-by: Krzysztof Kozlowski <[email protected]> Acked-by: Lee Jones <[email protected]> Signed-off-by: Linus Walleij <[email protected]>
2016-01-05gpio: add a data pointer to gpio_chipLinus Walleij1-1/+13
This adds a void * pointer to gpio_chip so that driver can assign and retrieve some states. This is done to get rid of container_of() calls for gpio_chips embedded inside state containers, so we can remove the need to have the gpio_chip or later (planned) struct gpio_device be dynamically allocated at registration time, so that its struct device can be properly reference counted and not bound to its parent device (e.g. a platform_device) but instead live on after unregistration if it is opened by e.g. a char device or sysfs. The data is added with the new function gpiochip_add_data() and for compatibility we add static inline wrapper function gpiochip_add() that will call gpiochip_add_data() with NULL as argument. The latter will be removed once we have exorcised gpiochip_add() from the kernel. gpiochip_get_data() is added as a static inline accessor for drivers to quickly get their data out. Signed-off-by: Linus Walleij <[email protected]>
2015-12-26gpio: update gpiochip .get() callback descriptionVladimir Zapolskiy1-2/+1
Since gpiochip .get() callback may return a negative error value, it strictly limits the range of possible non-error returned values to a subset of [30:0] bitmask, however on practice on success all gpiochip drivers return either 0 for low signal or 1 for high signal, this is assured by "gpio: *: Be sure to clamp return value" series of changes. To avoid any confusion, misinterpretation and potential errors while developing gpiochip drivers in future convert this implicit assumption to a mandatory rule. For output signals with unknown output signal state gpiochip drivers should return a negative error instead of 0. Signed-off-by: Vladimir Zapolskiy <[email protected]> Signed-off-by: Linus Walleij <[email protected]>
2015-11-19gpio: change member .dev to .parentLinus Walleij1-2/+2
The name .dev in a struct is normally reserved for a struct device that is let us say a superclass to the thing described by the struct. struct gpio_chip stands out by confusingly using a struct device *dev to point to the parent device (such as a platform_device) that represents the hardware. As we want to give gpio_chip:s real devices, this is not working. We need to rename this member to parent. This was done by two coccinelle scripts, I guess it is possible to combine them into one, but I don't know such stuff. They look like this: @@ struct gpio_chip *var; @@ -var->dev +var->parent and: @@ struct gpio_chip var; @@ -var.dev +var.parent and: @@ struct bgpio_chip *var; @@ -var->gc.dev +var->gc.parent Plus a few instances of bgpio that I couldn't figure out how to teach Coccinelle to rewrite. This patch hits all over the place, but I *strongly* prefer this solution to any piecemal approaches that just exercise patch mechanics all over the place. It mainly hits drivers/gpio and drivers/pinctrl which is my own backyard anyway. Cc: Haavard Skinnemoen <[email protected]> Cc: Rafał Miłecki <[email protected]> Cc: Richard Purdie <[email protected]> Cc: Mauro Carvalho Chehab <[email protected]> Cc: Alek Du <[email protected]> Cc: Jaroslav Kysela <[email protected]> Cc: Takashi Iwai <[email protected]> Acked-by: Dmitry Torokhov <[email protected]> Acked-by: Greg Kroah-Hartman <[email protected]> Acked-by: Lee Jones <[email protected]> Acked-by: Jiri Kosina <[email protected]> Acked-by: Hans-Christian Egtvedt <[email protected]> Acked-by: Jacek Anaszewski <[email protected]> Signed-off-by: Linus Walleij <[email protected]>
2015-10-16gpiolib: provide generic request/free implementationsJonas Gorski1-0/+3
Provide generic request/free implementations that pinctrl aware gpio drivers can use instead of open coding if they use a 1:1 pin to gpio signal mapping. Signed-off-by: Jonas Gorski <[email protected]> Signed-off-by: Linus Walleij <[email protected]>
2015-08-26gpiolib: add description for gpio irqchip fields in struct gpio_chipGrygorii Strashko1-0/+11
Add missed description for GPIO irqchip fields in struct gpio_chip. Signed-off-by: Grygorii Strashko <[email protected]> Signed-off-by: Linus Walleij <[email protected]>
2015-08-17gpiolib: irqchip: use different lockdep class for each gpio irqchipGrygorii Strashko1-5/+21
Since IRQ chip helpers were introduced drivers lose ability to register separate lockdep classes for each registered GPIO IRQ chip and the gpiolib now is using shared lockdep class for all GPIO IRQ chips (gpiochip_irq_lock_class). As result, lockdep will produce warning when there are min two stacked GPIO chips and all of them are interrupt controllers. HW configuration which generates lockdep warning (TI dra7-evm): [SOC GPIO bankA.gpioX] <- irq - [pcf875x.gpioY] <- irq - DevZ.enable_irq_wake(pcf_gpioY_irq); The issue was reported in [1] and discussed [2]. ============================================= [ INFO: possible recursive locking detected ] 4.2.0-rc6-00013-g5d050ed-dirty #55 Not tainted --------------------------------------------- sh/63 is trying to acquire lock: (class){......}, at: [<c009b91c>] __irq_get_desc_lock+0x50/0x94 but task is already holding lock: (class){......}, at: [<c009b91c>] __irq_get_desc_lock+0x50/0x94 other info that might help us debug this: Possible unsafe locking scenario: CPU0 ---- lock(class); lock(class); *** DEADLOCK *** May be due to missing lock nesting notation 7 locks held by sh/63: #0: (sb_writers#4){.+.+.+}, at: [<c016bbb8>] vfs_write+0x13c/0x164 #1: (&of->mutex){+.+.+.}, at: [<c01debf4>] kernfs_fop_write+0x4c/0x1a0 #2: (s_active#36){.+.+.+}, at: [<c01debfc>] kernfs_fop_write+0x54/0x1a0 #3: (pm_mutex){+.+.+.}, at: [<c009758c>] pm_suspend+0xec/0x4c4 #4: (&dev->mutex){......}, at: [<c03f77f8>] __device_suspend+0xd4/0x398 #5: (&gpio->lock){+.+.+.}, at: [<c009b940>] __irq_get_desc_lock+0x74/0x94 #6: (class){......}, at: [<c009b91c>] __irq_get_desc_lock+0x50/0x94 stack backtrace: CPU: 0 PID: 63 Comm: sh Not tainted 4.2.0-rc6-00013-g5d050ed-dirty #55 Hardware name: Generic DRA74X (Flattened Device Tree) [<c0016e24>] (unwind_backtrace) from [<c0013338>] (show_stack+0x10/0x14) [<c0013338>] (show_stack) from [<c05f6b24>] (dump_stack+0x84/0x9c) [<c05f6b24>] (dump_stack) from [<c00903f4>] (__lock_acquire+0x19c0/0x1e20) [<c00903f4>] (__lock_acquire) from [<c0091098>] (lock_acquire+0xa8/0x128) [<c0091098>] (lock_acquire) from [<c05fd61c>] (_raw_spin_lock_irqsave+0x38/0x4c) [<c05fd61c>] (_raw_spin_lock_irqsave) from [<c009b91c>] (__irq_get_desc_lock+0x50/0x94) [<c009b91c>] (__irq_get_desc_lock) from [<c009c4f4>] (irq_set_irq_wake+0x20/0xfc) [<c009c4f4>] (irq_set_irq_wake) from [<c0393ac4>] (pcf857x_irq_set_wake+0x24/0x54) [<c0393ac4>] (pcf857x_irq_set_wake) from [<c009c560>] (irq_set_irq_wake+0x8c/0xfc) [<c009c560>] (irq_set_irq_wake) from [<c04a02ac>] (gpio_keys_suspend+0x70/0xd4) [<c04a02ac>] (gpio_keys_suspend) from [<c03f6a00>] (dpm_run_callback+0x50/0x124) [<c03f6a00>] (dpm_run_callback) from [<c03f7830>] (__device_suspend+0x10c/0x398) [<c03f7830>] (__device_suspend) from [<c03f90f0>] (dpm_suspend+0x134/0x2f4) [<c03f90f0>] (dpm_suspend) from [<c0096e20>] (suspend_devices_and_enter+0xa8/0x728) [<c0096e20>] (suspend_devices_and_enter) from [<c00977cc>] (pm_suspend+0x32c/0x4c4) [<c00977cc>] (pm_suspend) from [<c0096060>] (state_store+0x64/0xb8) [<c0096060>] (state_store) from [<c01dec64>] (kernfs_fop_write+0xbc/0x1a0) [<c01dec64>] (kernfs_fop_write) from [<c016b280>] (__vfs_write+0x20/0xd8) [<c016b280>] (__vfs_write) from [<c016bb0c>] (vfs_write+0x90/0x164) [<c016bb0c>] (vfs_write) from [<c016c330>] (SyS_write+0x44/0x9c) [<c016c330>] (SyS_write) from [<c000f500>] (ret_fast_syscall+0x0/0x54) Lets fix it by using separate lockdep class for each registered GPIO IRQ Chip. This is done by wrapping gpiochip_irqchip_add call into macros. The implementation of this patch inspired by solution done by Nicolas Boichat for regmap [3] [1] http://www.spinics.net/lists/linux-gpio/msg05844.html [2] http://www.spinics.net/lists/linux-gpio/msg06021.html [3] http://www.spinics.net/lists/arm-kernel/msg429834.html Cc: Geert Uytterhoeven <[email protected]> Cc: Roger Quadros <[email protected]> Reported-by: Roger Quadros <[email protected]> Tested-by: Roger Quadros <[email protected]> Signed-off-by: Grygorii Strashko <[email protected]> Signed-off-by: Linus Walleij <[email protected]>
2015-07-16gpio: Remove double "base" in commentGeert Uytterhoeven1-1/+1
Signed-off-by: Geert Uytterhoeven <[email protected]> Signed-off-by: Linus Walleij <[email protected]>
2015-05-14gpio: discourage passing base to gpio_chipLinus Walleij1-2/+6
Passing a fixed base in struct gpio_chip is done for legacy systems that cannot handle dynamic allocation. Discourage this behaviour in the kerneldoc. Acked-by: Alexandre Courbot <[email protected]> Signed-off-by: Linus Walleij <[email protected]>
2015-05-13gpiolib: cleanup chained handler and dataDmitry Eremin-Solenikov1-0/+1
Clean up chained handler and handler data if they were set by gpiochip_set_chained_irqchip(). Signed-off-by: Dmitry Eremin-Solenikov <[email protected]> Signed-off-by: Linus Walleij <[email protected]>
2015-05-12gpio: sysfs: clean up chip class-device handlingJohan Hovold1-2/+2
Clean gpio-chip class device registration and deregistration. The class device is registered when a gpio-chip is added (or from gpiolib_sysfs_init post-core init call), and deregistered when the chip is removed. Store the class device in struct gpio_chip directly rather than do a class-device lookup on deregistration. This also removes the need for the exported flag. Signed-off-by: Johan Hovold <[email protected]> Reviewed-by: Alexandre Courbot <[email protected]> Signed-off-by: Linus Walleij <[email protected]>
2015-03-19gpio: move pincontrol calls to <linux/gpio/driver.h>Linus Walleij1-0/+48
These functions do not belong in <asm-generic/gpio.h> since the split into separate GPIO headers under <linux/gpio/*>. Move them to <linux/gpio/driver.h> as is apropriate. Acked-by: Alexandre Courbot <[email protected]> Signed-off-by: Linus Walleij <[email protected]>
2014-11-27gpiolib: allow simultaneous setting of multiple GPIO outputsRojhalat Ibrahim1-0/+4
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 <[email protected]> Reviewed-by: Alexandre Courbot <[email protected]> Reviewed-by: Mark Brown <[email protected]> Signed-off-by: Linus Walleij <[email protected]>
2014-10-28gpio: rename gpio_lock_as_irq to gpiochip_lock_as_irqAlexandre Courbot1-2/+2
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 <[email protected]> Signed-off-by: Linus Walleij <[email protected]>
2014-10-09Merge tag 'gpio-v3.18-1' of ↵Linus Torvalds1-2/+6
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 ...
2014-10-07Merge branch 'for-linus' of ↵Linus Torvalds1-2/+2
git://git.kernel.org/pub/scm/linux/kernel/git/jikos/trivial Pull "trivial tree" updates from Jiri Kosina: "Usual pile from trivial tree everyone is so eagerly waiting for" * 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/jikos/trivial: (39 commits) Remove MN10300_PROC_MN2WS0038 mei: fix comments treewide: Fix typos in Kconfig kprobes: update jprobe_example.c for do_fork() change Documentation: change "&" to "and" in Documentation/applying-patches.txt Documentation: remove obsolete pcmcia-cs from Changes Documentation: update links in Changes Documentation: Docbook: Fix generated DocBook/kernel-api.xml score: Remove GENERIC_HAS_IOMAP gpio: fix 'CONFIG_GPIO_IRQCHIP' comments tty: doc: Fix grammar in serial/tty dma-debug: modify check_for_stack output treewide: fix errors in printk genirq: fix reference in devm_request_threaded_irq comment treewide: fix synchronize_rcu() in comments checkstack.pl: port to AArch64 doc: queue-sysfs: minor fixes init/do_mounts: better syntax description MIPS: fix comment spelling powerpc/simpleboot: fix comment ...
2014-09-24gpiolib: add irq_not_threaded flag to gpio_chipOctavian Purdila1-0/+3
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 <[email protected]> Signed-off-by: Linus Walleij <[email protected]>
2014-09-23gpio: gpiolib: set gpiochip_remove retval to voidabdoulaye berthe1-1/+1
This avoids handling gpiochip remove error in device remove handler. Signed-off-by: Abdoulaye Berthe <[email protected]> Signed-off-by: Linus Walleij <[email protected]>
2014-09-05gpio: fix 'CONFIG_GPIO_IRQCHIP' commentsPaul Bolle1-2/+2
These two typos were introduced in commit 1425052097b5 ("gpio: add IRQ chip helpers in gpiolib"). The correct symbol name is CONFIG_GPIOLIB_IRQCHIP. [[email protected]: add changelog] Signed-off-by: Paul Bolle <[email protected]> Signed-off-by: Jiri Kosina <[email protected]>
2014-08-29gpio: change gpiochip_request_own_desc() prototypeAlexandre Courbot1-1/+2
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 <[email protected]> Tested-by: Mika Westerberg <[email protected]> Signed-off-by: Linus Walleij <[email protected]>
2014-07-28gpio: split gpiod board registration into machine headerLinus Walleij1-54/+0
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 <[email protected]> Cc: Nicolas Ferre <[email protected]> Cc: Jean-Christophe Plagniol-Villard <[email protected]> Cc: Ralf Baechle <[email protected]> Cc: Thierry Reding <[email protected]> Acked-by: Stephen Warren <[email protected]> Reviewed-by: Alexandre Courbot <[email protected]> Signed-off-by: Linus Walleij <[email protected]>
2014-07-24gpiolib: Export gpiochip_request_own_desc and gpiochip_free_own_descGuenter Roeck1-0/+3
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 <[email protected]> Reviewed-by: Mika Westerberg <[email protected]> Signed-off-by: Guenter Roeck <[email protected]> Signed-off-by: Linus Walleij <[email protected]>
2014-07-23gpio: remove gpiod_lock/unlock_as_irq()Alexandre Courbot1-2/+2
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 <[email protected]> Signed-off-by: Linus Walleij <[email protected]>
2014-07-23gpio: make gpiochip_get_desc() gpiolib-privateAlexandre Courbot1-3/+0
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 <[email protected]> Signed-off-by: Linus Walleij <[email protected]>
2014-07-23gpio: drop retval check enforcing from gpiochip_remove()Linus Walleij1-1/+1
As we start to decomission the return value from gpiochip_remove() the compilers emit warnings due to the function being tagged __must_check. So drop this until we remove the return value altogether. Cc: Abdoulaye Berthe <[email protected]> Suggested-by: Stephen Rothwell <[email protected]> Signed-off-by: Linus Walleij <[email protected]>
2014-04-28gpio: support threaded interrupts in irqchip helpersLinus Walleij1-1/+4
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 <[email protected]> Signed-off-by: Linus Walleij <[email protected]>
2014-03-28gpio: unmap gpio irqs properlyLinus Walleij1-0/+1
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 <[email protected]>
2014-03-26gpio: add IRQ chip helpers in gpiolibLinus Walleij1-0/+29
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 <[email protected]> Acked-by: Alexandre Courbot <[email protected]> Signed-off-by: Linus Walleij <[email protected]>
2014-02-12gpiolib: add gpiochip_get_desc() driver functionAlexandre Courbot1-0/+18
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 <[email protected]> Reviewed-by: Mika Westerberg <[email protected]> Reviewed-by: Jean-Jacques Hiblot <[email protected]> Signed-off-by: Linus Walleij <[email protected]>
2013-12-09gpiolib: convert gpiod_lookup description to kernel-docAndy Shevchenko1-17/+9
The patch moves description of the fields to the top of struct definition and converts them to the kernel-doc format. There is no functional change. Signed-off-by: Andy Shevchenko <[email protected]> Acked-by: Alexandre Courbot <[email protected]> Reviewed-by: Mika Westerberg <[email protected]> Signed-off-by: Linus Walleij <[email protected]>
2013-12-09gpio: better lookup method for platform GPIOsAlexandre Courbot1-11/+10
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 <[email protected]> Acked-by: Mika Westerberg <[email protected]> Reviewed-by: Andy Shevchenko <[email protected]> Signed-off-by: Linus Walleij <[email protected]>
2013-12-09Merge tag 'v3.13-rc3' into develLinus Walleij1-2/+12
Linux 3.13-rc3
2013-12-04gpio/pinctrl: make gpio_chip members typed booleanLinus Walleij1-4/+5
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 <[email protected]>
2013-12-03gpiolib: add missing declarationsAlexandre Courbot1-0/+3
Add declaration of 'struct of_phandle_args' to avoid the following warning: In file included from arch/arm/mach-tegra/board-paz00.c:21:0: include/linux/gpio/driver.h:102:17: warning: 'struct of_phandle_args' declared inside parameter list include/linux/gpio/driver.h:102:17: warning: its scope is only this definition or declaration, which is probably not what you want Also proactively add other definitions/includes that could be missing in other contexts. Signed-off-by: Alexandre Courbot <[email protected]> Reported-by: Stephen Warren <[email protected]> Reviewed-by: Mika Westerberg <[email protected]> Signed-off-by: Linus Walleij <[email protected]>
2013-11-25gpiolib: use dedicated flags for GPIO propertiesAlexandre Courbot1-2/+9
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 <[email protected]> Signed-off-by: Linus Walleij <[email protected]>
2013-10-29gpiolib: provide a declaration of seq_file in gpio/driver.hStephen Rothwell1-0/+1
Fixes this build error: In file included from include/asm-generic/gpio.h:13:0, from include/linux/gpio.h:51, from include/linux/of_gpio.h:20, from arch/powerpc/sysdev/ppc4xx_gpio.c:29: include/linux/gpio/driver.h:85:14: error: 'struct seq_file' declared inside= parameter list [-Werror] include/linux/gpio/driver.h:85:14: error: its scope is only this definition= or declaration, which is probably not what you want [-Werror] Signed-off-by: Stephen Rothwell <[email protected]> Signed-off-by: Linus Walleij <[email protected]>
2013-10-19gpiolib: add gpiod_get() and gpiod_put() functionsAlexandre Courbot1-0/+56
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 <[email protected]> Signed-off-by: Linus Walleij <[email protected]>
2013-10-19gpiolib: export descriptor-based GPIO interfaceAlexandre Courbot1-0/+127
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 <[email protected]> Signed-off-by: Linus Walleij <[email protected]>