- 12 Jan, 2018 4 commits
-
-
Linus Walleij authored
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>
-
Linus Walleij authored
We have been holding back on adding an API for fetching GPIO handles directly from device nodes, strongly preferring to get it from the spawn devices instead. The fwnode interface however already contains an API for doing this, as it is used for opaque device tree nodes or ACPI nodes for getting handles to LEDs and keys that use GPIO: those are specified as one child per LED/key in the device tree and are not individual devices. However regulators present a special problem as they already have helper functions to traverse the device tree from a regulator node and two levels down to fill in data, and as it already traverses GPIO nodes in its own way, and already holds a pointer to each regulators device tree node, it makes most sense to export an API to fetch the GPIO descriptor directly from the node. We only support the devm_* version for now, hopefully no non-devres version will be needed. Signed-off-by: -
Linus Walleij authored
Sometimes a GPIO needs to be taken from a node without a device associated with it. The fwnode accessor does this, let's however break out the DT code for now. Signed-off-by: -
Linus Walleij authored
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:
-
- 11 Jan, 2018 2 commits
-
-
Wei Yongjun authored
Fix to return error code -ENOMEM from the error handling case instead of 0, as done elsewhere in this function. Fixes: 5a2a3002 ("gpio: Add gpio driver support for ThunderX and OCTEON-TX") Signed-off-by:
Wei Yongjun <weiyongjun1@huawei.com> Acked-by:
David Daney <david.daney@cavium.com> Signed-off-by:
-
Arnd Bergmann authored
The newly added GPIO driver for winbond chipsets causes a circular dependency warning in Kconfig: drivers/gpio/Kconfig:13:error: recursive dependency detected! drivers/gpio/Kconfig:13: symbol GPIOLIB is selected by STX104 drivers/iio/adc/Kconfig:699: symbol STX104 depends on ISA_BUS_API arch/Kconfig:830: symbol ISA_BUS_API is selected by GPIO_WINBOND drivers/gpio/Kconfig:701: symbol GPIO_WINBOND depends on GPIOLIB The underlying problem is that ISA_BUS_API is not meant to be selected by device drivers, instead it is provided by the architectures that support ISA add-on card devices, or in case of x86 have this explicitly enabled. This particular driver appears to be different from the other ISA_BUS_API based drivers, in that it is not normally an add-on card (ISA or PC104) but instead is an LPC-attached component on the mainboard. We already support other functionality provided by this chip, at least drivers/watchdog/w83627hf_wdt.c and drivers/hwmon/w83627ehf.c, plus there is a discovery function for this hardware in drivers/parport/parport_pc.c. If we want to use this driver without having to enable CONFIG_EXPERT, it might be better to not use the isa_bus_type for it, but rather turn it into a platform_driver, acpi_driver or add an MFD for it that is shared with the wdt and hwmon portions and does the probing. For now, this patch fixes the dependency by changing 'select' into 'depends on'. Cc: William Breathitt Gray <vilhelm.gray@gmail.com> Cc: Guenter Roeck <linux@roeck-us.net> Cc: Maciej S. Szmigiero <mail@maciej.szmigiero.name> Cc: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Fixes: a0d65009 ("gpio: winbond: Add driver") Signed-off-by:
Arnd Bergmann <arnd@arndb.de> Signed-off-by:
-
- 10 Jan, 2018 2 commits
-
-
William Breathitt Gray authored
The ACCES PCIe-IDIO-24 device provides 56 lines of digital I/O (24 lines of optically-isolated non-polarized digital inputs for AC and DC control signals, 24 lines of isolated solid state FET digital outputs, and 8 non-isolated TTL/CMOS compatible programmable I/O). An interrupt is generated when any of the inputs change state (low to high or high to low). Input filter control is not supported by this driver, and input filters are deactivated by this driver. These devices are capable of get_multiple and set_multiple functionality, but these functions have not yet been implemented for this driver. Change-Of-State (COS) detection functionality may be configured to fire interrupts on exclusively rising/falling edges, but this driver currently only implements COS detection for either both edges or none. Signed-off-by:
William Breathitt Gray <vilhelm.gray@gmail.com> Signed-off-by:
-
Stephen Boyd authored
Some pinctrl drivers can use the gpiochip irq valid information to figure out if certain gpios are exposed to the kernel for usage or not. Expose this API so we can use it in the pinmux_ops::request ops. Signed-off-by:
Stephen Boyd <sboyd@codeaurora.org> Acked-by:
Bjorn Andersson <bjorn.andersson@linaro.org> Signed-off-by:
-
- 09 Jan, 2018 3 commits
-
-
Wolfram Sang authored
The use of the GPIOF_* flags is deprecated, so don't advertise them here. Document the plain numbers for now until we have a better solution. Signed-off-by:
Wolfram Sang <wsa+renesas@sang-engineering.com> Signed-off-by:
-
Wolfram Sang authored
The use of the GPIOF_* flags is deprecated, so don't advertise them here. Document the plain numbers for now until we have a better solution. Signed-off-by:
-
Maciej S. Szmigiero authored
This commit adds GPIO driver for Winbond Super I/Os. Currently, only W83627UHG model (also known as Nuvoton NCT6627UD) is supported but in the future a support for other Winbond models, too, can be added to the driver. A module parameter "gpios" sets a bitmask of GPIO ports to enable (bit 0 is GPIO1, bit 1 is GPIO2, etc.). One should be careful which ports one tinkers with since some might be managed by the firmware (for functions like powering on and off, sleeping, BIOS recovery, etc.) and some of GPIO port pins are physically shared with other devices included in the Super I/O chip. Signed-off-by:
Maciej S. Szmigiero <mail@maciej.szmigiero.name> Reviewed-by:
Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by:
-
- 08 Jan, 2018 1 commit
-
-
Linus Walleij authored
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:
-
- 05 Jan, 2018 1 commit
-
-
Linus Walleij authored
Some GPIO lines appear named "?" in the lsgpio dump due to their requesting drivers not passing a reasonable label. Most typically this happens if a device tree node just defines gpios = <...> and not foo-gpios = <...>, the former gets named "foo" and the latter gets named "?". However the struct device passed in is always valid so let's just label the GPIO with dev_name() on the device if no proper label was passed. Cc: Reported-by: Jason Kridner <jkridner@beagleboard.org> Reported-by:
Jason Kridner <jkridner@beagleboard.org> Signed-off-by:
-
- 03 Jan, 2018 1 commit
-
-
Linus Walleij authored
As we need to add GPIO lookup tables to the OMAP platforms, we need to reference each GPIO chip with a unique label. Use the GPIO base to name each chip, "gpio-0-31", "gpio-32-63" etc. Cc: Grygorii Strashko <grygorii.strashko@ti.com> Cc: Santosh Shilimkar <ssantosh@kernel.org> Cc: Kevin Hilman <khilman@kernel.org> Cc: linux-omap@vger.kernel.org Signed-off-by:
-
- 02 Jan, 2018 3 commits
-
-
Vladimir Zapolskiy authored
The gpiod_set_transitory() function is publicly exported, and it is expected from it to be ready for usage with optional GPIOs on consumer's side. Signed-off-by:
Vladimir Zapolskiy <vz@mleia.com> Signed-off-by:
-
Vladimir Zapolskiy authored
This non-functional change slightly simplifies the implementation of gpiod_to_chip() function. Signed-off-by:
-
Vladimir Zapolskiy authored
The fix restores a proper validation of an input gpio desc, which might be needed to deal with optional GPIOs correctly. Fixes: 02e47980 ("gpio: Alter semantics of *raw* operations to actually be raw") Signed-off-by:
-
- 28 Dec, 2017 2 commits
-
-
Vasyl Gomonovych authored
The test should be >= ARRAY_SIZE() instead of > ARRAY_SIZE(). Signed-off-by:
Vasyl Gomonovych <gomonovych@gmail.com> Signed-off-by:
-
Linus Walleij authored
This reverts commit 93ebe863. After discussion and review of the v11 patchset, a new approach was found so that this patch is not needed. Signed-off-by:
-
- 21 Dec, 2017 6 commits
-
-
Jonathan Neuschäfer authored
Signed-off-by:
Jonathan Neuschäfer <j.neuschaefer@gmx.net> Signed-off-by:
-
Rasmus Villemoes authored
While we do need macros to be able to return from the "calling" function, we can still factor the checks done by the VALIDATE_DESC* macros into a real helper function. This reduces the backslashtitis, avoids duplicating the logic in the two macros and saves about 1K of generated code: $ scripts/bloat-o-meter drivers/gpio/gpiolib.o.{0,1} add/remove: 1/0 grow/shrink: 0/15 up/down: 104/-1281 (-1177) Function old new delta validate_desc - 104 +104 gpiod_set_value 192 135 -57 gpiod_set_raw_value 125 67 -58 gpiod_direction_output 412 351 -61 gpiod_set_value_cansleep 150 70 -80 gpiod_set_raw_value_cansleep 132 52 -80 gpiod_get_raw_value 139 54 -85 gpiod_set_debounce 226 140 -86 gpiod_direction_output_raw 124 38 -86 gpiod_get_value 161 74 -87 gpiod_cansleep 126 39 -87 gpiod_get_raw_value_cansleep 130 39 -91 gpiod_get_value_cansleep 152 59 -93 gpiod_is_active_low 128 33 -95 gpiod_request 299 184 -115 gpiod_direction_input 386 266 -120 Total: Before=25460, After=24283, chg -4.62% Signed-off-by:Rasmus Villemoes <linux@rasmusvillemoes.dk> Reviewed-by:
-
Joel Stanley authored
The GPIO tools build fails when using a buildroot toolchain that uses musl as it's C library: arm-broomstick-linux-musleabi-gcc -Wp,-MD,./.gpio-event-mon.o.d \ -Wp,-MT,gpio-event-mon.o -O2 -Wall -g -D_GNU_SOURCE \ -Iinclude -D"BUILD_STR(s)=#s" -c -o gpio-event-mon.o gpio-event-mon.c gpio-event-mon.c:30:6: error: unknown type name ‘u_int32_t’; did you mean ‘uint32_t’? u_int32_t handleflags, ^~~~~~~~~ uint32_t The glibc headers installed on my laptop include sys/types.h in unistd.h, but it appears that musl does not. Fixes: 97f69747 ("tools/gpio: add the gpio-event-mon tool") Cc: stable@vger.kernel.org Signed-off-by:Joel Stanley <joel@jms.id.au> Signed-off-by:
-
Timur Tabi authored
pinctrl-msm only accepts an array of GPIOs from 0 to n-1, and it expects each group to support have only one pin (npins == 1). We can support "sparse" GPIO maps if we allow for some groups to have zero pins (npins == 0). These pins are "hidden" from the rest of the driver and gpiolib. Access to unavailable GPIOs is blocked via a request callback. If the requested GPIO is unavailable, -EACCES is returned, which prevents further access to that GPIO. Signed-off-by:
Timur Tabi <timur@codeaurora.org> Reviewed-by:
-
Timur Tabi authored
This reverts commit 72d32000. We cannot blindly query the direction of all GPIOs when the pins are first registered. The get_direction callback normally triggers a read/write to hardware, but we shouldn't be touching the hardware for an individual GPIO until after it's been properly claimed. Signed-off-by:
-
Geert Uytterhoeven authored
R8A7778 is R-Car (not R-Mobile) M1. Signed-off-by:
Geert Uytterhoeven <geert+renesas@glider.be> Acked-by:
Simon Horman <horms+renesas@verge.net.au> Reviewed-by:
-
- 20 Dec, 2017 8 commits
-
-
Pravin Shedge authored
These duplicate includes have been found with scripts/checkincludes.pl but they have been removed manually to avoid removing false positives. Signed-off-by:
Pravin Shedge <pravin.shedge4linux@gmail.com> Acked-by:
Gregory Fong <gregory.0xf0@gmail.com> Signed-off-by:
-
Jonathan Neuschäfer authored
u_int32_t is a non-standard version of uint32_t, that was apparently introduced by BSD. Use uint32_t from stdint.h instead. Signed-off-by:
-
Christophe Leroy authored
A 'perf record' on an app continuously writing in the 'value' attribute show that most of the time is spent in kstrtol() --17.99%--value_store | |--10.17%--kstrtoint | | | |--8.82%--kstrtoll | |--2.50%--gpiod_set_value_cansleep | |--1.82%--u16_gpio_set | |--1.46%--value_store The normal case is to write 0 or 1 in the attribute, therefore this patch avoids the call to kstrtol() in the most common cases Then 'perf record' shows --7.21%--value_store | |--2.69%--u16_gpio_set | |--1.47%--value_store | |--1.08%--gpiod_set_value_cansleep | |--0.60%--mutex_lock | --0.58%--mutex_unlock Signed-off-by:Christophe Leroy <christophe.leroy@c-s.fr> Signed-off-by:
-
Christophe Leroy authored
A bench with 'perf record' shows that most of time spent in value_show() is spent in sprintf() --42.41%--sysfs_kf_read | |--39.73%--dev_attr_show | | | |--38.23%--value_show | | | | | |--29.22%--sprintf | | | | | |--2.94%--gpiod_get_value_cansleep | | | value_show() only returns "0\n" or "1\n", therefore the use of sprintf() can be avoided With this patch we get the following result with 'perf record' --13.89%--sysfs_kf_read | |--10.72%--dev_attr_show | | | |--9.44%--value_show | | | | | |--4.61%--gpiod_get_value_cansleep Signed-off-by: -
Christophe Leroy authored
'value' attribute is supposed to only return 0 or 1 according to the documentation. With today's implementation, if gpiod_get_value_cansleep() fails the printed 'value' is a negative value. This patch ensures that an error is returned on read instead. Signed-off-by:
-
Christophe Leroy authored
The GPIO 'value' attribute is time critical. A small bench with 'perf record' on the app below shows that 80% of the time spent in sysfs_kf_seq_show() is spent in memset() for zeroising the buffer. |--67.48%--sysfs_kf_seq_show | | | |--54.40%--memset | | | |--11.49%--dev_attr_show | | | | | |--10.06%--value_show | | | | | | | |--4.75%--sprintf | | | | | This patch changes the attribute type to prealloc, eliminating the need to zeroise the buffer at each read. 'perf record' gives the following result. |--42.41%--sysfs_kf_read | | | |--39.73%--dev_attr_show | | | | | |--38.23%--value_show | | | | | | | |--29.22%--sprintf | | | | | Test done with the following small app: int main(int argc, char **argv) { int fd = open(argv[1], O_RDONLY); for (;;) { int buf[512]; read(fd, buf, 512); lseek(fd, 0, SEEK_SET); } exit(0); } Signed-off-by: -
Bartosz Golaszewski authored
Users often pass a pointer to a static string to gpiochip_add_data() family of functions. Avoid unnecessary memory allocations with the provided helper routine. While at it: use a ternary operator instead of an if else for brevity. Signed-off-by:
Bartosz Golaszewski <brgl@bgdev.pl> Signed-off-by:
-
Bartosz Golaszewski authored
This string is never modified. Make it const. Signed-off-by:
-
- 08 Dec, 2017 2 commits
-
-
Bartosz Golaszewski authored
The return value of platform_device_register_resndata() on error is an error code converted to pointer with ERR_PTR(), not NULL. Check the return value correctly. Fixes: 8a39f597 ("gpio: mockup: rework device probing") Signed-off-by:
-
Linus Walleij authored
The w1 master driver includes a complete open drain emulation reimplementation among other things. This converts the driver and all board files using it to use GPIO descriptors associated with the device to look up the GPIO wire, as well ass the optional pull-up GPIO line. When probed from the device tree, the driver will just pick descriptors and use them right off. For the two board files in the kernel, we add descriptor lookups so we do not need to keep any old platform data handling around for the GPIO lines. As the platform data is also a state container for this driver, we augment it to contain the GPIO descriptors. w1_gpio_write_bit_dir() and w1_gpio_write_bit_val() are gone since this pair was a reimplementation of open drain emulation which is now handled by gpiolib. The special "linux,open-drain" flag is a bit of mishap here: it has the same semantic as the same flags in I2C: it means that something in the platform is setting up the line as open drain behind our back. We handle this the same way as in I2C. To drive the pull-up, we need to bypass open drain emulation in gpiolib for the line, and this is done by driving it high using gpiod_set_raw_value() which has been augmented to have the semantic of overriding the open drain emulation. We also augment the documentation to reflect the way to pass GPIO descriptors from the machine. Acked-by:
Evgeniy Polyakov <zbr@ioremap.net> Signed-off-by:
-
- 07 Dec, 2017 5 commits
-
-
Linus Walleij authored
-
Quentin Schulz authored
The AXP813 has only two GPIOs. GPIO0 can either be used as a GPIO, an LDO regulator or an ADC. GPIO1 can be used either as a GPIO or an LDO regulator. Moreover, the status bit of the GPIOs when in input mode is not offset by 4 unlike the AXP209. Signed-off-by:
Quentin Schulz <quentin.schulz@free-electrons.com> Acked-by:
Maxime Ripard <maxime.ripard@free-electrons.com> Acked-by:
-
Quentin Schulz authored
To prepare for patches that will add support for a new PMIC that has a different GPIO adc muxing value, add an adc_mux within axp20x_pctl structure and use it. Signed-off-by:
-
Quentin Schulz authored
To prepare for patches that will add support for a new PMIC that has a different GPIO input status register, add a gpio_status_offset within axp20x_pctl structure and use it. Signed-off-by:
Chen-Yu Tsai <wens@csie.org> Signed-off-by:
-
Quentin Schulz authored
This driver used to do only GPIO features of the GPIOs in X-Powers AXP20X. Now that we have migrated everything to the pinctrl subsystem and added pinctrl features, rename everything related to pinctrl from gpio to pctl to ease the understanding of differences between GPIO and pinctrl features. Signed-off-by:
-
