- 23 1月, 2018 2 次提交
-
-
由 Linus Walleij 提交于
Add a hardirq handler to the GPIO userspace event loop, making sure to pick up the timestamp there, as close as possible in time relative to the actual event causing the interrupt. Tested with a simple pushbutton GPIO on ux500 and seems to work fine. Cc: Bartosz Golaszewski <brgl@bgdev.pl> Reviewed-by: NFelipe Balbi <felipe.balbi@linux.intel.com> Reported-by: NFelipe Balbi <felipe.balbi@linux.intel.com> Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
-
由 Linus Walleij 提交于
The GPIO event descriptor was leaking kernel stack to userspace because we don't zero the variable before use. Ooops. Fix this. Cc: stable@vger.kernel.org Reported-by: NArnd Bergmann <arnd@arndb.de> Reviewed-by: NBartosz Golaszewski <brgl@bgdev.pl> Reviewed-by: NArnd Bergmann <arnd@arndb.de> Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
-
- 17 1月, 2018 8 次提交
-
-
由 Colin Ian King 提交于
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: NColin Ian King <colin.king@canonical.com> Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
-
由 Linus Walleij 提交于
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: NHeiner Kallweit <hkallweit1@gmail.com> Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
-
由 Markus Elfring 提交于
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: NMarkus Elfring <elfring@users.sourceforge.net> Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
-
由 Markus Elfring 提交于
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: NMarkus Elfring <elfring@users.sourceforge.net> Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
-
由 Markus Elfring 提交于
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: NMarkus Elfring <elfring@users.sourceforge.net> Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
-
由 Markus Elfring 提交于
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: NMarkus Elfring <elfring@users.sourceforge.net> Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
-
由 Linus Walleij 提交于
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: NLinus Walleij <linus.walleij@linaro.org>
-
由 Patrice Chotard 提交于
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: NAlexandre TORGUE <alexandre.torgue@st.com> Signed-off-by: NPatrice Chotard <patrice.chotard@st.com> Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
-
- 14 1月, 2018 12 次提交
-
-
由 Linus Walleij 提交于
This driver has no business including <linux/gpio.h>, it is a driver so include <linux/gpio/driver.h>. Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
-
由 Linus Walleij 提交于
These drivers has no business including <linux/gpio.h>, they are drivers so include <linux/gpio/driver.h>. Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
-
由 Linus Walleij 提交于
This driver has no business including <linux/gpio.h>, it is a driver so include <linux/gpio/driver.h>. Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
-
由 Linus Walleij 提交于
This driver has no business including <linux/gpio.h>, it is a driver so include <linux/gpio/driver.h>. Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
-
由 Linus Walleij 提交于
This driver has no business including <linux/gpio.h>, it is a driver so include <linux/gpio/driver.h>. Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
-
由 Linus Walleij 提交于
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: NLinus Walleij <linus.walleij@linaro.org>
-
由 Linus Walleij 提交于
This driver has no business including <linux/gpio.h>, it is a driver so include <linux/gpio/driver.h>. Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
-
由 Linus Walleij 提交于
This driver has no business including <linux/gpio.h>, it is a driver so include <linux/gpio/driver.h>. Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
-
由 Linus Walleij 提交于
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: NLinus Walleij <linus.walleij@linaro.org>
-
由 Linus Walleij 提交于
This driver has no business including <linux/gpio.h>, it is a driver so include <linux/gpio/driver.h>. Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
-
由 Linus Walleij 提交于
This driver has no business including <linux/gpio.h>, it is a driver so include <linux/gpio/driver.h>. Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
-
由 Linus Walleij 提交于
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: NLinus Walleij <linus.walleij@linaro.org>
-
- 12 1月, 2018 4 次提交
-
-
由 Linus Walleij 提交于
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: NLinus Walleij <linus.walleij@linaro.org>
-
由 Linus Walleij 提交于
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: NLinus Walleij <linus.walleij@linaro.org>
-
由 Linus Walleij 提交于
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: NLinus Walleij <linus.walleij@linaro.org>
-
由 Linus Walleij 提交于
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: NLinus Walleij <linus.walleij@linaro.org>
-
- 11 1月, 2018 2 次提交
-
-
由 Wei Yongjun 提交于
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: NWei Yongjun <weiyongjun1@huawei.com> Acked-by: NDavid Daney <david.daney@cavium.com> Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
-
由 Arnd Bergmann 提交于
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: NArnd Bergmann <arnd@arndb.de> Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
-
- 10 1月, 2018 2 次提交
-
-
由 William Breathitt Gray 提交于
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: NWilliam Breathitt Gray <vilhelm.gray@gmail.com> Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
-
由 Stephen Boyd 提交于
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: NStephen Boyd <sboyd@codeaurora.org> Acked-by: NBjorn Andersson <bjorn.andersson@linaro.org> Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
-
- 09 1月, 2018 3 次提交
-
-
由 Wolfram Sang 提交于
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: NWolfram Sang <wsa+renesas@sang-engineering.com> Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
-
由 Maciej S. Szmigiero 提交于
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: NMaciej S. Szmigiero <mail@maciej.szmigiero.name> Reviewed-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
-
由 Linus Walleij 提交于
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: NRob Herring <robh@kernel.org> Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
-
- 05 1月, 2018 1 次提交
-
-
由 Linus Walleij 提交于
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: NJason Kridner <jkridner@beagleboard.org> Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
-
- 03 1月, 2018 1 次提交
-
-
由 Linus Walleij 提交于
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: NLinus Walleij <linus.walleij@linaro.org>
-
- 02 1月, 2018 3 次提交
-
-
由 Vladimir Zapolskiy 提交于
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: NVladimir Zapolskiy <vz@mleia.com> Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
-
由 Vladimir Zapolskiy 提交于
This non-functional change slightly simplifies the implementation of gpiod_to_chip() function. Signed-off-by: NVladimir Zapolskiy <vz@mleia.com> Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
-
由 Vladimir Zapolskiy 提交于
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: NVladimir Zapolskiy <vz@mleia.com> Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
-
- 28 12月, 2017 2 次提交
-
-
由 Vasyl Gomonovych 提交于
The test should be >= ARRAY_SIZE() instead of > ARRAY_SIZE(). Signed-off-by: NVasyl Gomonovych <gomonovych@gmail.com> Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
-
由 Linus Walleij 提交于
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: NLinus Walleij <linus.walleij@linaro.org>
-