- 21 Jan, 2018 1 commit
-
-
Linus Walleij authored
Simple etraneous letter. Reported-by: Alexander Stein <alexander.stein@systec-electronic.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
-
- 19 Jan, 2018 1 commit
-
-
Linus Walleij authored
-
- 18 Jan, 2018 1 commit
-
-
Linus Walleij authored
Update a slew of documentation files with the latest changes in the API/ABI. Again stress that sysfs is deprecated. Add all new flags and clean up and move some text. Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
-
- 17 Jan, 2018 8 commits
-
-
Colin Ian King authored
The initialized value stored in pointer desc is never read as it is updated in the first executable statement in the function. This is therefore redundant and can be removed. Cleans up clang warning: drivers/gpio/gpiolib.c:3710:20: warning: Value stored to 'desc' during its initialization is never read Signed-off-by: Colin Ian King <colin.king@canonical.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
-
Linus Walleij authored
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: 6a537d48 ("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>
-
Markus Elfring authored
The local variable "irq" will eventually be set to an appropriate value a bit later. Thus omit the explicit initialisation at the beginning. Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
-
Markus Elfring authored
Move the assignment for the local variable "irq" so that its setting will only be performed directly before it is checked by this function. Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
-
Markus Elfring authored
Replace the specification of a data structure by a pointer dereference as the parameter for the operator "sizeof" to make the corresponding size determination a bit safer according to the Linux coding style convention. This issue was detected by using the Coccinelle software. Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
-
Markus Elfring authored
A single character (line break) should be put into a sequence. Thus use the corresponding function "seq_putc". This issue was detected by using the Coccinelle software. Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
-
Linus Walleij authored
Sometimes a GPIO is fetched with NULL as parent device, and that is just fine. So under these circumstances, avoid using dev_name() to provide a name for the GPIO line. Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
-
Patrice Chotard authored
Move the workaround from stmpe_gpio_irq_unmask() which is executed in atomic context to stmpe_gpio_irq_sync_unlock() which is not. It fixes the following issue: [ 1.500000] BUG: scheduling while atomic: swapper/1/0x00000002 [ 1.500000] CPU: 0 PID: 1 Comm: swapper Not tainted 4.15.0-rc2-00020-gbd4301f-dirty #28 [ 1.520000] Hardware name: STM32 (Device Tree Support) [ 1.520000] [<0000bfc9>] (unwind_backtrace) from [<0000b347>] (show_stack+0xb/0xc) [ 1.530000] [<0000b347>] (show_stack) from [<0001fc49>] (__schedule_bug+0x39/0x58) [ 1.530000] [<0001fc49>] (__schedule_bug) from [<00168211>] (__schedule+0x23/0x2b2) [ 1.550000] [<00168211>] (__schedule) from [<001684f7>] (schedule+0x57/0x64) [ 1.550000] [<001684f7>] (schedule) from [<0016a513>] (schedule_timeout+0x137/0x164) [ 1.550000] [<0016a513>] (schedule_timeout) from [<00168b91>] (wait_for_common+0x8d/0xfc) [ 1.570000] [<00168b91>] (wait_for_common) from [<00139753>] (stm32f4_i2c_xfer+0xe9/0xfe) [ 1.580000] [<00139753>] (stm32f4_i2c_xfer) from [<00138545>] (__i2c_transfer+0x111/0x148) [ 1.590000] [<00138545>] (__i2c_transfer) from [<001385cf>] (i2c_transfer+0x53/0x70) [ 1.590000] [<001385cf>] (i2c_transfer) from [<001388a5>] (i2c_smbus_xfer+0x12f/0x36e) [ 1.600000] [<001388a5>] (i2c_smbus_xfer) from [<00138b49>] (i2c_smbus_read_byte_data+0x1f/0x2a) [ 1.610000] [<00138b49>] (i2c_smbus_read_byte_data) from [<00124fdd>] (__stmpe_reg_read+0xd/0x24) [ 1.620000] [<00124fdd>] (__stmpe_reg_read) from [<001252b3>] (stmpe_reg_read+0x19/0x24) [ 1.630000] [<001252b3>] (stmpe_reg_read) from [<0002c4d1>] (unmask_irq+0x17/0x22) [ 1.640000] [<0002c4d1>] (unmask_irq) from [<0002c57f>] (irq_startup+0x6f/0x78) [ 1.650000] [<0002c57f>] (irq_startup) from [<0002b7a1>] (__setup_irq+0x319/0x47c) [ 1.650000] [<0002b7a1>] (__setup_irq) from [<0002bad3>] (request_threaded_irq+0x6b/0xe8) [ 1.660000] [<0002bad3>] (request_threaded_irq) from [<0002d0b9>] (devm_request_threaded_irq+0x3b/0x6a) [ 1.670000] [<0002d0b9>] (devm_request_threaded_irq) from [<001446e7>] (mmc_gpiod_request_cd_irq+0x49/0x8a) [ 1.680000] [<001446e7>] (mmc_gpiod_request_cd_irq) from [<0013d45d>] (mmc_start_host+0x49/0x60) [ 1.690000] [<0013d45d>] (mmc_start_host) from [<0013e40b>] (mmc_add_host+0x3b/0x54) [ 1.700000] [<0013e40b>] (mmc_add_host) from [<00148119>] (mmci_probe+0x4d1/0x60c) [ 1.710000] [<00148119>] (mmci_probe) from [<000f903b>] (amba_probe+0x7b/0xbe) [ 1.720000] [<000f903b>] (amba_probe) from [<001170e5>] (driver_probe_device+0x169/0x1f8) [ 1.730000] [<001170e5>] (driver_probe_device) from [<001171b7>] (__driver_attach+0x43/0x5c) [ 1.740000] [<001171b7>] (__driver_attach) from [<0011618d>] (bus_for_each_dev+0x3d/0x46) [ 1.740000] [<0011618d>] (bus_for_each_dev) from [<001165cd>] (bus_add_driver+0xcd/0x124) [ 1.740000] [<001165cd>] (bus_add_driver) from [<00117713>] (driver_register+0x4d/0x7a) [ 1.760000] [<00117713>] (driver_register) from [<001fc765>] (do_one_initcall+0xbd/0xe8) [ 1.770000] [<001fc765>] (do_one_initcall) from [<001fc88b>] (kernel_init_freeable+0xfb/0x134) [ 1.780000] [<001fc88b>] (kernel_init_freeable) from [<00167ee3>] (kernel_init+0x7/0x9c) [ 1.790000] [<00167ee3>] (kernel_init) from [<00009b65>] (ret_from_fork+0x11/0x2c) Cc: stable@vger.kernel.org Signed-off-by: Alexandre TORGUE <alexandre.torgue@st.com> Signed-off-by: Patrice Chotard <patrice.chotard@st.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
-
- 14 Jan, 2018 4 commits
-
-
Linus Walleij authored
This driver has no business including <linux/gpio.h>, it is a driver so include <linux/gpio/driver.h>. Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
-
Linus Walleij authored
These drivers has no business including <linux/gpio.h>, they are drivers so include <linux/gpio/driver.h>. Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
-
Linus Walleij authored
This driver has no business including <linux/gpio.h>, it is a driver so include <linux/gpio/driver.h>. Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
-
Linus Walleij authored
This driver has no business including <linux/gpio.h>, it is a driver so include <linux/gpio/driver.h>. Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
-
- 13 Jan, 2018 8 commits
-
-
Linus Walleij authored
This driver has no business including <linux/gpio.h>, it is a driver so include <linux/gpio/driver.h>. Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
-
Linus Walleij authored
This driver has no business including <linux/gpio.h>, it is a driver so include <linux/gpio/driver.h>. GPIOF_DIR_IN/GPIOF_DIR_OUT are for consumers and should not be used in drivers to use just 1/0 instead. Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
-
Linus Walleij authored
This driver has no business including <linux/gpio.h>, it is a driver so include <linux/gpio/driver.h>. Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
-
Linus Walleij authored
This driver has no business including <linux/gpio.h>, it is a driver so include <linux/gpio/driver.h>. Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
-
Linus Walleij authored
This is a GPIO driver so it should definately include <linux/gpio/driver.h>. We want to get rid of <linux/of_gpio.h> but that will take a bit longer. Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
-
Linus Walleij authored
This driver has no business including <linux/gpio.h>, it is a driver so include <linux/gpio/driver.h>. Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
-
Linus Walleij authored
This driver has no business including <linux/gpio.h>, it is a driver so include <linux/gpio/driver.h>. Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
-
Linus Walleij authored
This driver has no business including <linux/gpio.h> or <linux/of_gpio.h>. Cut them and include <linux/gpio/driver.h> and <linux/gpio/consumer.h> which is it they really needs. Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
-
- 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 <linus.walleij@linaro.org>
-
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 <linus.walleij@linaro.org>
-
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: Linus Walleij <linus.walleij@linaro.org>
-
- 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: Linus Walleij <linus.walleij@linaro.org>
-
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: Linus Walleij <linus.walleij@linaro.org>
-
- 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: Linus Walleij <linus.walleij@linaro.org>
-
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: Linus Walleij <linus.walleij@linaro.org>
-
- 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: Linus Walleij <linus.walleij@linaro.org>
-
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: Linus Walleij <linus.walleij@linaro.org>
-
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: Linus Walleij <linus.walleij@linaro.org>
-
- 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: Linus Walleij <linus.walleij@linaro.org>
-
- 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: Linus Walleij <linus.walleij@linaro.org>
-
- 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: Linus Walleij <linus.walleij@linaro.org>
-
- 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: Linus Walleij <linus.walleij@linaro.org>
-
Vladimir Zapolskiy authored
This non-functional change slightly simplifies the implementation of gpiod_to_chip() function. Signed-off-by: Vladimir Zapolskiy <vz@mleia.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
-
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: Vladimir Zapolskiy <vz@mleia.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
-