- 24 Sep, 2018 2 commits
-
-
Janusz Krzysztofik authored
In new code introduced by commit b17566a6 ("gpiolib: Implement fast processing path in get/set array"), bitmap index is not updated with next found zero bit position as it should while skipping over pins already processed via fast bitmap path, possibly resulting in an infinite loop. Fix it. Signed-off-by: Janusz Krzysztofik <jmkrzyszt@gmail.com> Tested-by: Marek Szyprowski <m.szyprowski@samsung.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
-
Linus Walleij authored
Give the HTC EGPIO chips unique names, htc-egpio-0, htc-egpio-1 etc, so that it gets possible to associate machine descriptor tables with individual chips. Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
-
- 20 Sep, 2018 8 commits
-
-
Linus Walleij authored
-
Linus Walleij authored
We remove the references to anything but two-cell GPIO specifiers and just mention that controllers need to specify their bindings and that we strongly recommend two-cell bindings. Cc: devicetree@vger.kernel.org Reviewed-by: Rob Herring <robh@kernel.org> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
-
Linus Walleij authored
In 2011 the commit bf859f84 ("gpio/dt: Refine GPIO device tree binding") introduced an experimental BNF notation for defining a regular grammar for the GPIO phandles used by different devices. This was an interesting approach, and shows that we have long nutured the idea to formally verify device tree files using regular grammar. Most if not all other bindings use natural language to define the bindings, and the recent thinking for verifying device tree files is to use JSON schemas in separate definitions. Cut the BNF business and replace it with natural language so that it becomes more human-readable for now. Cc: devicetree@vger.kernel.org Cc: Grant Likely <grant.likely@secretlab.ca> Cc: Kumar Gala <galak@kernel.crashing.org> Reviewed-by: Rob Herring <robh@kernel.org> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
-
Andrew F. Davis authored
These defines, structs and inline functions are used only internally by the driver, they do not belong in platform_data. Move them. Signed-off-by: Andrew F. Davis <afd@ti.com> Tested-by: Keerthy <j-keerthy@ti.com> Acked-by: Keerthy <j-keerthy@ti.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
-
Andrew F. Davis authored
This macro does nothing and has only one user, remove it. Signed-off-by: Andrew F. Davis <afd@ti.com> Tested-by: Keerthy <j-keerthy@ti.com> Acked-by: Keerthy <j-keerthy@ti.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
-
Andrew F. Davis authored
Previously we created a controller structure per bank of GPIO pins. This has since been changed to one per controller, but the allocation size was not changed. Fix this here. This also leaves the variable 'nbank' unused, instead of removing it, move it down and use it to clean up a loop. For loops with multiple initializers and/or iteration expressions, especially ones that don't use those loop counters are quite hard to follow, fix this. Signed-off-by: Andrew F. Davis <afd@ti.com> Tested-by: Keerthy <j-keerthy@ti.com> Acked-by: Keerthy <j-keerthy@ti.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
-
Andrew F. Davis authored
Use dev_name to get a unique label and use -1 for a base to get our selection automatically. We pull in all GPIOs per chip now so this does not have the effect of out of order labels like before. We do these both together so we can drop all the static data in one patch. This also lets us normalize the return paths as we don't need any cleanup after this change. Signed-off-by: Andrew F. Davis <afd@ti.com> Tested-by: Keerthy <j-keerthy@ti.com> Acked-by: Keerthy <j-keerthy@ti.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
-
Andrew F. Davis authored
This was added as part of the patch in the fixes below, but was not needed or used, remove this here. Fixes: 8e11047b ("gpio: davinci: Add support for multiple GPIO controllers") Tested-by: Keerthy <j-keerthy@ti.com> Acked-by: Keerthy <j-keerthy@ti.com> Signed-off-by: Andrew F. Davis <afd@ti.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
-
- 17 Sep, 2018 15 commits
-
-
Linus Walleij authored
A bunch of core gpiolib files still include the <linux/gpio.h> legacy API header for no good reason. After this only the gpiolib-legacy.c file includes it, which is fine. The sysfs ABI code has a pointless wrapper function around gpio_to_desc() we can just loose. Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
-
Linus Walleij authored
Just use the SPDX license tag for these drivers. Cc: patches@opensource.cirrus.com Cc: Charles Keepax <ckeepax@opensource.cirrus.com> Cc: Mark Brown <broonie@kernel.org> Acked-by: Richard Fitzgerald <rf@opensource.cirrus.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
-
Linus Walleij authored
These are GPIO drivers so just include <linux/gpio/driver.h>. Cc: patches@opensource.cirrus.com Cc: Charles Keepax <ckeepax@opensource.cirrus.com> Cc: Mark Brown <broonie@kernel.org> Acked-by: Richard Fitzgerald <rf@opensource.cirrus.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
-
Linus Walleij authored
Just use the SPDX license tag for this file. Cc: Kamlakant Patel <kamlakant.patel@cavium.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
-
Linus Walleij authored
This is a GPIO driver so include only <linux/gpio/driver.h>. Cc: Kamlakant Patel <kamlakant.patel@cavium.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
-
Linus Walleij authored
Just use the SPDX header for the license. Cc: Daniel Drake <drake@endlessm.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
-
Linus Walleij authored
This is a GPIO driver so include only <linux/gpio/driver.h>. Cc: Daniel Drake <drake@endlessm.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
-
Linus Walleij authored
Just use the SPDX header for the license. Cc: Lars Poeschel <poeschel@lemonage.de> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
-
Linus Walleij authored
This is a GPIO driver so include only <linux/gpio/driver.h>. Cc: Lars Poeschel <poeschel@lemonage.de> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
-
Linus Walleij authored
Just use the SPDX header for the license. Acked-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
-
Linus Walleij authored
This is a GPIO driver so include only <linux/gpio/driver.h>. Acked-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
-
Linus Walleij authored
This API is not used anywhere in the kernel and has remained unused for years after being introduced. Over time, we have developed a subsystem to deal with pin control and this now managed pull up/down. Delete the old and unused API. If this platform needs it, we should implement a proper pin controller for it instead. Cc: Yoichi Yuasa <yuasa@linux-mips.org> Cc: Ralf Baechle <ralf@linux-mips.org> Acked-by: Paul Burton <paul.burton@mips.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
-
Linus Walleij authored
This switches this file to use the SPDX license tag. Cc: Yoichi Yuasa <yuasa@linux-mips.org> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
-
Linus Walleij authored
This is a GPIO driver so include only <linux/gpio/driver.h>. Cc: Yoichi Yuasa <yuasa@linux-mips.org> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
-
Hans Verkuil authored
Some drivers use a single irqchip for multiple gpiochips. As a result the irqchip hooks are overridden for the first gpiochip that was added, but for the other gpiochip instances this should not happen again, otherwise we would go into an infinite recursion. Check for this, but also log a message that the driver should be fixed since this is bad practice. Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com> Tested-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
-
- 14 Sep, 2018 1 commit
-
-
Wolfram Sang authored
EINVAL is very generic, use ENOTSUPP in case the gpiochip does not provide this function. While removing the assignment from the 'status' variable, use better indentation in the declaration block. Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com> Reviewed-by: Simon Horman <horms+renesas@verge.net.au> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
-
- 13 Sep, 2018 6 commits
-
-
Janusz Krzysztofik authored
Certain GPIO descriptor arrays returned by gpio_get_array() may contain information on direct mapping of array members to pins of a single GPIO chip in hardware order. In such cases, bitmaps of values can be passed directly from/to the chip's .get/set_multiple() callbacks without wasting time on iterations. Add respective code to gpiod_get/set_array_bitmap_complex() functions. Pins not applicable for fast path are processed as before, skipping over the 'fast' ones. Cc: Jonathan Corbet <corbet@lwn.net> Signed-off-by: Janusz Krzysztofik <jmkrzyszt@gmail.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
-
Janusz Krzysztofik authored
In order to make use of array info obtained from gpiod_get_array() and speed up processing of arrays matching single GPIO chip layout, that information must be passed to get/set array functions. Extend the functions' API with that additional parameter and update all users. Pass NULL if a user builds an array itself from single GPIOs. Cc: Jonathan Corbet <corbet@lwn.net> Cc: Miguel Ojeda Sandonis <miguel.ojeda.sandonis@gmail.com> Cc: Geert Uytterhoeven <geert@linux-m68k.org> Cc: Sebastien Bourdelin <sebastien.bourdelin@savoirfairelinux.com> Cc: Lukas Wunner <lukas@wunner.de> Cc: Peter Korsgaard <peter.korsgaard@barco.com> Cc: Peter Rosin <peda@axentia.se> Cc: Andrew Lunn <andrew@lunn.ch> Cc: Florian Fainelli <f.fainelli@gmail.com> Cc: "David S. Miller" <davem@davemloft.net> Cc: Rojhalat Ibrahim <imr@rtschenk.de> Cc: Dominik Brodowski <linux@dominikbrodowski.net> Cc: Russell King <rmk+kernel@armlinux.org.uk> Cc: Kishon Vijay Abraham I <kishon@ti.com> Cc: Tony Lindgren <tony@atomide.com> Cc: Lars-Peter Clausen <lars@metafoo.de> Cc: Michael Hennerich <Michael.Hennerich@analog.com> Cc: Jonathan Cameron <jic23@kernel.org> Cc: Hartmut Knaack <knaack.h@gmx.de> Cc: Peter Meerwald-Stadler <pmeerw@pmeerw.net> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: Jiri Slaby <jslaby@suse.com> Cc: Yegor Yefremov <yegorslists@googlemail.com> Cc: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by: Janusz Krzysztofik <jmkrzyszt@gmail.com> Acked-by: Ulf Hansson <ulf.hansson@linaro.org> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
-
Janusz Krzysztofik authored
Certain GPIO array lookup results may map directly to GPIO pins of a single GPIO chip in hardware order. If that condition is recognized and handled efficiently, significant performance gain of get/set array functions may be possible. While processing a request for an array of GPIO descriptors, identify those which represent corresponding pins of a single GPIO chip. Skip over pins which require open source or open drain special processing. Moreover, identify pins which require inversion. Pass a pointer to that information with the array to the caller so it can benefit from enhanced performance as soon as get/set array functions can accept and make efficient use of it. Cc: Jonathan Corbet <corbet@lwn.net> Signed-off-by: Janusz Krzysztofik <jmkrzyszt@gmail.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
-
Janusz Krzysztofik authored
Most users of get/set array functions iterate consecutive bits of data, usually a single integer, while processing array of results obtained from, or building an array of values to be passed to those functions. Save time wasted on those iterations by changing the functions' API to accept bitmaps. All current users are updated as well. More benefits from the change are expected as soon as planned support for accepting/passing those bitmaps directly from/to respective GPIO chip callbacks if applicable is implemented. Cc: Jonathan Corbet <corbet@lwn.net> Cc: Miguel Ojeda Sandonis <miguel.ojeda.sandonis@gmail.com> Cc: Sebastien Bourdelin <sebastien.bourdelin@savoirfairelinux.com> Cc: Lukas Wunner <lukas@wunner.de> Cc: Peter Korsgaard <peter.korsgaard@barco.com> Cc: Peter Rosin <peda@axentia.se> Cc: Andrew Lunn <andrew@lunn.ch> Cc: Florian Fainelli <f.fainelli@gmail.com> Cc: "David S. Miller" <davem@davemloft.net> Cc: Rojhalat Ibrahim <imr@rtschenk.de> Cc: Dominik Brodowski <linux@dominikbrodowski.net> Cc: Russell King <rmk+kernel@armlinux.org.uk> Cc: Kishon Vijay Abraham I <kishon@ti.com> Cc: Tony Lindgren <tony@atomide.com> Cc: Lars-Peter Clausen <lars@metafoo.de> Cc: Michael Hennerich <Michael.Hennerich@analog.com> Cc: Jonathan Cameron <jic23@kernel.org> Cc: Hartmut Knaack <knaack.h@gmx.de> Cc: Peter Meerwald-Stadler <pmeerw@pmeerw.net> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: Jiri Slaby <jslaby@suse.com> Cc: Yegor Yefremov <yegorslists@googlemail.com> Cc: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by: Janusz Krzysztofik <jmkrzyszt@gmail.com> Acked-by: Ulf Hansson <ulf.hansson@linaro.org> 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>
-
Uwe Kleine-König authored
This concerns gpio edge detection for GPIO IRQs used from userspace for GPIO event listeners. Trying to work out the right event if it's not sure that the examined gpio actually moved is impossible. Consider two gpios "gpioA" and "gpioB" that share an interrupt. gpioA's irq should trigger on any edge, gpioB's on a falling edge. If now the common irq fires and both gpio lines are high, there are several possibilities that could have happend: a) gpioA just had a low-to-high edge b) gpioB just had a high-to-low-to-high spike c) a combination of both a) and b) While c) is unlikely (in most setups) a) and b) alone are bad enough. Currently the code assumes case a) unconditionally and doesn't report an event for gpioB. Note that even if there is no irq sharing involved a spike for a gpio might not result in an event if it's configured to trigger for a single edge only. The only way to improve this is to drop support for interrupt sharing. This way a spike results in an event for the right gpio at least. Note that apart from dropping IRQF_SHARED this effectively undoes commit df1e76f2 ("gpiolib: skip unwanted events, don't convert them to opposite edge"). This obviously breaks setups that rely on interrupt sharing, but given that this cannot be reliable, this is probably an acceptable trade-off. Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> [Assuming there are no users of interrupt sharing yet] Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
-
Geert Uytterhoeven authored
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
-
- 12 Sep, 2018 2 commits
-
-
Linus Walleij authored
Just use the SPDX identifier for the license. Acked-by: Stefan Agner <stefan@agner.ch> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
-
Linus Walleij authored
This is a GPIO driver so only include <linux/gpio/driver.h>. Acked-by: Stefan Agner <stefan@agner.ch> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
-
- 11 Sep, 2018 2 commits
-
-
Wolfram Sang authored
The ';' was missing. And cosmetic: there was a space too much. Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com> Reviewed-by: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
-
Linus Walleij authored
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>
-
- 10 Sep, 2018 4 commits
-
-
Hans Verkuil authored
Since this driver does not use the gpiolib irqchip helpers it will have to allocate the irq resources and irq_en/disable itself. Use the new gpiochip_req/relres_irq helpers to request/release all the resources. Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com> Cc: Ray Jui <rjui@broadcom.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
-
Hans Verkuil authored
Document these new functions. Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
-
Hans Verkuil authored
When using the gpiolib irqchip helpers install irq_enable/disable hooks for the irqchip to ensure that gpiolib knows when the irq is enabled or disabled, allowing drivers to disable the irq and then use it as an output pin, and later switch the direction to input and re-enable the irq. Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
-
Hans Verkuil authored
GPIO drivers call gpiochip_(un)lock_as_irq whenever they want to use a gpio as an interrupt. This is done when the irq is requested and it marks the gpio as in use by an interrupt. This is problematic for cases where a gpio pin is used as an interrupt pin, then, after the irq is disabled, is used as a regular gpio pin. Currently it is not possible to do this other than by first freeing the interrupt so gpiochip_unlock_as_irq is called, since an attempt to switch the gpio direction for output will fail since gpiolib believes that the gpio is in use for an interrupt and it does not know that it the irq is actually disabled. There are currently two drivers that would like to be able to do this: the tda998x_drv.c driver where a regular gpio pin needs to be temporarily reconfigured as an interrupt pin during CEC calibration, and the cec-gpio driver where you want to configure the gpio pin as an interrupt while waiting for traffic over the CEC bus, or as a regular pin when receiving or transmitting a CEC message. The solution is to add a new flag that is set when the irq is enabled, and have gpiod_direction_output check for that flag. We also add functions that drivers that do not use GPIOLIB_IRQCHIP can call when they enable/disable the irq. Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
-