aboutsummaryrefslogtreecommitdiff
path: root/drivers/gpio/gpiolib.c
AgeCommit message (Collapse)Author
2013-03-02gpiolib: move comment to right functionAlexandre Courbot
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>
2013-03-02gpiolib: use const parameters when possibleAlexandre Courbot
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>
2013-03-02gpiolib: check descriptors validity before useAlexandre Courbot
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>
2013-02-27gpio: convert to idr_alloc()Tejun Heo
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>
2013-02-26Merge tag 'gpio-for-linus' of git://git.secretlab.ca/git/linuxLinus Torvalds
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() ...
2013-02-11gpiolib: Fix locking on gpio debugfs filesGrant Likely
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>
2013-02-11gpiolib: let gpio_chip reference its descriptorsAlexandre Courbot
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>
2013-02-11gpiolib: use descriptors internallyAlexandre Courbot
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>
2013-02-09gpiolib: use gpio_chips list in gpiochip_find_baseAlexandre Courbot
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>
2013-02-09gpiolib: use gpio_chips list in sysfs opsAlexandre Courbot
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>
2013-02-09gpiolib: use gpio_chips list in gpiochip_findAlexandre Courbot
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>
2013-02-09gpiolib: use gpio_chips list in gpiolib_sysfs_initAlexandre Courbot
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>
2013-02-09gpiolib: link all gpio_chips using a listAlexandre Courbot
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>
2013-02-06driver-core: constify data for class_find_device()Michał Mirosław
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>
2013-02-04gpiolib: add missing braces in gpio_direction_showAlexandre Courbot
Add missing braces in an if..else condition. Signed-off-by: Alexandre Courbot <acourbot@nvidia.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2013-02-04gpiolib: remove gpiochip_reserve()Alexandre Courbot
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>
2012-12-11Merge tag 'gpio-for-linus' of git://git.secretlab.ca/git/linux-2.6Linus Torvalds
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 ...
2012-11-21gpiolib: Fix use after free in gpiochip_add_pin_rangeAxel Lin
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>
2012-11-21gpiolib: rename pin range argumentsLinus Walleij
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>
2012-11-21gpiolib: return any error code from range creationLinus Walleij
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>
2012-11-21gpiolib: rename find_pinctrl_*Linus Walleij
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>
2012-11-21gpiolib: let gpiochip_add_pin_range() specify offsetLinus Walleij
Like with commit 3c739ad0df5eb41cd7adad879eda6aa09879eb76 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>
2012-11-11gpiolib: separation of pin concernsLinus Walleij
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>
2012-11-11gpiolib: call pin removal in chip removal functionLinus Walleij
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>
2012-11-11gpiolib: fix up function prototypes etcLinus Walleij
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>
2012-11-11gpiolib: provide provision to register pin rangesShiraz Hashim
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>
2012-10-26gpiolib: unlock on error in gpio_export()Dan Carpenter
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>
2012-10-26gpiolib: Don't return -EPROBE_DEFER to sysfs, or for invalid gpiosMathias Nyman
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>
2012-10-26gpiolib: add gpio get direction callback supportMathias Nyman
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>
2012-10-23gpiolib: Refactor gpio_exportRyan Mallon
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>
2012-08-17gpiolib: Use seq_file's iterator interfaceThierry Reding
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>
2012-07-17gpiolib: Defer failed gpio requests by defaultMark Brown
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>
2012-05-18gpiolib: Remove 'const' from data argument of gpiochip_find()Grant Likely
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>
2012-05-18gpiolib: quiet gpiochip_add boot message noiseH Hartley Sweeten
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>
2012-05-18gpio: Adjust of_xlate API to support multiple GPIO chipsGrant Likely
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>
2012-04-05gpio: add flags to export GPIOs when requestingWolfram Sang
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>
2012-03-05gpiolib: Add comments explaining the _cansleep() WARN_ON()sMark Brown
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>
2012-03-05gpio: gpiolib: Support for open source/emitter gpiosLaxman Dewangan
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>
2012-03-05gpio: gpiolib: Support for open drain/collector gpiosLaxman Dewangan
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>
2012-03-02gpio: constify the data parameter to gpiochip_find()Grant Likely
Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
2012-02-15Fix circular locking dependency (3.3-rc2)Ming Lei
Hi, On Wed, Feb 8, 2012 at 8:41 PM, Felipe Balbi <balbi@ti.com> wrote: > Hi guys, > > I have just triggered the folllowing: > > [   84.860321] ====================================================== > [   84.860321] [ INFO: possible circular locking dependency detected ] > [   84.860321] 3.3.0-rc2-00026-ge4e8a39 #474 Not tainted > [   84.860321] ------------------------------------------------------- > [   84.860321] bash/949 is trying to acquire lock: > [   84.860321]  (sysfs_lock){+.+.+.}, at: [<c0275358>] gpio_value_store+0x24/0xcc > [   84.860321] > [   84.860321] but task is already holding lock: > [   84.860321]  (s_active#22){++++.+}, at: [<c016996c>] sysfs_write_file+0xdc/0x184 > [   84.911468] > [   84.911468] which lock already depends on the new lock. > [   84.911468] > [   84.920043] > [   84.920043] the existing dependency chain (in reverse order) is: > [   84.920043] > [   84.927886] -> #1 (s_active#22){++++.+}: > [   84.927886]        [<c008f640>] check_prevs_add+0xdc/0x150 > [   84.927886]        [<c008fc18>] validate_chain.clone.24+0x564/0x694 > [   84.927886]        [<c0090cdc>] __lock_acquire+0x49c/0x980 > [   84.951660]        [<c0091838>] lock_acquire+0x98/0x100 > [   84.951660]        [<c016a8e8>] sysfs_deactivate+0xb0/0x100 > [   84.962982]        [<c016b1b4>] sysfs_addrm_finish+0x2c/0x6c > [   84.962982]        [<c016b8bc>] sysfs_remove_dir+0x84/0x98 > [   84.962982]        [<c02590d8>] kobject_del+0x10/0x78 > [   84.974670]        [<c02c29e8>] device_del+0x140/0x170 > [   84.974670]        [<c02c2a24>] device_unregister+0xc/0x18 > [   84.985382]        [<c0276894>] gpio_unexport+0xbc/0xdc > [   84.985382]        [<c02768c8>] gpio_free+0x14/0xfc > [   85.001708]        [<c0276a28>] unexport_store+0x78/0x8c > [   85.001708]        [<c02c5af8>] class_attr_store+0x18/0x24 > [   85.007293]        [<c0169990>] sysfs_write_file+0x100/0x184 > [   85.018981]        [<c0109d48>] vfs_write+0xb4/0x148 > [   85.018981]        [<c0109fd0>] sys_write+0x40/0x70 > [   85.018981]        [<c0013cc0>] ret_fast_syscall+0x0/0x3c > [   85.035003] > [   85.035003] -> #0 (sysfs_lock){+.+.+.}: > [   85.035003]        [<c008f54c>] check_prev_add+0x680/0x698 > [   85.035003]        [<c008f640>] check_prevs_add+0xdc/0x150 > [   85.052093]        [<c008fc18>] validate_chain.clone.24+0x564/0x694 > [   85.052093]        [<c0090cdc>] __lock_acquire+0x49c/0x980 > [   85.052093]        [<c0091838>] lock_acquire+0x98/0x100 > [   85.069885]        [<c047e280>] mutex_lock_nested+0x3c/0x2f4 > [   85.069885]        [<c0275358>] gpio_value_store+0x24/0xcc > [   85.069885]        [<c02c18dc>] dev_attr_store+0x18/0x24 > [   85.087158]        [<c0169990>] sysfs_write_file+0x100/0x184 > [   85.087158]        [<c0109d48>] vfs_write+0xb4/0x148 > [   85.098297]        [<c0109fd0>] sys_write+0x40/0x70 > [   85.098297]        [<c0013cc0>] ret_fast_syscall+0x0/0x3c > [   85.109069] > [   85.109069] other info that might help us debug this: > [   85.109069] > [   85.117462]  Possible unsafe locking scenario: > [   85.117462] > [   85.117462]        CPU0                    CPU1 > [   85.128417]        ----                    ---- > [   85.128417]   lock(s_active#22); > [   85.128417]                                lock(sysfs_lock); > [   85.128417]                                lock(s_active#22); > [   85.142486]   lock(sysfs_lock); > [   85.151794] > [   85.151794]  *** DEADLOCK *** > [   85.151794] > [   85.151794] 2 locks held by bash/949: > [   85.158020]  #0:  (&buffer->mutex){+.+.+.}, at: [<c01698b8>] sysfs_write_file+0x28/0x184 > [   85.170349]  #1:  (s_active#22){++++.+}, at: [<c016996c>] sysfs_write_file+0xdc/0x184 > [   85.170349] > [   85.178588] stack backtrace: > [   85.178588] [<c001b824>] (unwind_backtrace+0x0/0xf0) from [<c008de64>] (print_circular_bug+0x100/0x114) > [   85.193023] [<c008de64>] (print_circular_bug+0x100/0x114) from [<c008f54c>] (check_prev_add+0x680/0x698) > [   85.193023] [<c008f54c>] (check_prev_add+0x680/0x698) from [<c008f640>] (check_prevs_add+0xdc/0x150) > [   85.212524] [<c008f640>] (check_prevs_add+0xdc/0x150) from [<c008fc18>] (validate_chain.clone.24+0x564/0x694) > [   85.212524] [<c008fc18>] (validate_chain.clone.24+0x564/0x694) from [<c0090cdc>] (__lock_acquire+0x49c/0x980) > [   85.233306] [<c0090cdc>] (__lock_acquire+0x49c/0x980) from [<c0091838>] (lock_acquire+0x98/0x100) > [   85.233306] [<c0091838>] (lock_acquire+0x98/0x100) from [<c047e280>] (mutex_lock_nested+0x3c/0x2f4) > [   85.242614] [<c047e280>] (mutex_lock_nested+0x3c/0x2f4) from [<c0275358>] (gpio_value_store+0x24/0xcc) > [   85.261840] [<c0275358>] (gpio_value_store+0x24/0xcc) from [<c02c18dc>] (dev_attr_store+0x18/0x24) > [   85.261840] [<c02c18dc>] (dev_attr_store+0x18/0x24) from [<c0169990>] (sysfs_write_file+0x100/0x184) > [   85.271240] [<c0169990>] (sysfs_write_file+0x100/0x184) from [<c0109d48>] (vfs_write+0xb4/0x148) > [   85.290008] [<c0109d48>] (vfs_write+0xb4/0x148) from [<c0109fd0>] (sys_write+0x40/0x70) > [   85.298400] [<c0109fd0>] (sys_write+0x40/0x70) from [<c0013cc0>] (ret_fast_syscall+0x0/0x3c) > -bash: echo: write error: Operation not permitted > > the way to trigger is: > > root@legolas:~# cd /sys/class/gpio/ > root@legolas:/sys/class/gpio# echo 2 > export > root@legolas:/sys/class/gpio# echo 2 > unexport > root@legolas:/sys/class/gpio# echo 2 > export > root@legolas:/sys/class/gpio# cd gpio2/ > root@legolas:/sys/class/gpio/gpio2# echo 1 > value Looks 'sysfs_lock' needn't to be held for unregister, so the patch below may fix the problem. Acked-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
2011-12-12gpio/powerpc: Eliminate duplication of of_get_named_gpio_flags()Grant Likely
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>
2011-12-12gpiolib: output basic details and consolidate gpio device driversGrant Likely
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>
2011-05-27gpio: make gpio_{request,free}_array gpio array parameter constLars-Peter Clausen
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>
2011-05-20gpio: add trace events for setting direction and valueUwe Kleine-König
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>
2011-05-20gpiolib: export gpiochip_findJean Delvare
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>
2011-03-25arm/gpio: Remove three copies of broken and racy debug codeThomas Gleixner
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>
2010-12-22gpiolib: gpio_request_one(): add missing gpio_free()Aaro Koskinen
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>
2010-08-11gpiolib: allow nested threaded irqs for poll(2)Daniel Gl?ckner
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>
2010-08-11gpiolib: get rid of struct poll_desc and workletDaniel Gl?ckner
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>
generated by cgit v1.2.3 (git 2.25.1) at 2024-05-24 07:28:47 +0000