aboutsummaryrefslogtreecommitdiffstats
path: root/drivers/gpio/gpiolib-of.c (follow)
AgeCommit message (Collapse)AuthorFilesLines
2018-12-17gpio/mmc/of: Respect polarity in the device treeLinus Walleij1-33/+16
The device tree bindings for the MMC card detect and write protect lines specify that these should be active low unless "cd-inverted" or "wp-inverted" has been specified. However that is not how the kernel code has worked. It has always respected the flags passed to the phandle in the device tree, but respected the "cd-inverted" and "wp-inverted" flags such that if those are set, the polarity will be the inverse of that specified in the device tree. Switch to behaving like the old code did and fix the regression. Fixes: 81c85ec15a19 ("gpio: OF: Parse MMC-specific CD and WP properties") Cc: Bartosz Golaszewski <bgolaszewski@baylibre.com> Cc: Guenter Roeck <linux@roeck-us.net> Reported-by: Guenter Roeck <linux@roeck-us.net> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2018-11-29gpio: OF: Parse MMC-specific CD and WP propertiesLinus Walleij1-0/+39
When retrieveing CD (card detect) and WP (write protect) GPIO handles from the device tree, make sure to assign them active low by default unless the "cd-inverted" or "wp-inverted" properties are set. These properties mean that respective signal is active HIGH since the SDHCI specification stipulates that this kind of signals should be treated as active LOW. If the twocell GPIO flag is also specified as active low, well that's nice and we will silently ignore the tautological specification. If however the GPIO line is specified as active low in the GPIO flasg cell and "cd-inverted" or "wp-inverted" is also specified, the latter takes precedence and we print a warning. The current effect on the MMC slot-gpio core are as follows: For CD GPIOs: no effect. The current code in mmc/core/host.c calls mmc_gpiod_request_cd() with the "override_active_level" argument set to true, which means that whatever the GPIO descriptor thinks about active low/high will be ignored, the core will use the MMC_CAP2_CD_ACTIVE_HIGH to keep track of this and reads the raw value from the GPIO descriptor, totally bypassing gpiolibs inversion semantics. I plan to clean this up at a later point passing the handling of inversion semantics over to gpiolib, so this patch prepares the ground for that. Fow WP GPIOs: this is probably fixing a bug, because the code in mmc/core/host.c calls mmc_gpiod_request_ro() with the "override_active_level" argument set to false, which means it will respect the inversion semantics of the gpiolib and ignore the MMC_CAP2_RO_ACTIVE_HIGH flag for everyone using this through device tree. However the code in host.c confusingly goes to great lengths setting up the MMC_CAP2_RO_ACTIVE_HIGH flag from the GPIO descriptor and by reading the "wp-inverted" property of the node. As far as I can tell this is all in vain and the inversion is broken: device trees that use "wp-inverted" do not work as intended, instead the only way to actually get inversion on a line is by setting the second cell flag to GPIO_ACTIVE_HIGH (which will be the default) or GPIO_ACTIVE_LOW if they want the proper MMC semantics. Presumably all device trees do this right but we need to parse and handle this properly. Cc: linux-mmc@vger.kernel.org Cc: linux-gpio@vger.kernel.org Cc: Bartosz Golaszewski <bgolaszewski@baylibre.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2018-11-26gpio: restore original GPLv2+ license of gpiolib-of.c sourcesVladimir Zapolskiy1-1/+1
It's easy to verify that the change of drivers/gpio/gpiolib-of.c license header to SPDX standard changes the license from GPLv2+ to GPLv2, and this change corrects it. Fixes: dae5f0afcfc3 ("gpio: Use SPDX header for core library") Signed-off-by: Vladimir Zapolskiy <vz@mleia.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2018-10-23Merge tag 'gpio-v4.20-1' of git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-gpioLinus Torvalds1-9/+51
Pull GPIO updates from Linus Walleij: "This is the bulk of GPIO changes for the v4.20 series: Core changes: - A patch series from Hans Verkuil to make it possible to enable/disable IRQs on a GPIO line at runtime and drive GPIO lines as output without having to put/get them from scratch. The irqchip callbacks have been improved so that they can use only the fastpatch callbacks to enable/disable irqs like any normal irqchip, especially the gpiod_lock_as_irq() has been improved to be callable in fastpath context. A bunch of rework had to be done to achieve this but it is a big win since I never liked to restrict this to slowpath. The only call requireing slowpath was try_module_get() and this is kept at the .request_resources() slowpath callback. In the GPIO CEC driver this is a big win sine a single line is used for both outgoing and incoming traffic, and this needs to use IRQs for incoming traffic while actively driving the line for outgoing traffic. - Janusz Krzysztofik improved the GPIO array API to pass a "cookie" (struct gpio_array) and a bitmap for setting or getting multiple GPIO lines at once. This improvement orginated in a specific need to speed up an OMAP1 driver and has led to a much better API and real performance gains when the state of the array can be used to bypass a lot of checks and code when we want things to go really fast. The previous code would minimize the number of calls down to the driver callbacks assuming the CPU speed was orders of magnitude faster than the I/O latency, but this assumption was wrong on several platforms: what we needed to do was to profile and improve the speed on the hot path of the array functions and this change is now completed. - Clean out the painful and hard to grasp BNF experiments from the device tree bindings. Future approaches are looking into using JSON schema for this purpose. (Rob Herring is floating a patch series.) New drivers: - The RCAR driver now supports r8a774a1 (RZ/G2M). - Synopsys GPIO via CREGs driver. Major improvements: - Modernization of the EP93xx driver to use irqdomain and other contemporary concepts. - The ingenic driver has been merged into the Ingenic pin control driver and removed from the GPIO subsystem. - Debounce support in the ftgpio010 driver" * tag 'gpio-v4.20-1' of git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-gpio: (116 commits) gpio: Clarify kerneldoc on gpiochip_set_chained_irqchip() gpio: Remove unused 'irqchip' argument to gpiochip_set_cascaded_irqchip() gpio: Drop parent irq assignment during cascade setup mmc: pwrseq_simple: Fix incorrect handling of GPIO bitmap gpio: fix SNPS_CREG kconfig dependency warning gpiolib: Initialize gdev field before is used gpio: fix kernel-doc after devres.c file rename gpio: fix doc string for devm_gpiochip_add_data() to not talk about irq_chip gpio: syscon: Fix possible NULL ptr usage gpiolib: Show correct direction from the beginning pinctrl: msm: Use init_valid_mask exported function gpiolib: Add init_valid_mask exported function GPIO: add single-register GPIO via CREG driver dt-bindings: Document the Synopsys GPIO via CREG bindings gpio: mockup: use device properties instead of platform_data gpio: Slightly more helpful debugfs gpio: omap: Remove set but not used variable 'dev' gpio: omap: drop omap_gpio_list Accept partial 'gpio-line-names' property. gpio: omap: get rid of the conditional PM runtime calls ...
2018-09-25gpio: Use SPDX header for core libraryLinus Walleij1-5/+1
Use the SPDX headers and cut down on boilerplate to indicate the license in the core gpiolib implementation. Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2018-09-11gpio: of: Handle SPI chipselect legacy bindingsLinus Walleij1-2/+48
The SPI chipselects are assumed to be active low in the current binding, so when we want to use GPIO descriptors and handle the active low/high semantics in gpiolib, we need a special parsing quirk to deal with this. We check for the property "spi-cs-high" and if that is NOT present we assume the CS line is active low. If the line is tagged as active low in the device tree and has no "spi-cs-high" property all is fine, the device tree and the SPI bindings are in agreement. If the line is tagged as active high in the device tree with the second cell flag and has no "spi-cs-high" property we enforce active low semantics (as this is the exception we can just tag on the flag). If the line is tagged as active low with the second cell flag AND tagged with "spi-cs-high" the SPI active high property takes precedence and we print a warning. Cc: Mark Brown <broonie@kernel.org> Cc: linux-spi@vger.kernel.org Cc: Geert Uytterhoeven <geert@linux-m68k.org> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2018-08-31gpio: Fix crash due to registration raceVincent Whitchurch1-0/+1
gpiochip_add_data_with_key() adds the gpiochip to the gpio_devices list before of_gpiochip_add() is called, but it's only the latter which sets the ->of_xlate function pointer. gpiochip_find() can be called by someone else between these two actions, and it can find the chip and call of_gpiochip_match_node_and_xlate() which leads to the following crash due to a NULL ->of_xlate(). Unhandled prefetch abort: page domain fault (0x01b) at 0x00000000 Modules linked in: leds_gpio(+) gpio_generic(+) CPU: 0 PID: 830 Comm: insmod Not tainted 4.18.0+ #43 Hardware name: ARM-Versatile Express PC is at (null) LR is at of_gpiochip_match_node_and_xlate+0x2c/0x38 Process insmod (pid: 830, stack limit = 0x(ptrval)) (of_gpiochip_match_node_and_xlate) from (gpiochip_find+0x48/0x84) (gpiochip_find) from (of_get_named_gpiod_flags+0xa8/0x238) (of_get_named_gpiod_flags) from (gpiod_get_from_of_node+0x2c/0xc8) (gpiod_get_from_of_node) from (devm_fwnode_get_index_gpiod_from_child+0xb8/0x144) (devm_fwnode_get_index_gpiod_from_child) from (gpio_led_probe+0x208/0x3c4 [leds_gpio]) (gpio_led_probe [leds_gpio]) from (platform_drv_probe+0x48/0x9c) (platform_drv_probe) from (really_probe+0x1d0/0x3d4) (really_probe) from (driver_probe_device+0x78/0x1c0) (driver_probe_device) from (__driver_attach+0x120/0x13c) (__driver_attach) from (bus_for_each_dev+0x68/0xb4) (bus_for_each_dev) from (bus_add_driver+0x1a8/0x268) (bus_add_driver) from (driver_register+0x78/0x10c) (driver_register) from (do_one_initcall+0x54/0x1fc) (do_one_initcall) from (do_init_module+0x64/0x1f4) (do_init_module) from (load_module+0x2198/0x26ac) (load_module) from (sys_finit_module+0xe0/0x110) (sys_finit_module) from (ret_fast_syscall+0x0/0x54) One way to fix this would be to rework the hairy registration sequence in gpiochip_add_data_with_key(), but since I'd probably introduce a couple of new bugs if I attempted that, simply add a check for a non-NULL of_xlate function pointer in of_gpiochip_match_node_and_xlate(). This works since the driver looking for the gpio will simply fail to find the gpio and defer its probe and be reprobed when the driver which is registering the gpiochip has fully completed its probe. Signed-off-by: Vincent Whitchurch <vincent.whitchurch@axis.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2018-08-29gpio: Convert to using %pOFn instead of device_node.nameRob Herring1-2/+2
In preparation to remove the node name pointer from struct device_node, convert printf users to use the %pOFn format specifier. Cc: Linus Walleij <linus.walleij@linaro.org> Cc: linux-gpio@vger.kernel.org Signed-off-by: Rob Herring <robh@kernel.org> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2018-08-15Merge tag 'gpio-v4.19-1' of git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-gpioLinus Torvalds1-3/+0
Pull GPIO updates from Linus Walleij: "This is the bulk of GPIO changes for the v4.19 kernel cycle. I don't know if anything in particular stands out. Maybe the Aspeed coprocessor thing from Benji: Aspeed is doing baseboard management chips (BMC's) for servers etc. These Aspeed's are ARM processors that exist inside (I guess) Intel servers, and they are moving forward to using mainline Linux in those. This is one of the pieces of the puzzle to achive that. They are doing OpenBMC, it's pretty cool: https://lwn.net/Articles/683320/ Summary: Core changes: - Add a new API for explicitly naming GPIO consumers, when needed. - Don't let userspace set values on input lines. While we do not think anyone would do this crazy thing we better plug the hole before someone uses it and think it's a nifty feature. - Avoid calling chip->request() for unused GPIOs. New drivers/subdrivers: - The Mediatek MT7621 is supported which is a big win for OpenWRT and similar router distributions using this chip, as it seems every major router manufacturer on the planet has made products using this chip: https://wikidevi.com/wiki/MediaTek_MT7621 - The Tegra 194 is now supported. - The IT87 driver now supports IT8786E and IT8718F super-IO chips. - Add support for Rockchip RK3328 in the syscon GPIO driver. Driver changes: - Handle the get/set_multiple() properly on MMIO chips with inverted direction registers. We didn't have this problem until a new chip appear that has get/set registers AND inverted direction bits, OK now we handle it. - A patch series making more error codes percolate upward properly for different errors on gpiochip_lock_as_irq(). - Get/set multiple for the OMAP driver, accelerating these multiple line operations if possible. - A coprocessor interface for the Aspeed driver. Sometimes a few GPIO lines need to be grabbed by a co-processor for doing automated tasks, sometimes they are available as GPIO lines. By adding an explicit API in this driver we make it possible for the two line consumers to coexist. (This work was made available on the ib-aspeed branch, which may be appearing in other pull requests.) - Implemented .get_direction() and open drain in the SCH311x driver. - Continuing cleanup of included headers in GPIO drivers" * tag 'gpio-v4.19-1' of git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-gpio: (80 commits) gpio: it87: Add support for IT8613 gpio: it87: add support for IT8718F Super I/O. gpiolib: Avoid calling chip->request() for unused gpios gpio: tegra: Include the right header gpio: mmio: Fix up inverted direction registers gpio: xilinx: Use the right include gpio: timberdale: Include the right header gpio: tb10x: Use the right include gpiolib: Fix of_node inconsistency gpio: vr41xx: Bail out on gpiochip_lock_as_irq() error gpio: uniphier: Bail out on gpiochip_lock_as_irq() error gpio: xgene-sb: Don't shadow error code of gpiochip_lock_as_irq() gpio: em: Don't shadow error code of gpiochip_lock_as_irq() gpio: dwapb: Don't shadow error code of gpiochip_lock_as_irq() gpio: bcm-kona: Don't shadow error code of gpiochip_lock_as_irq() gpiolib: Don't shadow error code of gpiochip_lock_as_irq() gpio: syscon: rockchip: add GRF GPIO support for rk3328 gpio: omap: Add get/set_multiple() callbacks gpio: pxa: remove set but not used variable 'gpio_offset' gpio-it87: add support for IT8786E Super I/O ...
2018-08-10gpiolib: Fix of_node inconsistencyBiju Das1-3/+0
Some platforms are not setting of_node in the driver. On these platforms defining gpio-reserved-ranges on device tree leads to kernel crash. It is due to some parts of the gpio core relying on the driver to set up of_node,while other parts do themselves.This inconsistent behaviour leads to a crash. gpiochip_add_data_with_key() calls gpiochip_init_valid_mask() with of_node as NULL. of_gpiochip_add() fills "of_node" and calls of_gpiochip_init_valid_mask(). The fix is to move the assignment to chip->of_node from of_gpiochip_add() to gpiochip_add_data_with_key(). Signed-off-by: Biju Das <biju.das@bp.renesas.com> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be> Tested-by: Geert Uytterhoeven <geert+renesas@glider.be> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2018-07-23gpio: of: Handle fixed regulator flags properlyLinus Walleij1-1/+2
This fixes up the handling of fixed regulator polarity inversion flags: while I remembered to fix it for the undocumented "reg-fixed-voltage" I forgot about the official "regulator-fixed" binding, there are two ways to do a fixed regulator. The error was noticed and fixed. Fixes: a603a2b8d86e ("gpio: of: Add special quirk to parse regulator flags") Cc: Mark Brown <broonie@kernel.org> Cc: Thierry Reding <thierry.reding@gmail.com> Reported-by: Thierry Reding <thierry.reding@gmail.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2018-05-16gpio: Convert to use match_string() helperAndy Shevchenko1-5/+2
The new helper returns index of the matching string in an array. We are going to use it here. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2018-04-05Merge tag 'devicetree-for-4.17' of git://git.kernel.org/pub/scm/linux/kernel/git/robh/linuxLinus Torvalds1-2/+2
Pull DeviceTree updates from Rob Herring: - Sync dtc to upstream version v1.4.6-9-gaadd0b65c987. This adds a bunch more warnings (hidden behind W=1). - Build dtc lexer and parser files instead of using shipped versions. - Rework overlay apply API to take an FDT as input and apply overlays in a single step. - Add a phandle lookup cache. This improves boot time by hundreds of msec on systems with large DT. - Add trivial mcp4017/18/19 potentiometers bindings. - Remove VLA stack usage in DT code. * tag 'devicetree-for-4.17' of git://git.kernel.org/pub/scm/linux/kernel/git/robh/linux: (26 commits) of: unittest: fix an error code in of_unittest_apply_overlay() of: unittest: move misplaced function declaration of: unittest: Remove VLA stack usage of: overlay: Fix forgotten reference to of_overlay_apply() of: Documentation: Fix forgotten reference to of_overlay_apply() of: unittest: local return value variable related cleanups of: unittest: remove unneeded local return value variables dt-bindings: trivial: add various mcp4017/18/19 potentiometers of: unittest: fix an error test in of_unittest_overlay_8() of: cache phandle nodes to reduce cost of of_find_node_by_phandle() dt-bindings: rockchip-dw-mshc: use consistent clock names MAINTAINERS: Add linux/of_*.h headers to appropriate subsystems scripts: turn off some new dtc warnings by default scripts/dtc: Update to upstream version v1.4.6-9-gaadd0b65c987 scripts/dtc: generate lexer and parser during build instead of shipping powerpc: boot: add strrchr function of: overlay: do not include path in full_name of added nodes of: unittest: clean up changeset test arm64/efi: Make strrchr() available to the EFI namespace ARM: boot: add strrchr function ...
2018-03-27gpiolib: Support 'gpio-reserved-ranges' propertyStephen Boyd1-0/+24
Some qcom platforms make some GPIOs or pins unavailable for use by non-secure operating systems, and thus reading or writing the registers for those pins will cause access control issues. Add support for a DT property to describe the set of GPIOs that are available for use so that higher level OSes are able to know what pins to avoid reading/writing. Non-DT platforms can add support by directly updating the chip->valid_mask. Signed-off-by: Stephen Boyd <sboyd@codeaurora.org> Signed-off-by: Stephen Boyd <swboyd@chromium.org> Tested-by: Timur Tabi <timur@codeaurora.org> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2018-02-27gpio: Handle deferred probing in of_find_gpio() properlyChen-Yu Tsai1-1/+1
of_get_named_gpiod_flags() used directly in of_find_gpio() or indirectly through of_find_spi_gpio() or of_find_regulator_gpio() can return -EPROBE_DEFER. This gets overwritten by the subsequent of_find_*_gpio() calls. This patch fixes this by trying of_find_spi_gpio() or of_find_regulator_gpio() only if deferred probing was not requested by the previous of_get_named_gpiod_flags() call. Fixes: 6a537d48461d ("gpio: of: Support regulator nonstandard GPIO properties") Fixes: c85823390215 ("gpio: of: Support SPI nonstandard GPIO properties") Signed-off-by: Chen-Yu Tsai <wens@csie.org> [Augmented to fit with Maxime's patch] Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2018-02-27gpiolib: Keep returning EPROBE_DEFER when we shouldMaxime Ripard1-0/+13
Commits c85823390215 ("gpio: of: Support SPI nonstandard GPIO properties") and 6a537d48461d ("gpio: of: Support regulator nonstandard GPIO properties") have introduced a regression in the way error codes from of_get_named_gpiod_flags are handled. Previously, those errors codes were returned immediately, but the two commits mentioned above are now overwriting the error pointer, meaning that whatever value has been returned will be dropped in favor of whatever the two new functions will return. This might not be a big deal except for EPROBE_DEFER, on which GPIOlib customers will depend on, and that will now be returned as an hard error which means that they will not probe anymore, instead of gently deferring their probe. Since EPROBE_DEFER basically means that we have found a valid property but there was no GPIO controller registered to handle it, fix this issues by returning it as soon as we encounter it. Fixes: c85823390215 ("gpio: of: Support SPI nonstandard GPIO properties") Fixes: 6a537d48461d ("gpio: of: Support regulator nonstandard GPIO properties") Signed-off-by: Maxime Ripard <maxime.ripard@bootlin.com> [Fold in fix to the fix] Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2018-02-12gpio: Support gpio nexus dt bindingsStephen Boyd1-2/+2
Platforms like 96boards have a standardized connector/expansion slot that exposes signals like GPIOs to expansion boards in an SoC agnostic way. We'd like the DT overlays for the expansion boards to be written once without knowledge of the SoC on the other side of the connector. This avoids the unscalable combinatorial explosion of a different DT overlay for each expansion board and SoC pair. Now that we have nexus support in the OF core let's change the function call here that parses the phandle lists of gpios to use the nexus variant. This allows us to remap phandles and their arguments through any number of nexus nodes and end up with the actual gpio provider being used. Cc: Pantelis Antoniou <pantelis.antoniou@konsulko.com> Acked-by: Linus Walleij <linus.walleij@linaro.org> Cc: Mark Brown <broonie@kernel.org> Signed-off-by: Stephen Boyd <stephen.boyd@linaro.org> Signed-off-by: Rob Herring <robh@kernel.org>
2018-01-31Merge tag 'gpio-v4.16-1' of git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-gpioLinus Torvalds1-2/+117
Pull GPIO updates from Linus Walleij: "The is the bulk of GPIO changes for the v4.16 kernel cycle. It is pretty calm this time around I think. I even got time to get to things like starting to clean up header includes. Core changes: - Disallow open drain and open source flags to be set simultaneously. This doesn't make electrical sense, and would the hardware actually respond to this setting, the result would be short circuit. - ACPI GPIO has a new core infrastructure for handling quirks. The quirks are there to deal with broken ACPI tables centrally instead of pushing the work to individual drivers. In the world of BIOS writers, the ACPI tables are perfect. Until they find a mistake in it. When such a mistake is found, we can patch it with a quirk. It should never happen, the problem is that it happens. So we accomodate for it. - Several documentation updates. - Revert the patch setting up initial direction state from reading the device. This was causing bad things for drivers that can't read status on all its pins. It is only affecting debugfs information quality. - Label descriptors with the device name if no explicit label is passed in. - Pave the ground for transitioning SPI and regulators to use GPIO descriptors by implementing some quirks in the device tree GPIO parsing code. New drivers: - New driver for the Access PCIe IDIO 24 family. Other: - Major refactorings and improvements to the GPIO mockup driver used for test and verification. - Moved the AXP209 driver over to pin control since it gained a pin control back-end. These patches will appear (with the same hashes) in the pin control pull request as well. - Convert the onewire GPIO driver w1-gpio to use descriptors. This is merged here since the W1 maintainers send very few pull requests and he ACKed it. - Start to clean up driver headers using <linux/gpio.h> to just use <linux/gpio/driver.h> as appropriate" * tag 'gpio-v4.16-1' of git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-gpio: (103 commits) gpio: Timestamp events in hardirq handler gpio: Fix kernel stack leak to userspace gpio: Fix a documentation spelling mistake gpio: Documentation update gpiolib: remove redundant initialization of pointer desc gpio: of: Fix NPE from OF flags gpio: stmpe: Delete an unnecessary variable initialisation in stmpe_gpio_probe() gpio: stmpe: Move an assignment in stmpe_gpio_probe() gpio: stmpe: Improve a size determination in stmpe_gpio_probe() gpio: stmpe: Use seq_putc() in stmpe_dbg_show() gpio: No NULL owner gpio: stmpe: i2c transfer are forbiden in atomic context gpio: davinci: Include proper header gpio: da905x: Include proper header gpio: cs5535: Include proper header gpio: crystalcove: Include proper header gpio: bt8xx: Include proper header gpio: bcm-kona: Include proper header gpio: arizona: Include proper header gpio: amd8111: Include proper header ...
2018-01-17gpio: of: Fix NPE from OF flagsLinus Walleij1-1/+2
Some calls to of_get_named_gpio() calls sets the flags argument to NULL because they are not interested in the flags. This caused a null pointer exception since we were unconditionally using these flags. Fix it. Fixes: 6a537d48461d ("gpio: of: Support regulator nonstandard GPIO properties") Cc: Heiner Kallweit <hkallweit1@gmail.com> Reported-by: Heiner Kallweit <hkallweit1@gmail.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2018-01-12gpio: of: Add special quirk to parse regulator flagsLinus Walleij1-0/+38
While most GPIOs are indicated to be active low or open drain using their twocell flags, we have legacy regulator bindings to take into account. Add a quirk respecting the special boolean active-high and open drain flags when parsing regulator nodes for GPIOs. This makes it possible to get rid of duplicated inversion semantics handling in the regulator core and any regulator drivers parsing and handling this separately. Unfortunately the old regulator inversion semantics are specified such that the presence or absence of "enable-active-high" solely controls the semantics, so we cannot deprecate this in favor of the phandle-provided inversion flag, instead any such phandle inversion flag provided in the second cell of a GPIO handle must be actively ignored, so we print a warning to contain the situation and make things easy for the users. Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2018-01-12gpio: of: Support regulator nonstandard GPIO propertiesLinus Walleij1-0/+39
Before it was clearly established that all GPIO properties in the device tree shall be named "foo-gpios" (with the deprecated variant "foo-gpio" for single lines) we unfortunately merged a few bindings for regulators with random phandle names. As we want to switch the GPIO regulator driver to using descriptors, we need devm_gpiod_get() to return something reasonable when looking up these in the device tree. Put in a special #ifdef:ed kludge to do this special lookup only for the regulator case and gets compiled out if we're not enabling regulators. Supply a whitelist with properties we accept. Cc: Rob Herring <robh@kernel.org> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2018-01-08gpio: of: Support SPI nonstandard GPIO propertiesLinus Walleij1-0/+35
Before it was clearly established that all GPIO properties in the device tree shall be named "foo-gpios" (with the deprecated variant "foo-gpio" for single lines) we unfortunately merged a few bindings which named the lines "gpio-foo" instead. This is most prominent in the GPIO SPI driver in Linux which names the lines "gpio-sck", "gpio-mosi" and "gpio-miso". As we want to switch the GPIO SPI driver to using descriptors, we need devm_gpiod_get() to return something reasonable when looking up these in the device tree. Put in a special #ifdef:ed kludge to do this special lookup only for the SPI case and gets compiled out if we're not enabling SPI. If we have more oddly defined legacy GPIOs like this, they can be handled in a similar manner. Reviewed-by: Rob Herring <robh@kernel.org> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2017-12-22gpio: fix "gpio-line-names" property retrievalChristophe Leroy1-1/+2
Following commit 9427ecbed46cc ("gpio: Rework of_gpiochip_set_names() to use device property accessors"), "gpio-line-names" DT property is not retrieved anymore when chip->parent is not set by the driver. This is due to OF based property reads having been replaced by device based property reads. This patch fixes that by making use of fwnode_property_read_string_array() instead of device_property_read_string_array() and handing over either of_fwnode_handle(chip->of_node) or dev_fwnode(chip->parent) to that function. Fixes: 9427ecbed46cc ("gpio: Rework of_gpiochip_set_names() to use device property accessors") Cc: stable@vger.kernel.org Signed-off-by: Christophe Leroy <christophe.leroy@c-s.fr> Acked-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2017-12-02gpio: gpiolib: Generalise state persistence beyond sleepAndrew Jeffery1-2/+4
General support for state persistence is added to gpiolib with the introduction of a new pinconf parameter to propagate the request to hardware. The existing persistence support for sleep is adapted to include hardware support if the GPIO driver provides it. Persistence continues to be enabled by default; in-kernel consumers can opt out, but userspace (currently) does not have a choice. The *_SLEEP_MAY_LOSE_VALUE and *_SLEEP_MAINTAIN_VALUE symbols are renamed, dropping the SLEEP prefix to reflect that the concept is no longer sleep-specific. I feel that renaming to just *_MAY_LOSE_VALUE could initially be misinterpreted, so I've further changed the symbols to *_TRANSITORY and *_PERSISTENT to address this. The sysfs interface is modified only to keep consistency with the chardev interface in enforcing persistence for userspace exports. Signed-off-by: Andrew Jeffery <andrew@aj.id.au> Reviewed-by: Charles Keepax <ckeepax@opensource.cirrus.com> Acked-by: Rob Herring <robh@kernel.org> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2017-10-20gpio: Fix loose spellingAndrew Jeffery1-2/+2
Literally. I expect "lose" was meant here, rather than "loose", though you could feasibly use a somewhat uncommon definition of "loose" to mean what would be meant by "lose": "Loose the hounds" for instance, as in "Release the hounds". Substituting in "value" for "hounds" gives "release the value", and makes some sense, but futher substituting back to loose gives "loose the value" which overall just seems a bit anachronistic. Instead, use modern, pragmatic English and save a character. Cc: Russell Currey <ruscur@russell.cc> Signed-off-by: Andrew Jeffery <andrew@aj.id.au> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2017-08-14gpio: of: Improve kerneldocThierry Reding1-4/+3
Add descriptions for missing fields and fix up some parameter references to match the code. Signed-off-by: Thierry Reding <treding@nvidia.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2017-08-14gpio: Convert to using %pOF instead of full_nameRob Herring1-15/+14
Now that we have a custom printf format specifier, convert users of full_name to use %pOF instead. This is preparation to remove storing of the full path string for each node. Signed-off-by: Rob Herring <robh@kernel.org> Cc: Tien Hock Loh <thloh@altera.com> Cc: Linus Walleij <linus.walleij@linaro.org> Cc: Alexandre Courbot <gnurou@gmail.com> Cc: Brian Norris <computersforpeace@gmail.com> Cc: Florian Fainelli <f.fainelli@gmail.com> Cc: bcm-kernel-feedback-list@broadcom.com Cc: Michal Simek <michal.simek@xilinx.com> Cc: "Sören Brinkmann" <soren.brinkmann@xilinx.com> Cc: linux-gpio@vger.kernel.org Cc: linux-arm-kernel@lists.infradead.org Acked-by: Gregory Fong <gregory.0xf0@gmail.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2017-06-16gpio: of: Spelling: s/retures/returns/Geert Uytterhoeven1-1/+1
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2017-05-29gpio: Add new flags to control sleep status of GPIOsCharles Keepax1-0/+3
Add new flags to allow users to specify that they are not concerned with the status of GPIOs whilst in a sleep/low power state. Signed-off-by: Charles Keepax <ckeepax@opensource.wolfsonmicro.com> Acked-by: Rob Herring <robh@kernel.org> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2017-04-07gpio: core: Decouple open drain/source flag with active low/highLaxman Dewangan1-1/+1
Currently, the GPIO interface is said to Open Drain if it is Single Ended and active LOW. Similarly, it is said as Open Source if it is Single Ended and active HIGH. The active HIGH/LOW is used in the interface for setting the pin state to HIGH or LOW when enabling/disabling the interface. In Open Drain interface, pin is set to HIGH by putting pin in high impedance and LOW by driving to the LOW. In Open Source interface, pin is set to HIGH by driving pin to HIGH and set to LOW by putting pin in high impedance. With above, the Open Drain/Source is unrelated to the active LOW/HIGH in interface. There is interface where the enable/disable of interface is ether active LOW or HIGH but it is Open Drain type. Hence decouple the Open Drain with Single Ended + Active LOW and Open Source with Single Ended + Active HIGH. Adding different flag for the Open Drain/Open Source which is valid only when Single ended flag is enabled. Signed-off-by: Laxman Dewangan <ldewangan@nvidia.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2016-12-30gpio: of: Add support for multiple GPIOs in a single GPIO hogGeert Uytterhoeven1-11/+20
When listing multiple GPIOs in the "gpios" property of a GPIO hog, only the first GPIO is affected. The user is left clueless about the dysfunctioning of the other GPIOs specified. Fix this by adding and documenting support for specifying multiple GPIOs in a single GPIO hog. Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org> Acked-by: Rob Herring <robh@kernel.org> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2016-12-13Merge tag 'gpio-v4.10-1' of git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-gpioLinus Torvalds1-47/+4
Pull GPIO updates from Luinus Walleij: "Bulk GPIO changes for the v4.10 kernel cycle: Core changes: - Simplify threaded interrupt handling: instead of passing numbed parameters to gpiochip_irqchip_add_chained() we create a new call: gpiochip_irqchip_add_nested() so the two types are clearly semantically different. Also make sure that all nested chips call gpiochip_set_nested_irqchip() which is necessary for IRQ resend to work properly if it happens. - Return error on seek operations for the chardev. - Clamp values set as part of gpio[d]_direction_output() so that anything != 0 will be send down to the driver as "1" not the value passed in. - ACPI can now support naming of GPIO lines, hogs and holes in the GPIO lists. New drivers: - The SX150x driver was deemed unfit for the GPIO subsystem and was moved over to a combined GPIO+pinctrl driver in the pinctrl subsystem. New features: - Various cleanups to various drivers" * tag 'gpio-v4.10-1' of git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-gpio: (49 commits) gpio: merrifield: Implement gpio_get_direction callback gpio: merrifield: Add support for hardware debouncer gpio: chardev: Return error for seek operations gpio: arizona: Tidy up probe error path gpio: arizona: Remove pointless set of platform drvdata gpio: pl061: delete platform data handling gpio: pl061: move platform data into driver gpio: pl061: rename variable from chip to pl061 gpio: pl061: rename state container struct gpio: pl061: use local state for parent IRQ storage gpio: set explicit nesting on drivers gpio: simplify adding threaded interrupts gpio: vf610: use builtin_platform_driver gpio: axp209: use correct register for GPIO input status gpio: stmpe: fix interrupt handling bug gpio: em: depnd on ARCH_SHMOBILE gpio: zx: depend on ARCH_ZX gpio: x86: update config dependencies for x86 specific hardware gpio: mb86s7x: use builtin_platform_driver gpio: etraxfs: use builtin_platform_driver ...
2016-10-31gpio: of: fix GPIO drivers with multiple gpio_chip for a single nodeMasahiro Yamada1-5/+9
Sylvain Lemieux reports the LPC32xx GPIO driver is broken since commit 762c2e46c059 ("gpio: of: remove of_gpiochip_and_xlate() and struct gg_data"). Probably, gpio-etraxfs.c and gpio-davinci.c are broken too. Those drivers register multiple gpio_chip that are associated to a single OF node, and their own .of_xlate() checks if the passed gpio_chip is valid. Now, the problem is of_find_gpiochip_by_node() returns the first gpio_chip found to match the given node. So, .of_xlate() fails, except for the first GPIO bank. Reverting the commit could be a solution, but I do not want to go back to the mess of struct gg_data. Another solution here is to take the match by a node pointer and the success of .of_xlate(). It is a bit clumsy to call .of_xlate twice; for gpio_chip matching and for really getting the gpio_desc index. Perhaps, our long-term goal might be to convert the drivers to single chip registration, but this commit will solve the problem until then. Fixes: 762c2e46c059 ("gpio: of: remove of_gpiochip_and_xlate() and struct gg_data") Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> Reported-by: Sylvain Lemieux <slemieux.tyco@gmail.com> Tested-by: David Lechner <david@lechnology.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2016-10-31gpio: of: add missing of_node_put() in of_gpiochip_scan_gpios()Wei Yongjun1-1/+3
When terminating for_each_available_child_of_node() iteration with break or return, of_node_put() should be used to prevent stale device node references from being left behind. This is detected by Coccinelle semantic patch. Signed-off-by: Wei Yongjun <weiyongjun1@huawei.com> Reviewed-by: Vladimir Zapolskiy <vladimir_zapolskiy@mentor.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2016-10-24gpio: Rework of_gpiochip_set_names() to use device property accessorsMika Westerberg1-46/+1
In order to use "gpio-line-names" property in systems not having DT as their boot firmware, rework of_gpiochip_set_names() to use device property accessors. This reworked function is placed in a separate file making it clear it deals with universal device properties. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2016-10-05Merge tag 'gpio-v4.9-1' of git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-gpioLinus Torvalds1-0/+39
Pull GPIO updates from Linus Walleij: "This is the bulk of GPIO changes for the v4.9 series: Subsystem improvements: - do away with the last users of the obsolete Kconfig options ARCH_REQUIRE_GPIOLIB and ARCH_WANT_OPTIONAL_GPIOLIB (the latter always sounded like an item on a wishlist to Santa Claus to me). We can now select GPIOLIB and be done with it, for all archs. After some struggle it even work on UM. Not that it has GPIO, but if it wants to, it can select the library. - continued efforts to make drivers properly either tristate or bool. - introduce a warning for drivers assigning default triggers to their irqchip lines when probed from device tree, so we find and fix these ambigous drivers. It is agreed that in the OF config path, the device tree defines trigger characteristics. - the same warning, mutatis mutandis, for ACPI-probed GPIO irqchips. - we introduce the ability to mark certain IRQ lines as "unusable" as they can be taken by BIOS/firmware, unrouted in silicon and generally nasty if you use them, and such things. This is put to good use in the STMPE driver and also in the Cherryview pin control driver. - a new "mockup" virtual GPIO device that can be used for testing. The plan is to add unit tests under tools/* for exercising this device and verify that the kernel code paths are working as they should. - make memory-mapped I/O-drivers depend on HAS_IOMEM. This was implicit all the time, but when people started building UM with allyesconfig or allmodconfig it exploded in their face. - move some stray bits of device tree and ACPI HW description callbacks down into their respective implementation silo. These were causing issues when compiling on !HAS_IOMEM as well, so now eventually UM compiles the GPIOLIB library if it wants to. New drivers: - new driver for the Aspeed GPIO front-end companion to the pin controller merged through the pin control tree. - new driver for the LP873x PMIC GPIO portions. - new driver for Technologic Systems' I2C FPGA GPIO such as TS4900, TS-7970, TS-7990 and TS-4100. - new driver for the Broadcom BCM63xx series including BCM6338 and BCM6345. - new driver for the Intel WhiskeyCove PMIC GPIO. - new driver for the Allwinner AXP209 PMIC GPIO portions. - new driver for Diamond Systems 48 line GPIO-MM, another of these port-mapped I/O expansion cards. - support the STMicroelectronics STMPE1600 variant in the STMPE driver. Driver improvements: - the STMPE driver now supports rising/falling edge detection properly for IRQs. - the PCA954x will now fetch and enable its VCC regulator properly. - major rework of the PCA953x driver with the goal of eventually switching it over to use regmap and thus modernize it even more. - switch the IOP driver to use the generic MMIO GPIO library. - move the ages old HTC EGPIO (extended GPIO) GPIO expander driver over to this subsystem from MFD, achieveing some separation of concerns" * tag 'gpio-v4.9-1' of git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-gpio: (81 commits) gpio: add missing static inline gpio: OF: localize some gpiochip init functions gpio: acpi: separation of concerns gpio: OF: separation of concerns gpio: make memory-mapped drivers depend on HAS_IOMEM gpio: stmpe: use BIT() macro gpio: stmpe: forbid unused lines to be mapped as IRQs mfd/gpio: Move HTC GPIO driver to GPIO subsystem gpio: MAINTAINERS: Add an entry for GPIO mockup driver gpio/mockup: add virtual gpio device gpio: Added zynq specific check for special pins on bank zero gpio: axp209: Implement get_direction gpio: aspeed: remove redundant return value check gpio: loongson1: remove redundant return value check ARM: omap2: fix missing include gpio: tc3589x: fix up complaints on unsigned gpio: tc3589x: add .get_direction() and small cleanup gpio: f7188x: use gpiochip_get_data instead of container_of gpio: tps65218: use devm_gpiochip_add_data() for gpio registration gpio: aspeed: fix return value check in aspeed_gpio_probe() ...
2016-10-03gpio: OF: separation of concernsLinus Walleij1-0/+39
The generic GPIO library directly implement code for of_find_gpio() which is only used with CONFIG_OF and causes compilation problems on archs that do not even have stubs for OF functions, especially on UM that does not implement any IO remap functions. Move the function to gpiolib-of.c, implement a static inline stub in gpiolib.h returning PTR_ERR(-ENOENT) if CONFIG_OF_GPIO is not set and be done with it. Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2016-09-08Revert "gpio: include <linux/io-mapping.h> in gpiolib-of"Linus Walleij1-1/+0
This reverts commit 7d4defe21c682c934a19fce1ba8b54b7bde61b08. The commit was pointless, manically trembling in the dark for a solution. The real fixes are: commit 048c28c91e56 ("gpio: make any OF dependent driver depend on OF_GPIO") commit 2527ecc9195e ("gpio: Fix OF build problem on UM") Reported-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2016-07-26Merge tag 'gpio-v4.8-1' of git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-gpioLinus Torvalds1-68/+59
Pull GPIO updates from Linus Walleij: "This is the bulk of GPIO changes for the v4.8 kernel cycle. The big news is the completion of the chardev ABI which I'm very happy about and apart from that it's an ordinary, quite busy cycle. The details are below. The patches are tested in linux-next for some time, patches to other subsystem mostly have ACKs. I got overly ambitious with configureing lines as input for IRQ lines but it turns out that some controllers have their interrupt-enable and input-enabling in orthogonal settings so the assumption that all IRQ lines are input lines does not hold. Oh well, revert and back to the drawing board with that. Core changes: - The big item is of course the completion of the character device ABI. It has now replaced and surpassed the former unmaintainable sysfs ABI: we can now hammer (bitbang) individual lines or sets of lines and read individual lines or sets of lines from userspace, and we can also register to listen to GPIO events from userspace. As a tie-in we have two new tools in tools/gpio: gpio-hammer and gpio-event-mon that illustrate the proper use of the new ABI. As someone said: the wild west days of GPIO are now over. - Continued to remove the pointless ARCH_[WANT_OPTIONAL|REQUIRE]_GPIOLIB Kconfig symbols. I'm patching hexagon, openrisc, powerpc, sh, unicore, ia64 and microblaze. These are either ACKed by their maintainers or patched anyways after a grace period and no response from maintainers. Some archs (ARM) come in from their trees, and others (x86) are still not fixed, so I might send a second pull request to root it out later in this merge window, or just defer to v4.9. - The GPIO tools are moved to the tools build system. New drivers: - New driver for the MAX77620/MAX20024. - New driver for the Intel Merrifield. - Enabled PCA953x for the TI PCA9536. - Enabled PCA953x for the Intel Edison. - Enabled R8A7792 in the RCAR driver. Driver improvements: - The STMPE and F7188x now supports the .get_direction() callback. - The Xilinx driver supports setting multiple lines at once. - ACPI support for the Vulcan GPIO controller. - The MMIO GPIO driver supports device tree probing. - The Acer One 10 is supported through the _DEP ACPI attribute. Cleanups: - A major cleanup of the OF/DT support code. It is way easier to read and understand now, probably this improves performance too. - Drop a few redundant .owner assignments. - Remove CLPS711x boardfile support: we are 100% DT" * tag 'gpio-v4.8-1' of git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-gpio: (67 commits) MAINTAINERS: Add INTEL MERRIFIELD GPIO entry gpio: dwapb: add missing fwnode_handle_put() in dwapb_gpio_get_pdata() gpio: merrifield: Protect irq_ack() and gpio_set() by lock gpio: merrifield: Introduce GPIO driver to support Merrifield gpio: intel-mid: Make it depend to X86_INTEL_MID gpio: intel-mid: Sort header block alphabetically gpio: intel-mid: Remove potentially harmful code gpio: rcar: add R8A7792 support gpiolib: remove duplicated include from gpiolib.c Revert "gpio: convince line to become input in irq helper" gpiolib: of_find_gpio(): Don't discard errors gpio: of: Allow overriding the device node gpio: free handles in fringe cases gpio: tps65218: Add platform_device_id table gpio: max77620: get gpio value based on direction gpio: lynxpoint: avoid potential warning on error path tools/gpio: add install section tools/gpio: move to tools buildsystem gpio: intel-mid: switch to devm_gpiochip_add_data() gpio: 74x164: Use spi_write() helper instead of open coding ...
2016-06-23gpio: of: factor out common code to a new helper functionMasahiro Yamada1-19/+18
The conversion from a DT spec to struct gpio_desc is common between of_get_named_gpiod_flags() and of_parse_own_gpio(). Factor out the common code to a new helper, of_xlate_and_get_gpiod_flags(). Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2016-06-23gpio: of: remove of_gpiochip_and_xlate() and struct gg_dataMasahiro Yamada1-46/+35
The usage of gpiochip_find(&gg_data, of_gpiochip_and_xlate) is odd. Usually gpiochip_find() is used to find a gpio_chip. Here, however, the return value from gpiochip_find() is just discarded. Instead, gpiochip_find(&gg_data, of_gpiochip_and_xlate) is called for the side-effect of the match function. The match function, of_gpiochip_find_and_xlate(), fills the given struct gg_data, but a match function should be simply called to judge the matching. This commit fixes this distortion and makes the code more readable. Remove of_gpiochip_find_and_xlate() and struct gg_data. Instead, this adds a very simple helper function of_find_gpiochip_by_node(). Now, of_get_named_gpiod_flags() is implemented more straight-forward. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2016-06-23gpio: of: move chip->of_gpio_n_cells checking to of_gpiochip_add()Masahiro Yamada1-1/+4
Do this sanity check only once when the gpio_chip is added rather than every time gpio-hog is handled. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2016-06-23gpio: of: drop needless gpio_chip look-up in of_parse_own_gpio()Masahiro Yamada1-19/+20
This function is doing more complicated than needed. The caller of this function, of_gpiochip_scan_gpios() already knows the pointer to the gpio_chip. It can pass it to of_parse_own_gpio() instead of looking up the gpio_chip by gpiochip_find(). Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2016-06-23gpio: of: optimize "gpios" property parsing of of_parse_own_gpio()Masahiro Yamada1-7/+5
Call of_property_read_u32_array() only once rather than iterating of_property_read_u32_index(). Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2016-06-08gpio: include <linux/io-mapping.h> in gpiolib-ofLinus Walleij1-0/+1
When enabling the gpiolib for all archs a build robot came up with this: All errors (new ones prefixed by >>): drivers/gpio/gpiolib-of.c: In function 'of_mm_gpiochip_add_data': >> drivers/gpio/gpiolib-of.c:317:2: error: implicit declaration of function 'iounmap' [-Werror=implicit-function-declaration] iounmap(mm_gc->regs); ^~~~~~~ cc1: some warnings being treated as errors Fix this by including <linux/io-mapping.h> explicitly. Fixes: 296ad4acb8ef ("gpio: remove deps on ARCH_[WANT_OPTIONAL|REQUIRE]_GPIOLIB") Reported-by: kbuild test robot <fengguang.wu@intel.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2016-06-07gpio: of: add missing of_node_put() to of_gpiochip_add_pin_range()Masahiro Yamada1-0/+1
As the comment block of of_parse_phandle_with_fixed_args() says, the caller is responsible to call of_node_put() on the returned node when done. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2016-05-10gpio: of: make it possible to name GPIO linesLinus Walleij1-0/+49
Make it possible to name the producer side of a GPIO line using a "gpio-line-names" property array, modeled on the "clock-output-names" property from the clock bindings. This naming is especially useful for: - Debugging: lines are named after function, not just opaque offset numbers. - Exploration: systems where some or all GPIO lines are available to end users, such as prototyping, one-off's "makerspace usecases" users are helped by the names of the GPIO lines when tinkering. This usecase has been surfacing recently. The gpio-line-names attribute is completely optional. Example output from lsgpio on a patched Snowball tree: GPIO chip: gpiochip6, "8000e180.gpio", 32 GPIO lines line 0: unnamed unused line 1: "AP_GPIO161" "extkb3" [kernel] line 2: "AP_GPIO162" "extkb4" [kernel] line 3: "ACCELEROMETER_INT1_RDY" unused [kernel] line 4: "ACCELEROMETER_INT2" unused line 5: "MAG_DRDY" unused [kernel] line 6: "GYRO_DRDY" unused [kernel] line 7: "RSTn_MLC" unused line 8: "RSTn_SLC" unused line 9: "GYRO_INT" unused line 10: "UART_WAKE" unused line 11: "GBF_RESET" unused line 12: unnamed unused Cc: Grant Likely <grant.likely@linaro.org> Cc: Amit Kucheria <amit.kucheria@linaro.org> Cc: David Mandala <david.mandala@linaro.org> Cc: Lee Campbell <leecam@google.com> Cc: devicetree@vger.kernel.org Acked-by: Rob Herring <robh@kernel.org> Reviewed-by: Michael Welling <mwelling@ieee.org> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2016-04-14gpio: of: Scan available child node for gpio-hogLaxman Dewangan1-1/+1
Look for child node which are available when iterating for gpio hog node for request/set GPIO initial configuration during OF gpio chip registration. All it really does is make it possible to set status = "disabled"; in the hog nodes, and then they will not be applied. Signed-off-by: Laxman Dewangan <ldewangan@nvidia.com> Reviewed-by: Thierry Reding <treding@nvidia.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2016-04-13gpio: of: Return error if gpio hog configuration failedLaxman Dewangan1-6/+9
If GPIO hog configuration failed while adding OF based gpiochip() then return the error instead of ignoring it. This helps of properly handling the gpio driver dependency. When adding the gpio hog nodes for NVIDIA's Tegra210 platforms, the gpio_hogd() fails with EPROBE_DEFER because pinctrl is not ready at this time and gpio_request() for Tegra GPIO driver returns error. The error was not causing the Tegra GPIO driver to fail as the error was getting ignored. Signed-off-by: Laxman Dewangan <ldewangan@nvidia.com> Cc: Benoit Parrot <bparrot@ti.com> Cc: Alexandre Courbot <acourbot@nvidia.com> Reviewed-by: Thierry Reding <treding@nvidia.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2016-01-05gpio: of: provide optional of_mm_gpiochip_add_data() functionLinus Walleij1-5/+7
In the same spirit as we add an optional void *data argument to the gpiochip_add_data() call, we need this also for of_mm_gpiochip_add(). Signed-off-by: Linus Walleij <linus.walleij@linaro.org>