- 22 7月, 2016 4 次提交
-
-
由 Andy Shevchenko 提交于
Sort the header inclusion lines by alphabetical order. While here, update Intel Copyright. Signed-off-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com> Reviewed-by: NMika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
-
由 Andy Shevchenko 提交于
The commit d56d6b3d ("gpio: langwell: add Intel Merrifield support") doesn't look at all as a proper support for Intel Merrifield and I dare to say that it distorts the behaviour of the hardware. The register map is different on Intel Merrifield, i.e. only 6 out of 8 register have the same purpose but none of them has same location in the address space. The current case potentially harmful to existing hardware since it's poking registers on wrong offsets and may set some pin to be GPIO output when connected hardware doesn't expect such. Besides the above GPIO and pinctrl on Intel Merrifield have been located in different IP blocks. The functionality has been extended as well, i.e. added support of level interrupts, special registers for wake capable sources and thus, in my opinion, requires a completele separate driver. If someone wondering the existing gpio-intel-mid.c would be converted to actual pinctrl (which by the fact it is now), though I wouldn't be a volunteer to do that. Fixes: d56d6b3d ("gpio: langwell: add Intel Merrifield support") Cc: stable@vger.kernel.org # v3.13+ Signed-off-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com> Reviewed-by: NMika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
-
由 Sergei Shtylyov 提交于
Renesas R8A7792 SoC is a member of the R-Car gen2 family, add support for its GPIO controllers. Signed-off-by: NSergei Shtylyov <sergei.shtylyov@cogentembedded.com> Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
-
由 Wei Yongjun 提交于
Remove duplicated include. Signed-off-by: NWei Yongjun <yongjun_wei@trendmicro.com.cn> Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
-
- 06 7月, 2016 3 次提交
-
-
由 Linus Walleij 提交于
This reverts commit 7e7c059c. I was wrong about trying to do this, as it breaks the orthogonality between gpiochips and irqchips. Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
-
由 Lars-Peter Clausen 提交于
Since commit dd34c37a ("gpio: of: Allow -gpio suffix for property names") when requesting a GPIO from the devicetree gpiolib looks for properties with both the '-gpio' and the '-gpios' suffix. This was implemented by first searching for the property with the '-gpios' suffix and if that yields an error try the '-gpio' suffix. This approach has the issue that any error returned when looking for the '-gpios' suffix is silently discarded. Commit 06fc3b70 ("gpio: of: Fix handling for deferred probe for -gpio suffix") partially addressed the issue by treating the EPROBE_DEFER error as a special condition. This fixed the case when the property is specified, but the GPIO provider is not ready yet. But there are other cases in which of_get_named_gpiod_flags() returns an error even though the property is specified, e.g. if the specification is incorrect. of_find_gpio() should only try to look for the property with the '-gpio' suffix if no property with the '-gpios' suffix was found. If the property was not found of_get_named_gpiod_flags() will return -ENOENT, so update the condition to abort and propagate the error to the caller in all other cases. This is important for gpiod_get_optinal() and friends to behave correctly in case the specifier contains errors. Without this patch they'll return NULL if the property uses the '-gpios' suffix and the specifier contains errors, which falsely indicates to the caller that no GPIO was specified. Signed-off-by: NLars-Peter Clausen <lars@metafoo.de> Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
-
由 Thierry Reding 提交于
When registering a GPIO chip, drivers can override the device tree node associated with the chip by setting the chip's ->of_node field. If set, this field is supposed to take precedence over the ->parent->of_node field, but the code doesn't actually do that. Commit 762c2e46 ("gpio: of: remove of_gpiochip_and_xlate() and struct gg_data") exposes this because it now no longer matches on the GPIO chip's ->of_node field, but the GPIO device's ->of_node field that is set using the procedure described above. Signed-off-by: NThierry Reding <treding@nvidia.com> Acked-by: NAlexandre Courbot <acourbot@nvidia.com> Reviewed-by: NMasahiro Yamada <yamada.masahiro@socionext.com> Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
-
- 04 7月, 2016 3 次提交
-
-
由 Linus Walleij 提交于
If we fail when copying the ioctl() struct to userspace we still need to clean up the cruft otherwise left behind or it will stay around until the issuing process terminates the file handle. Reported-by: NAlexander Stein <alexander.stein@systec-electronic.com> Acked-by: NAlexander Stein <alexander.stein@systec-electronic.com> Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
-
由 Keerthy 提交于
platform_device_id table is needed for adding the tps65218-gpio module to the mfd_cell array. Signed-off-by: NKeerthy <j-keerthy@ti.com> Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
-
由 Venkat Reddy Talla 提交于
Gpio direction is determined by DIRx bit of GPIO configuration register, return max77620 gpio value based on direction in or out. Signed-off-by: NVenkat Reddy Talla <vreddytalla@nvidia.com> Reviewed-by: NAlexandre Courbot <acourbot@nvidia.com> Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
-
- 23 6月, 2016 11 次提交
-
-
由 Andy Shevchenko 提交于
When devres API is in use we are not supposed to call plain gpiochip_remove(). Remove redundant call to gpiochip_remove(). Signed-off-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com> Acked-by: NMika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
-
由 Andy Shevchenko 提交于
Allow user to call install target. Signed-off-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com> Acked-by: NAlexandre Courbot <acourbot@nvidia.com> Tested-by: NAlexandre Courbot <acourbot@nvidia.com> Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
-
由 Andy Shevchenko 提交于
There is a nice buildsystem dedicated for userspace tools in Linux kernel tree. Switch gpio target to be built by it. Signed-off-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com> Acked-by: NAlexandre Courbot <acourbot@nvidia.com> Tested-by: NAlexandre Courbot <acourbot@nvidia.com> Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
-
由 Andy Shevchenko 提交于
The error handling is not correct since the commit 3f7dbfd8 ("gpio: intel-mid: switch to using gpiolib irqchip helpers"). Switch to devres API to fix the potential resource leak. Fixes: commit 3f7dbfd8 ("gpio: intel-mid: switch to using gpiolib irqchip helpers") Signed-off-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
-
由 Geert Uytterhoeven 提交于
Signed-off-by: NGeert Uytterhoeven <geert+renesas@glider.be> Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
-
由 Masahiro Yamada 提交于
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: NMasahiro Yamada <yamada.masahiro@socionext.com> Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
-
由 Masahiro Yamada 提交于
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: NMasahiro Yamada <yamada.masahiro@socionext.com> Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
-
由 Masahiro Yamada 提交于
Do this sanity check only once when the gpio_chip is added rather than every time gpio-hog is handled. Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com> Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
-
由 Masahiro Yamada 提交于
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: NMasahiro Yamada <yamada.masahiro@socionext.com> Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
-
由 Masahiro Yamada 提交于
Call of_property_read_u32_array() only once rather than iterating of_property_read_u32_index(). Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com> Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
-
由 Linus Walleij 提交于
The generic IRQ helper library just checks if the IRQ line is set as input before activating it for interrupts. As we recently started to check things better with .get_dir() it turns out that it's good to try to convince the line to become an input before attempting to lock it as IRQ. Reviewed-by: NBjörn Andersson <bjorn.andersson@linaro.org> Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
-
- 18 6月, 2016 2 次提交
-
-
由 Ben Dooks 提交于
The lineevent_irq_thread is not exported, so make it static to fix the following warning: drivers/gpio/gpiolib.c:654:13: warning: symbol 'lineevent_irq_thread' was not declared. Should it be static? Signed-off-by: NBen Dooks <ben.dooks@codethink.co.uk> Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
-
由 Linus Walleij 提交于
When initializing the GPIO handles, we use the iterator (i) to back off if something goes wrong. But since the iterator is also used after we pass the loop, we must decrement by one after exiting the loop so that we point at the last element in the array. Reported-by: NDan Carpenter <dan.carpenter@oracle.com> Cc: Dan Carpenter <dan.carpenter@oracle.com> Cc: Walter Harms <wharms@bfs.de> Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
-
- 16 6月, 2016 1 次提交
-
-
由 Arnd Bergmann 提交于
gcc reports a theoretical case for returning uninitialized data in the kfifo when a GPIO interrupt happens and neither GPIOEVENT_REQUEST_RISING_EDGE nor GPIOEVENT_REQUEST_FALLING_EDGE are set: drivers/gpio/gpiolib.c: In function 'lineevent_irq_thread': drivers/gpio/gpiolib.c:683:87: error: 'ge.id' may be used uninitialized in this function [-Werror=maybe-uninitialized] This case should not happen, but to be on the safe side, let's return from the irq handler without adding data to the FIFO to ensure we can never leak stack data to user space. Signed-off-by: NArnd Bergmann <arnd@arndb.de> Fixes: 61f922db ("gpio: userspace ABI for reading GPIO line events") Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
-
- 15 6月, 2016 6 次提交
-
-
由 Linus Walleij 提交于
The gpio-event-mon is used from userspace as an example of how to monitor GPIO line events. It will latch on to a certain GPIO line on a certain gpiochip and print timestamped events as they arrive. Example output: $ gpio-event-mon -n gpiochip2 -o 0 -r -f Monitoring line 0 on gpiochip2 Initial line value: 1 GPIO EVENT 946685798487609863: falling edge GPIO EVENT 946685798732482910: rising edge GPIO EVENT 946685799115997314: falling edge GPIO EVENT 946685799381469726: rising edge Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
-
由 Linus Walleij 提交于
This adds an ABI for listening to events on GPIO lines. The mechanism returns an anonymous file handle to a request to listen to a specific offset on a specific gpiochip. To fetch the stream of events from the file handle, userspace simply reads an event. - Events can be requested with the same flags as ordinary handles, i.e. open drain or open source. An ioctl() call GPIO_GET_LINEEVENT_IOCTL is issued indicating the desired line. - Events can be requested for falling edge events, rising edge events, or both. - All events are timestamped using the kernel real time nanosecond timestamp (the same as is used by IIO). - The supplied consumer label will appear in "lsgpio" listings of the lines, and in /proc/interrupts as the mechanism will request an interrupt from the gpio chip. - Events are not supported on gpiochips that do not serve interrupts (no legal .to_irq() call). The event interrupt is threaded to avoid any realtime problems. - It is possible to also directly read the current value of the registered GPIO line by issuing the same GPIOHANDLE_GET_LINE_VALUES_IOCTL as used by the line handles. Setting the value is not supported: we do not listen to events on output lines. This ABI is strongly influenced by Industrial I/O and surpasses the old sysfs ABI by providing proper precision timestamps, making it possible to set flags like open drain, and put consumer names on the GPIO lines. Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
-
由 Linus Walleij 提交于
The gpio-hammer is used from userspace as an example of how to retrieve a GPIO handle for one or several GPIO lines and hammer the outputs from low to high and back again. It will pulse the selected lines once per second for a specified number of times or indefinitely if no loop count is supplied. Example output: $ gpio-hammer -n gpiochip0 -o5 -o6 -o7 Hammer lines [5, 6, 7] on gpiochip0, initial states: [1, 1, 1] [-] [5: 0, 6: 0, 7: 0] Tested-by: NMichael Welling <mwelling@ieee.org> Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
-
由 Linus Walleij 提交于
This adds a userspace ABI for reading and writing GPIO lines. The mechanism returns an anonymous file handle to a request to read/write n offsets from a gpiochip. This file handle in turn accepts two ioctl()s: one that reads and one that writes values to the selected lines. - Handles can be requested as input/output, active low, open drain, open source, however when you issue a request for n lines with GPIO_GET_LINEHANDLE_IOCTL, they must all have the same flags, i.e. all inputs or all outputs, all open drain etc. If a granular control of the flags for each line is desired, they need to be requested individually, not in a batch. - The GPIOHANDLE_GET_LINE_VALUES_IOCTL read ioctl() can be issued also to output lines to verify that the hardware is in the expected state. - It reads and writes up to GPIOHANDLES_MAX lines at once, utilizing the .set_multiple() call in the driver if possible, making the call efficient if several lines can be written with a single register update. The limitation of GPIOHANDLES_MAX to 64 lines is done under the assumption that we may expect hardware that can issue a transaction updating 64 bits at an instant but unlikely anything larger than that. ChangeLog v2->v3: - Use gpiod_get_value_cansleep() so we support also slowpath GPIO drivers. - Fix up the UAPI docs kerneldoc. - Allocate the anonymous fd last, so that the release function don't get called until that point of something fails. After this point, skip the errorpath. ChangeLog v1->v2: - Handle ioctl_compat() properly based on a similar patch to the other ioctl() handling code. - Use _IOWR() as we pass pointers both in and out of the ioctl() - Use kmalloc() and kfree() for the linehandled, do not try to be fancy with devm_* it doesn't work the way I thought. - Fix const-correctness on the linehandle name field. Acked-by: NMichael Welling <mwelling@ieee.org> Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
-
由 Andy Shevchenko 提交于
Intel Edison board has 4 GPIO expanders PCA9555a connected to I2C bus. Add an ID to support them. Signed-off-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
-
由 Rui Zhang 提交于
On Acer One 10, the ACPI battery driver can not be probed because it depends on the GPIO controller as well as the I2C controller to work, Device (BATC) { Name (_HID, EisaId ("PNP0C0A") /* Control Method Battery */) ... Name (_DEP, Package (0x03) // _DEP: Dependencies { I2C1, GPO2, GPO0 }) ... } The I2C dependency also exists on other platforms and has been fixed by commit 40e7fcb1 ("ACPI: Add _DEP support to fix battery issue on Asus T100TA"), this patch resolves the GPIO dependency for Acer One 10. Link:https://bugzilla.kernel.org/show_bug.cgi?id=115191Tested-by: NStace A. Zacharov <stace75@gmail.com> Signed-off-by: NZhang Rui <rui.zhang@intel.com> Acked-by: NMika Westerberg <mika.westerberg@linux.intel.com> Acked-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
-
- 14 6月, 2016 2 次提交
-
-
由 plr.vincent@gmail.com 提交于
Avoids gpiolib assumptions on initial pin direction, allowing user to observe power-on settings. Signed-off-by: NVincent Pelletier <plr.vincent@gmail.com> Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
-
由 Andrew F. Davis 提交于
When CONFIG_GPIOLIB is not set make will still descend into the gpio directory but nothing will be built. This produces unneeded build artifacts and messages in addition to slowing the build. Fix this here. Signed-off-by: NAndrew F. Davis <afd@ti.com> Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
-
- 13 6月, 2016 2 次提交
-
-
由 Andrew Jeffery 提交于
Signed-off-by: NAndrew Jeffery <andrew@aj.id.au> Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
-
由 Vignesh R 提交于
NBANK() macro assumes that ngpios is a multiple of 8(BANK_SZ) and hence results in 0 banks for PCA9536 which has just 4 gpios. This is wrong as PCA9356 has 1 bank with 4 gpios. This results in uninitialized PCA953X_INVERT register. Fix this by using DIV_ROUND_UP macro in NBANK(). Cc: stable@vger.kernel.org Signed-off-by: NVignesh R <vigneshr@ti.com> Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
-
- 08 6月, 2016 6 次提交
-
-
由 Christian Lamparter 提交于
This patch adds support for the Western Digital's MyBook Live memory-mapped GPIO controllers. The GPIOs will be supported by the generic driver for memory-mapped GPIO controllers. Signed-off-by: NChristian Lamparter <chunkeey@googlemail.com> Acked-by: NAlexandre Courbot <acourbot@nvidia.com> Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
-
由 Álvaro Fernández Rojas 提交于
This patch adds support for defining memory-mapped GPIOs which are compatible with the existing gpio-mmio interface. The generic library provides support for many memory-mapped GPIO controllers that are found in various on-board FPGA and ASIC solutions that are used to control board's switches, LEDs, chip-selects, Ethernet/USB PHY power, etc. For setting GPIOs there are three configurations: 1. single input/output register resource (named "dat"), 2. set/clear pair (named "set" and "clr"), 3. single output register resource and single input resource ("set" and dat"). The configuration is detected by which resources are present. For the single output register, this drives a 1 by setting a bit and a zero by clearing a bit. For the set clr pair, this drives a 1 by setting a bit in the set register and clears it by setting a bit in the clear register. For setting the GPIO direction, there are three configurations: a. simple bidirectional GPIOs that requires no configuration. b. an output direction register (named "dirout") where a 1 bit indicates the GPIO is an output. c. an input direction register (named "dirin") where a 1 bit indicates the GPIO is an input. Reviewed-by: NAndy Shevchenko <andy.shevchenko@gmail.com> Signed-off-by: NÁlvaro Fernández Rojas <noltari@gmail.com> Signed-off-by: NChristian Lamparter <chunkeey@googlemail.com> Acked-by: NAlexandre Courbot <acourbot@nvidia.com> Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
-
由 Paul Gortmaker 提交于
The Kconfig currently controlling compilation of this code is: config GPIO_LPC18XX bool "NXP LPC18XX/43XX GPIO support" ...meaning that it currently is not being built as a module by anyone. When targeting orphaned modular code in non-modular drivers, this came up. Joachim indicated that the driver was actually meant to be tristate but ended up bool by accident. So here we make it tristate instead of removing the modular code that was essentially orphaned. Cc: Joachim Eastwood <manabian@gmail.com> Acked-by: NJoachim Eastwood <manabian@gmail.com> Cc: Linus Walleij <linus.walleij@linaro.org> Cc: Alexandre Courbot <gnurou@gmail.com> Cc: linux-gpio@vger.kernel.org Signed-off-by: NPaul Gortmaker <paul.gortmaker@windriver.com> Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
-
由 Kamlakant Patel 提交于
Add ACPI support for GPIO controller on Broadcom Vulcan ARM64. ACPI ID for this device is BRCM9006. Signed-off-by: NKamlakant Patel <kamlakant.patel@broadcom.com> Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
-
由 Kamlakant Patel 提交于
irq_alloc_descs need not be called in case of Vulcan, where we use a dynamic IRQ range for GPIO interrupt numbers. Update code not to call irq_alloc_descs and pass 0 as irq_base in case of Vulcan. Signed-off-by: NKamlakant Patel <kamlakant.patel@broadcom.com> Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
-
由 Alexander Shiyan 提交于
Since board support for the CLPS711X platform was removed, remove the board support from the driver. Signed-off-by: NAlexander Shiyan <shc_work@mail.ru> Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
-