#
74975b4f |
|
26-Sep-2023 |
Bartosz Golaszewski <bartosz.golaszewski@linaro.org> |
gpio: acpi: remove acpi_get_and_request_gpiod() With no more users, we can remove acpi_get_and_request_gpiod(). Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org> Reviewed-by: From: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com>
|
#
f42dafe3 |
|
03-Sep-2023 |
Bartosz Golaszewski <bartosz.golaszewski@linaro.org> |
gpiolib: unexport gpiod_set_transitory() There are no and never have been any users of gpiod_set_transitory() outside the core GPIOLIB code. Make it private. Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org> Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
|
#
380c7ba3 |
|
08-Feb-2023 |
Andy Shevchenko <andriy.shevchenko@linux.intel.com> |
gpiolib: Clean up headers There is a few things done: - include only the headers we are direct user of - when pointer is in use, provide a forward declaration - add missing headers - group generic headers and subsystem headers - sort each group alphabetically Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
|
#
5b191197 |
|
07-Feb-2023 |
Andy Shevchenko <andriy.shevchenko@linux.intel.com> |
gpiolib: Group forward declarations in consumer.h For better maintenance group the forward declarations together. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
|
#
91e5ae95 |
|
07-Feb-2023 |
Andy Shevchenko <andriy.shevchenko@linux.intel.com> |
gpiolib: Deduplicate forward declarations in consumer.h The struct fwnode_handle pointer is used in both branches of ifdeffery, no need to have a copy of the same in each of them, just make it global. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
|
#
650f2dc9 |
|
19-Dec-2022 |
Dmitry Torokhov <dmitry.torokhov@gmail.com> |
gpiolib: of: remove [devm_]gpiod_get_from_of_node() APIs Now that everyone is using [devm_]fwnode_gpiod_get[_index]() APIs, remove OF-specific [devm_]gpiod_get_from_of_node(). Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
|
#
2fe8e1dc |
|
02-Sep-2022 |
Dmitry Torokhov <dmitry.torokhov@gmail.com> |
gpiolib: remove devm_fwnode_get_[index_]gpiod_from_child() Now that there are no more users of these APIs in the kernel we can remove them. Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com> Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
|
#
0eadd36d |
|
04-Sep-2022 |
Dmitry Torokhov <dmitry.torokhov@gmail.com> |
gpiolib: make fwnode_get_named_gpiod() static There are no external users of fwnode_get_named_gpiod() anymore, so let's stop exporting it and mark it as static. Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com> Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> Signed-off-by: Bartosz Golaszewski <brgl@bgdev.pl>
|
#
42112dd7 |
|
22-Apr-2022 |
Dipen Patel <dipenp@nvidia.com> |
gpiolib: Add HTE support Some GPIO chip can provide hardware timestamp support on its GPIO lines , in order to support that, additional API needs to be added which can talk to both GPIO chip and HTE (hardware timestamping engine) providers if there is any dependencies. This patch introduces optional hooks to enable and disable hardware timestamping related features in the GPIO controller chip. Signed-off-by: Dipen Patel <dipenp@nvidia.com> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Reported-by: kernel test robot <lkp@intel.com> Signed-off-by: Thierry Reding <treding@nvidia.com>
|
#
0c2cae09 |
|
17-Mar-2022 |
Andy Shevchenko <andriy.shevchenko@linux.intel.com> |
gpiolib: acpi: Convert type for pin to be unsigned A pin that comes from ACPI tables is of unsigned type. This also applies to the internal APIs which use unsigned int to store the pin. Convert type for pin to be unsigned in the places where it's not yet true. While at it, add a stub for acpi_get_and_request_gpiod() for the sake of consistency in the APIs. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
|
#
4398693a |
|
08-Feb-2022 |
Bartosz Golaszewski <brgl@bgdev.pl> |
gpiolib: make struct comments into real kernel docs We have several comments that start with '/**' but don't conform to the kernel doc standard. Add proper detailed descriptions for the affected definitions and move the docs from the forward declarations to the struct definitions where applicable. Reported-by: Randy Dunlap <rdunlap@infradead.org> Signed-off-by: Bartosz Golaszewski <brgl@bgdev.pl> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Tested-by: Randy Dunlap <rdunlap@infradead.org>
|
#
507805b8 |
|
10-Nov-2021 |
Andy Shevchenko <andriy.shevchenko@linux.intel.com> |
gpiolib: acpi: Remove never used devm_acpi_dev_remove_driver_gpios() Remove never used devm_acpi_dev_remove_driver_gpios(). Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com>
|
#
b3907521 |
|
03-Aug-2021 |
Andy Shevchenko <andriy.shevchenko@linux.intel.com> |
gpiolib: Deduplicate forward declaration in the consumer.h header struct acpi_device is repeated in two branches of ifdeffery. Move it out and hence deduplicate. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
|
#
e6ae9a83 |
|
28-Jul-2021 |
Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com> |
gpiolib: constify passed device_node pointer Several gpiolib functions receive pointer to struct device_node which is later passed to OF functions. These OF functions accept already pointer to const, so gpiolib can follow similar approach to indicate they are not modifying the struct device_node. Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com> Reviewed-by: Rob Herring <robh@kernel.org> Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
|
#
43582f29 |
|
03-Jun-2021 |
Daniel Scally <djrscally@gmail.com> |
gpiolib: acpi: Introduce acpi_get_and_request_gpiod() helper We need to be able to translate GPIO resources in an ACPI device's _CRS into GPIO descriptor array. Those are represented in _CRS as a pathname to a GPIO device plus the pin's index number: the acpi_get_gpiod() function is perfect for that purpose. As it's currently only used internally within the GPIO layer, provide and export a wrapper function that additionally holds a reference to the GPIO device. Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> Signed-off-by: Daniel Scally <djrscally@gmail.com> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
|
#
62d5247d |
|
25-Feb-2021 |
Andy Shevchenko <andriy.shevchenko@linux.intel.com> |
gpiolib: acpi: Add ACPI_GPIO_QUIRK_ABSOLUTE_NUMBER quirk On some systems the ACPI tables has wrong pin number and instead of having a relative one it provides an absolute one in the global GPIO number space. Add ACPI_GPIO_QUIRK_ABSOLUTE_NUMBER quirk to cope with such cases. Fixes: ba8c90c61847 ("gpio: pca953x: Override IRQ for one of the expanders on Galileo Gen 2") Depends-on: 0ea683931adb ("gpio: dwapb: Convert driver to using the GPIO-lib-based IRQ-chip") Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Acked-by: Mika Westerberg <mika.westerberg@linux.intel.com> Acked-by: Linus Walleij <linus.walleij@linaro.org>
|
#
13daf489 |
|
09-Nov-2020 |
Andy Shevchenko <andriy.shevchenko@linux.intel.com> |
gpiolib: Replace unsigned by unsigned int Replace unsigned by unsigned int in GPIO library code. Note, legacy API left untouched. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Acked-by: Linus Walleij <linus.walleij@linaro.org> Reviewed-by: Hans de Goede <hdegoede@redhat.com> Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com>
|
#
8ced32ff |
|
24-Mar-2020 |
Geert Uytterhoeven <geert+renesas@glider.be> |
gpiolib: Introduce gpiod_set_config() The GPIO Aggregator will need a method to forward a .set_config() call to its parent gpiochip. This requires obtaining the gpio_chip and offset for a given gpio_desc. While gpiod_to_chip() is public, gpio_chip_hwgpio() is not, so there is currently no method to obtain the needed GPIO offset parameter. Hence introduce a public gpiod_set_config() helper, which invokes the .set_config() callback through a gpio_desc pointer, like is done for most other gpio_chip callbacks. Rewrite the existing gpiod_set_debounce() helper as a wrapper around gpiod_set_config(), to avoid duplication. Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Link: https://lore.kernel.org/r/20200324135653.6676-5-geert+renesas@glider.be Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
046e14af |
|
05-Feb-2020 |
Andy Shevchenko <andriy.shevchenko@linux.intel.com> |
gpio: Avoid kernel.h inclusion where it's possible Inclusion of kernel.h increases the mess with the header dependencies. Avoid kernel.h inclusion where it's possible. Besides that, clean up a bit other inclusions inside GPIO subsystem headers. It includes: - removal pin control bits (forward declaration and header) from linux/gpio.h - removal of.h from asm-generic/gpio.h - use of explicit headers in gpio/consumer.h - add FIXME note with regard to gpio.h inclusion in of_gpio,h Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Link: https://lore.kernel.org/r/20200205134336.20197-1-andriy.shevchenko@linux.intel.com Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
d3a5bcb4 |
|
10-Dec-2019 |
Michał Mirosław <mirq-linux@rere.qmqm.pl> |
gpio: add gpiod_toggle_active_low() Add possibility to toggle active-low flag of a gpio descriptor. This is useful for compatibility code, where defaults are inverted vs DT gpio flags or the active-low flag is taken from elsewhere. Acked-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Michał Mirosław <mirq-linux@rere.qmqm.pl> Link: https://lore.kernel.org/r/7ce0338e01ad17fa5a227176813941b41a7c35c1.1576031637.git.mirq-linux@rere.qmqm.pl Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
|
#
13949fa9 |
|
12-Sep-2019 |
Dmitry Torokhov <dmitry.torokhov@gmail.com> |
gpiolib: introduce fwnode_gpiod_get_index() This introduces fwnode_gpiod_get_index() that iterates through common gpio suffixes when trying to locate a GPIO within a given firmware node. We also switch devm_fwnode_gpiod_get_index() to call fwnode_gpiod_get_index() instead of iterating through GPIO suffixes on its own. Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com> Link: https://lore.kernel.org/r/20190913032240.50333-3-dmitry.torokhov@gmail.com Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
2d2f116d |
|
12-Sep-2019 |
Dmitry Torokhov <dmitry.torokhov@gmail.com> |
gpiolib: introduce devm_fwnode_gpiod_get_index() devm_fwnode_get_index_gpiod_from_child() is too long, besides the fwnode in question does not have to be a child of device node. Let's rename it to devm_fwnode_gpiod_get_index() and keep the old name for compatibility for now. Also let's add a devm_fwnode_gpiod_get() wrapper as majority of the callers need a single GPIO. Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com> Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com> Link: https://lore.kernel.org/r/20190913032240.50333-2-dmitry.torokhov@gmail.com Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
2838bf94 |
|
30-Jul-2019 |
Andy Shevchenko <andriy.shevchenko@linux.intel.com> |
gpiolib-acpi: Move acpi_dev_add_driver_gpios() et al to consumer.h The API, which belongs to GPIO library, is foreign to ACPI headers. Earlier we moved out I²C out of the latter, and now it's time for acpi_dev_add_driver_gpios() et al. For time being the acpi_gpio_get_irq_resource() and acpi_dev_gpio_irq_get() are left untouched as they need more thought about. Note, it requires uninline acpi_dev_remove_driver_gpios() to keep purity of consumer.h. Cc: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Cc: Liam Girdwood <liam.r.girdwood@linux.intel.com> Cc: Jie Yang <yang.jie@linux.intel.com> Cc: Mark Brown <broonie@kernel.org> Cc: alsa-devel@alsa-project.org (moderated list:INTEL ASoC DRIVERS) Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Link: https://lore.kernel.org/r/20190730104337.21235-3-andriy.shevchenko@linux.intel.com Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
fce04b1c |
|
30-Jul-2019 |
Andy Shevchenko <andriy.shevchenko@linux.intel.com> |
gpiolib: of: Reshuffle contents of consumer.h for new library layout Kernel build bot reported a compilation error after the commit f626d6dfb709 ("gpio: of: Break out OF-only code"): drivers/gpio/gpiolib-devres.o: In function `devm_gpiod_get_from_of_node': gpiolib-devres.c:(.text+0x19a): undefined reference to `gpiod_get_from_of_node' This happens due to move the latter under umbrella of CONFIG_OF_GPIO while customer.h contains staled data. Fix it by reshuffling contents of consumer.h to satisfy build dependencies. Reported-by: kbuild test robot <lkp@intel.com> Fixes: f626d6dfb709 ("gpio: of: Break out OF-only code"): Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Link: https://lore.kernel.org/r/20190730104337.21235-1-andriy.shevchenko@linux.intel.com Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
ffe0bbab |
|
08-Jul-2019 |
Bartosz Golaszewski <bgolaszewski@baylibre.com> |
gpio: don't WARN() on NULL descs if gpiolib is disabled If gpiolib is disabled, we use the inline stubs from gpio/consumer.h instead of regular definitions of GPIO API. The stubs for 'optional' variants of gpiod_get routines return NULL in this case as if the relevant GPIO wasn't found. This is correct so far. Calling other (non-gpio_get) stubs from this header triggers a warning because the GPIO descriptor couldn't have been requested. The warning however is unconditional (WARN_ON(1)) and is emitted even if the passed descriptor pointer is NULL. We don't want to force the users of 'optional' gpio_get to check the returned pointer before calling e.g. gpiod_set_value() so let's only WARN on non-NULL descriptors. Cc: stable@vger.kernel.org Reported-by: Claus H. Stovgaard <cst@phaseone.com> Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
|
#
c5510b8d |
|
06-Dec-2018 |
Krzysztof Kozlowski <krzk@kernel.org> |
gpiolib: Fix return value of gpio_to_desc() stub if !GPIOLIB If CONFIG_GPOILIB is not set, the stub of gpio_to_desc() should return the same type of error as regular version: NULL. All the callers compare the return value of gpio_to_desc() against NULL, so returned ERR_PTR would be treated as non-error case leading to dereferencing of error value. Fixes: 79a9becda894 ("gpiolib: export descriptor-based GPIO interface") Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
891ddbc7 |
|
06-Dec-2018 |
Linus Walleij <linus.walleij@linaro.org> |
gpio: Add devm_gpiod_unhinge() This adds a function named devm_gpiod_unhinge() that removes the resource management from a GPIO descriptor. I am not sure if this is the best anglosaxon name for the function, no other managed resources have an equivalent currently, but I chose "unhinge" as the closest intuitive thing I could imagine that fits Rusty Russell's API design criterions "the obvious use is the correct one" and "the name tells you how to use it". The idea came out of a remark from Mark Brown that it should be possible to handle over management of a resource from devres to the regulator core, and indeed we can do that. Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Reviewed-by: Marek Szyprowski <m.szyprowski@samsung.com> Tested-by: Marek Szyprowski <m.szyprowski@samsung.com> Reviewed-by: Charles Keepax <ckeepax@opensource.cirrus.com> Signed-off-by: Mark Brown <broonie@kernel.org>
|
#
fe6c473e |
|
06-Dec-2018 |
Linus Walleij <linus.walleij@linaro.org> |
gpio: Export gpiod_get_from_of_node() This function already exist inside gpiolib, we were just reluctant to make it available to the kernel at large as the devm_* seemed to be enough for anyone. However we found out that regulators need to do their own lifecycle/refcounting on GPIO descriptors and explicitly call gpiod_put() when done with a descriptor, so export this function so we can hand the refcounting over to the regulator core for these descriptors after retrieveal. Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Reviewed-by: Marek Szyprowski <m.szyprowski@samsung.com> Tested-by: Marek Szyprowski <m.szyprowski@samsung.com> Reviewed-by: Charles Keepax <ckeepax@opensource.cirrus.com> Signed-off-by: Mark Brown <broonie@kernel.org>
|
#
18534df4 |
|
01-Nov-2018 |
Muchun Song <smuchun@gmail.com> |
gpiolib: Fix possible use after free on label gpiod_request_commit() copies the pointer to the label passed as an argument only to be used later. But there's a chance the caller could immediately free the passed string(e.g., local variable). This could trigger a use after free when we use gpio label(e.g., gpiochip_unlock_as_irq(), gpiochip_is_requested()). To be on the safe side: duplicate the string with kstrdup_const() so that if an unaware user passes an address to a stack-allocated buffer, we won't get the arbitrary label. Also fix gpiod_set_consumer_name(). Signed-off-by: Muchun Song <smuchun@gmail.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
b0ce7b29 |
|
12-Oct-2018 |
Linus Walleij <linus.walleij@linaro.org> |
regulator/gpio: Allow nonexclusive GPIO access This allows nonexclusive (simultaneous) access to a single GPIO line for the fixed regulator enable line. This happens when several regulators use the same GPIO for enabling and disabling a regulator, and all need a handle on their GPIO descriptor. This solution with a special flag is not entirely elegant and should ideally be replaced by something more careful as this makes it possible for several consumers to enable/disable the same GPIO line to the left and right without any consistency. The current use inside the regulator core should however be fine as it takes special care to handle this. For the state of the GPIO backend, this is still the lesser evil compared to going back to global GPIO numbers. Cc: Marek Szyprowski <m.szyprowski@samsung.com> Cc: Jon Hunter <jonathanh@nvidia.com> Fixes: efdfeb079cc3 ("regulator: fixed: Convert to use GPIO descriptor only") Reported-by: Marek Szyprowski <m.szyprowski@samsung.com> Tested-by: Jon Hunter <jonathanh@nvidia.com> Tested-by: Marek Szyprowski <m.szyprowski@samsung.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Mark Brown <broonie@kernel.org>
|
#
3c940660 |
|
27-Sep-2018 |
Geert Uytterhoeven <geert+renesas@glider.be> |
gpio: Restore indentation of continued lines Fixes: 3027743f83f867d8 ("gpio: Remove VLA from gpiolib") Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
cf9af0d5 |
|
27-Sep-2018 |
Geert Uytterhoeven <geert+renesas@glider.be> |
gpio: Propagate errors from gpiod_set_array_value_complex() Internal helper function gpiod_set_array_value_complex() was changed to return an error value, but not all gpiolib callers were updated to propagate the new error up. Fixes: 3027743f83f867d8 ("gpio: Remove VLA from gpiolib") Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
77588c14 |
|
05-Sep-2018 |
Janusz Krzysztofik <jmkrzyszt@gmail.com> |
gpiolib: Pass array info to get/set array functions 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>
|
#
bf9346f5 |
|
05-Sep-2018 |
Janusz Krzysztofik <jmkrzyszt@gmail.com> |
gpiolib: Identify arrays matching GPIO hardware 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>
|
#
b9762beb |
|
05-Sep-2018 |
Janusz Krzysztofik <jmkrzyszt@gmail.com> |
gpiolib: Pass bitmaps, not integer arrays, to get/set array 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>
|
#
0969a204 |
|
27-Jul-2018 |
Andy Shevchenko <andriy.shevchenko@linux.intel.com> |
gpiolib: Use GPIOD_OUT_{LOW,HIGH} macros in open drain ones There should not be anything more than stated by the name of newly introduced constants, i.e. GPIOD_OUT_LOW_OPEN_DRAIN == GPIOD_OUT_LOW + open drain and nothing more. Make it better to read and slightly more robust by using GPIOD_OUT_LOW and GPIOD_OUT_HIGH constants with open drain flag. No functional change intended. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
90b39402e |
|
01-Jun-2018 |
Linus Walleij <linus.walleij@linaro.org> |
gpio: Add API to explicitly name a consumer The GPIO (descriptor) API registers a "label" naming what is currently using the GPIO line. Typically this is taken from things like the device tree node, so "reset-gpios" will result in he line being labeled "reset". The technical effect is pretty much zero: the use is for debug and introspection, such as "lsgpio" and debugfs files. However sometimes the user want this cuddly feeling of listing all GPIO lines and seeing exactly what they are for and it gives a very fulfilling sense of control. Especially in the cases when the device tree node doesn't provide a good name, or anonymous GPIO lines assigned just to "gpios" in the device tree because the usage is implicit. For these cases it may be nice to be able to label the line directly and explicitly. Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
3027743f |
|
21-May-2018 |
Laura Abbott <labbott@redhat.com> |
gpio: Remove VLA from gpiolib The new challenge is to remove VLAs from the kernel (see https://lkml.org/lkml/2018/3/7/621) to eventually turn on -Wvla. Using a kmalloc array is the easy way to fix this but kmalloc is still more expensive than stack allocation. Introduce a fast path with a fixed size stack array to cover most chip with gpios below some fixed amount. The slow path dynamically allocates an array to cover those chips with a large number of gpios. Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be> Reviewed-by: Phil Reid <preid@electromag.com.au> Reviewed-and-tested-by: Lukas Wunner <lukas@wunner.de> Signed-off-by: Lukas Wunner <lukas@wunner.de> Signed-off-by: Laura Abbott <labbott@redhat.com> Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
92542edc |
|
29-Dec-2017 |
Linus Walleij <linus.walleij@linaro.org> |
gpio: Export devm_gpiod_get_from_of_node() for consumers 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>
|
#
e10f72bf |
|
29-Nov-2017 |
Andrew Jeffery <andrew@aj.id.au> |
gpio: gpiolib: Generalise state persistence beyond sleep General support for state persistence is added to gpiolib with the introduction of a new pinconf parameter to propagate the request to hardware. The existing persistence support for sleep is adapted to include hardware support if the GPIO driver provides it. Persistence continues to be enabled by default; in-kernel consumers can opt out, but userspace (currently) does not have a choice. The *_SLEEP_MAY_LOSE_VALUE and *_SLEEP_MAINTAIN_VALUE symbols are renamed, dropping the SLEEP prefix to reflect that the concept is no longer sleep-specific. I feel that renaming to just *_MAY_LOSE_VALUE could initially be misinterpreted, so I've further changed the symbols to *_TRANSITORY and *_PERSISTENT to address this. The sysfs interface is modified only to keep consistency with the chardev interface in enforcing persistence for userspace exports. Signed-off-by: Andrew Jeffery <andrew@aj.id.au> Reviewed-by: Charles Keepax <ckeepax@opensource.cirrus.com> Acked-by: Rob Herring <robh@kernel.org> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
b2441318 |
|
01-Nov-2017 |
Greg Kroah-Hartman <gregkh@linuxfoundation.org> |
License cleanup: add SPDX GPL-2.0 license identifier to files with no license Many source files in the tree are missing licensing information, which makes it harder for compliance tools to determine the correct license. By default all files without license information are under the default license of the kernel, which is GPL version 2. Update the files which contain no license information with the 'GPL-2.0' SPDX license identifier. The SPDX identifier is a legally binding shorthand, which can be used instead of the full boiler plate text. This patch is based on work done by Thomas Gleixner and Kate Stewart and Philippe Ombredanne. How this work was done: Patches were generated and checked against linux-4.14-rc6 for a subset of the use cases: - file had no licensing information it it. - file was a */uapi/* one with no licensing information in it, - file was a */uapi/* one with existing licensing information, Further patches will be generated in subsequent months to fix up cases where non-standard license headers were used, and references to license had to be inferred by heuristics based on keywords. The analysis to determine which SPDX License Identifier to be applied to a file was done in a spreadsheet of side by side results from of the output of two independent scanners (ScanCode & Windriver) producing SPDX tag:value files created by Philippe Ombredanne. Philippe prepared the base worksheet, and did an initial spot review of a few 1000 files. The 4.13 kernel was the starting point of the analysis with 60,537 files assessed. Kate Stewart did a file by file comparison of the scanner results in the spreadsheet to determine which SPDX license identifier(s) to be applied to the file. She confirmed any determination that was not immediately clear with lawyers working with the Linux Foundation. Criteria used to select files for SPDX license identifier tagging was: - Files considered eligible had to be source code files. - Make and config files were included as candidates if they contained >5 lines of source - File already had some variant of a license header in it (even if <5 lines). All documentation files were explicitly excluded. The following heuristics were used to determine which SPDX license identifiers to apply. - when both scanners couldn't find any license traces, file was considered to have no license information in it, and the top level COPYING file license applied. For non */uapi/* files that summary was: SPDX license identifier # files ---------------------------------------------------|------- GPL-2.0 11139 and resulted in the first patch in this series. If that file was a */uapi/* path one, it was "GPL-2.0 WITH Linux-syscall-note" otherwise it was "GPL-2.0". Results of that was: SPDX license identifier # files ---------------------------------------------------|------- GPL-2.0 WITH Linux-syscall-note 930 and resulted in the second patch in this series. - if a file had some form of licensing information in it, and was one of the */uapi/* ones, it was denoted with the Linux-syscall-note if any GPL family license was found in the file or had no licensing in it (per prior point). Results summary: SPDX license identifier # files ---------------------------------------------------|------ GPL-2.0 WITH Linux-syscall-note 270 GPL-2.0+ WITH Linux-syscall-note 169 ((GPL-2.0 WITH Linux-syscall-note) OR BSD-2-Clause) 21 ((GPL-2.0 WITH Linux-syscall-note) OR BSD-3-Clause) 17 LGPL-2.1+ WITH Linux-syscall-note 15 GPL-1.0+ WITH Linux-syscall-note 14 ((GPL-2.0+ WITH Linux-syscall-note) OR BSD-3-Clause) 5 LGPL-2.0+ WITH Linux-syscall-note 4 LGPL-2.1 WITH Linux-syscall-note 3 ((GPL-2.0 WITH Linux-syscall-note) OR MIT) 3 ((GPL-2.0 WITH Linux-syscall-note) AND MIT) 1 and that resulted in the third patch in this series. - when the two scanners agreed on the detected license(s), that became the concluded license(s). - when there was disagreement between the two scanners (one detected a license but the other didn't, or they both detected different licenses) a manual inspection of the file occurred. - In most cases a manual inspection of the information in the file resulted in a clear resolution of the license that should apply (and which scanner probably needed to revisit its heuristics). - When it was not immediately clear, the license identifier was confirmed with lawyers working with the Linux Foundation. - If there was any question as to the appropriate license identifier, the file was flagged for further research and to be revisited later in time. In total, over 70 hours of logged manual review was done on the spreadsheet to determine the SPDX license identifiers to apply to the source files by Kate, Philippe, Thomas and, in some cases, confirmation by lawyers working with the Linux Foundation. Kate also obtained a third independent scan of the 4.13 code base from FOSSology, and compared selected files where the other two scanners disagreed against that SPDX file, to see if there was new insights. The Windriver scanner is based on an older version of FOSSology in part, so they are related. Thomas did random spot checks in about 500 files from the spreadsheets for the uapi headers and agreed with SPDX license identifier in the files he inspected. For the non-uapi files Thomas did random spot checks in about 15000 files. In initial set of patches against 4.14-rc6, 3 files were found to have copy/paste license identifier errors, and have been fixed to reflect the correct identifier. Additionally Philippe spent 10 hours this week doing a detailed manual inspection and review of the 12,461 patched files from the initial patch version early this week with: - a full scancode scan run, collecting the matched texts, detected license ids and scores - reviewing anything where there was a license detected (about 500+ files) to ensure that the applied SPDX license was correct - reviewing anything where there was no detection but the patch license was not GPL-2.0 WITH Linux-syscall-note to ensure that the applied SPDX license was correct This produced a worksheet with 20 files needing minor correction. This worksheet was then exported into 3 different .csv files for the different types of files to be modified. These .csv files were then reviewed by Greg. Thomas wrote a script to parse the csv files and add the proper SPDX tag to the file, in the format that the file expected. This script was further refined by Greg based on the output to detect more types of files automatically and to distinguish between header and source .c files (which need different comment types.) Finally Greg ran the script using the .csv files to generate the patches. Reviewed-by: Kate Stewart <kstewart@linuxfoundation.org> Reviewed-by: Philippe Ombredanne <pombredanne@nexb.com> Reviewed-by: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
#
f926dfc1 |
|
10-Sep-2017 |
Linus Walleij <linus.walleij@linaro.org> |
gpio: Make it possible for consumers to enforce open drain Some busses, like I2C, strictly need to have the line handled as open drain, i.e. not actively driven high. For this reason the i2c-gpio.c bit-banged I2C driver is reimplementing open drain handling outside of gpiolib. This is not very optimal. Instead make it possible for a consumer to explcitly express that the line must be handled as open drain instead of allowing local hacks papering over this issue. The descriptor tables, whether DT, ACPI or board files, should of course have flagged these lines as open drain. E.g.: enum gpio_lookup_flags GPIO_OPEN_DRAIN for a board file, or gpios = <&foo 42 GPIO_ACTIVE_HIGH|GPIO_OPEN_DRAIN>; in a device tree using <dt-bindings/gpio/gpio.h> But more often than not, these descriptors are wrong. So we need to make it possible for consumers to enforce this open drain behaviour. We now have two new enumerated GPIO descriptor config flags: GPIOD_OUT_LOW_OPEN_DRAIN and GPIOD_OUT_HIGH_OPEN_DRAIN that will set up the lined enforced as open drain as output low or high, using open drain (if the driver supports it) or using open drain emulation (setting the line as input to drive it high) from the gpiolib core. Cc: linux-gpio@vger.kernel.org Tested-by: Geert Uytterhoeven <geert+renesas@glider.be> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
eec1d566 |
|
11-Oct-2017 |
Lukas Wunner <lukas@wunner.de> |
gpio: Introduce ->get_multiple callback SPI-attached GPIO controllers typically read out all inputs in one go. If callers desire the values of multipe inputs, ideally a single readout should take place to return the desired values. However the current driver API only offers a ->get callback but no ->get_multiple (unlike ->set_multiple, which is present). Thus, to read multiple inputs, a full readout needs to be performed for every single value (barring driver-internal caching), which is inefficient. In fact, the lack of a ->get_multiple callback has been bemoaned repeatedly by the gpio subsystem maintainer: http://www.spinics.net/lists/linux-gpio/msg10571.html http://www.spinics.net/lists/devicetree/msg121734.html Introduce the missing callback. Add corresponding consumer functions such as gpiod_get_array_value(). Amend linehandle_ioctl() to take advantage of the newly added infrastructure. Update the documentation. Cc: Rojhalat Ibrahim <imr@rtschenk.de> Signed-off-by: Lukas Wunner <lukas@wunner.de> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
22c40367 |
|
12-Feb-2017 |
Dmitry Torokhov <dmitry.torokhov@gmail.com> |
gpio: return NULL from gpiod_get_optional when GPIOLIB is disabled Given the intent behind gpiod_get_optional() and friends it does not make sense to return -ENOSYS when GPIOLIB is disabled: the driver is expected to work just fine without gpio so let's behave as if gpio was not found. Otherwise we have to special-case -ENOSYS in drivers. Note that there was objection that someone might forget to enable GPIOLIB when dealing with a platform that has device that actually specifies optional gpio and we'll break it. I find this unconvincing as that would have to be the *only GPIO* in the system, which is extremely unlikely. Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
0043c1df |
|
08-Feb-2017 |
Lee Jones <lee.jones@linaro.org> |
serial: st-asc: Use new GPIOD API to obtain RTS pin The commits mentioned below adapt the GPIO API to allow more information to be passed directly through devm_get_gpiod_from_child() in the first instance. This facilitates the removal of subsequent calls, such as gpiod_direction_output(). This patch firstly moves to utilise the new API and secondly removes the now superfluous call do set the direction. Reported-by: Stephen Rothwell <sfr@canb.auug.org.au> Suggested-by: Boris Brezillon <boris.brezillon@free-electrons.com> Signed-off-by: Lee Jones <lee.jones@linaro.org> [Also drop the header file dummies that only this driver was using] Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
3498d869 |
|
21-Feb-2017 |
Linus Walleij <linus.walleij@linaro.org> |
gpio: reintroduce devm_get_gpiod_from_child() We need to keep this API around for the merge window to avoid nasty build problems in the merges. Cc: Lee Jones <lee.jones@linaro.org> Suggested-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
537b94da |
|
02-Feb-2017 |
Boris Brezillon <bbrezillon@kernel.org> |
gpio: Add the devm_fwnode_get_index_gpiod_from_child() helper devm_fwnode_get_gpiod_from_child() currently allows GPIO users to request a GPIO that is defined in a child fwnode instead of directly in the device fwnode. Extend this API by adding the devm_fwnode_get_index_gpiod_from_child() helper which does the same except you can also specify an index in case the 'xx-gpios' property describe several GPIOs. Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
4b094797 |
|
02-Feb-2017 |
Boris Brezillon <bbrezillon@kernel.org> |
gpio: Rename devm_get_gpiod_from_child() Rename devm_get_gpiod_from_child() into devm_fwnode_get_gpiod_from_child() to reflect the fact that this function is operating on a fwnode object. Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com> Acked-by: Jacek Anaszewski <jacek.anaszewski@gmail.com> Acked-by: Dmitry Torokhov <dmitry.torokhov@gmail.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
b2987d74 |
|
12-Jan-2017 |
Alexander Stein <alexander.stein@systec-electronic.com> |
gpio: Pass GPIO label down to gpiod_request Currently all users of fwnode_get_named_gpiod() have no way to specify a label for the GPIO. So GPIOs listed in debugfs are shown with label "?". With this change a proper label is used. Also adjust all users so they can pass a label, properly retrieved from device tree properties. Signed-off-by: Alexander Stein <alexander.stein@systec-electronic.com> Cc: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Acked-by: Jacek Anaszewski <jacek.anaszewski@gmail.com> Acked-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com> Acked-by: Dmitry Torokhov <dmitry.torokhov@gmail.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
a264d10f |
|
09-Jan-2017 |
Andy Shevchenko <andriy.shevchenko@linux.intel.com> |
gpiolib: Convert fwnode_get_named_gpiod() to configure GPIO Make fwnode_get_named_gpiod() consistent with the rest of gpiod_get() like API, i.e. configure GPIO pin immediately after request. Besides obvious clean up it will help to configure pins based on firmware provided resources. Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
f881bab0 |
|
23-Sep-2015 |
Linus Walleij <linus.walleij@linaro.org> |
gpio: keep the GPIO line names internal This refactors the changes to the GPIO line naming mechanism to not have so widespread effects, instead we conclude the patch series by having created a name attribute in the GPIO descriptor, that need not be globally unique, and it will be initialized from the old .names array in struct gpio_chip if it exists, then used in the legacy sysfs code like the array was used previously. The associated changes to name lines from the device tree are controversial and need to stand alone from this. Resulting changes: 1. Remove the export and the header for the gpio_name_to_desc() as so far the only use is inside gpiolib.c. Staticize gpio_name_to_desc() and move it above the only function using it. 2. Only print a warning if there are two GPIO lines with the same name. The reason is to preserve current behaviour: before the previous changes to the naming mechanism this would not reject probing the driver, instead the error would occur when trying to export the line in sysfs, so restore this behaviour, but print a friendly warning if names collide. Cc: Johan Hovold <johan@kernel.org> Cc: Markus Pargmann <mpa@pengutronix.de> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
c0017ed7 |
|
14-Aug-2015 |
Markus Pargmann <mpa@pengutronix.de> |
gpio: Introduce gpio descriptor 'name' The latest gpio hogging mechanism assigns each gpio a 'line-name' in the devicetree. The 'name' field is different from the 'label' field. 'label' is only used for requested GPIOs to describe its current use by driver or userspace. The 'name' field describes the GPIO itself, not the use. This is most likely identical to the label in the schematic on the GPIO line and should help to find this particular GPIO. This is equivalent to the gpiochip->names array. However names should be stored in the GPIO descriptor. We will use gpiochip->names in the future only as initializer for the GPIO descriptors for drivers that assign GPIO names hardcoded. All other GPIO names will be parsed from DT and directly assigned to the GPIO descriptor. This patch adds a helper function to find gpio descriptors by name instead of gpio number. Signed-off-by: Markus Pargmann <mpa@pengutronix.de> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
b17d1bf1 |
|
11-Feb-2015 |
Uwe Kleine-König <u.kleine-koenig@pengutronix.de> |
gpio: make flags mandatory for gpiod_get functions Now that all[1] users of the gpiod_get functions are converted to make use of the up to now optional flags parameter, make it mandatory which allows to remove some cpp magic. [1] all but etraxfs-uart which is broken anyhow and I'm allowed to ignore it by Jesper Nilsson :-) Acked-by: Alexandre Courbot <acourbot@nvidia.com> Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
|
#
3fff99bc |
|
13-May-2015 |
Rojhalat Ibrahim <imr@rtschenk.de> |
gpiolib: rename gpiod_set_array to gpiod_set_array_value There have been concerns that the function names gpiod_set_array() and gpiod_get_array() might be confusing to users. One might expect gpiod_get_array() to return array values, while it is actually the array counterpart of gpiod_get(). To be consistent with the single descriptor API we could rename gpiod_set_array() to gpiod_set_array_value(). This makes some function names a bit lengthy: gpiod_set_raw_array_value_cansleep(). Signed-off-by: Rojhalat Ibrahim <imr@rtschenk.de> Acked-by: Alexandre Courbot <acourbot@nvidia.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
496e7ce2 |
|
07-May-2015 |
Geert Uytterhoeven <geert@linux-m68k.org> |
gpiolib: Add missing dummies for the unified device properties interface If GPIOLIB=n: drivers/leds/leds-gpio.c: In function ‘gpio_leds_create’: drivers/leds/leds-gpio.c:187: error: implicit declaration of function ‘devm_get_gpiod_from_child’ drivers/leds/leds-gpio.c:187: warning: assignment makes pointer from integer without a cast Add dummies for fwnode_get_named_gpiod() and devm_get_gpiod_from_child() for the !GPIOLIB case to fix this. Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org> Fixes: 40b7318319281b1b ("gpio: Support for unified device properties interface") Acked-by: Alexandre Courbot <acourbot@nvidia.com> Acked-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Bryan Wu <cooloney@gmail.com>
|
#
166a85e4 |
|
04-May-2015 |
Johan Hovold <johan@kernel.org> |
gpio: remove gpiod_sysfs_set_active_low Remove gpiod_sysfs_set_active_low (and gpio_sysfs_set_active_low) which allowed code to change the polarity of a gpio line even after it had been exported through sysfs. Drivers should not care, and generally does not know, about gpio-line polarity which is a hardware feature that needs to be described by firmware. It is currently possible to define gpio-line polarity in device-tree and acpi firmware or using platform data. Userspace can also change the polarity through sysfs. Note that drivers using the legacy gpio interface could still use GPIOF_ACTIVE_LOW to change the polarity before exporting the gpio. There are no in-kernel users of this interface. Cc: Jonathan Corbet <corbet@lwn.net> Cc: Harry Wei <harryxiyou@gmail.com> Cc: Arnd Bergmann <arnd@arndb.de> Cc: linux-doc@vger.kernel.org Cc: linux-kernel@zh-kernel.org Cc: linux-arch@vger.kernel.org Signed-off-by: Johan Hovold <johan@kernel.org> Reviewed-by: Alexandre Courbot <acourbot@nvidia.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
331758ee |
|
11-Feb-2015 |
Rojhalat Ibrahim <imr@rtschenk.de> |
gpiolib: add devm_gpiod_get_array and devm_gpiod_put_array functions Add device managed variants of gpiod_get_array() / gpiod_put_array() functions for conveniently obtaining and disposing of an entire array of GPIOs with one function call. Signed-off-by: Rojhalat Ibrahim <imr@rtschenk.de> Reviewed-by: Alexandre Courbot <acourbot@nvidia.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
66858527 |
|
11-Feb-2015 |
Rojhalat Ibrahim <imr@rtschenk.de> |
gpiolib: add gpiod_get_array and gpiod_put_array functions Introduce new functions for conveniently obtaining and disposing of an entire array of GPIOs with one function call. ACPI parts tested by Mika Westerberg, DT parts tested by Rojhalat Ibrahim. Change log: v5: move the ACPI functions to gpiolib-acpi.c v4: - use shorter names for members of struct gpio_descs - rename lut_gpio_count to platform_gpio_count for clarity - add check for successful memory allocation - use ERR_CAST() v3: - rebase on current linux-gpio devel branch - fix ACPI GPIO counting - allow for zero-sized arrays - make the flags argument mandatory for the new functions - clarify documentation v2: change interface Suggested-by: Alexandre Courbot <acourbot@nvidia.com> Signed-off-by: Rojhalat Ibrahim <imr@rtschenk.de> Reviewed-by: Alexandre Courbot <acourbot@nvidia.com> Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com> Tested-by: Mika Westerberg <mika.westerberg@linux.intel.com> Tested-by: Rojhalat Ibrahim <imr@rtschenk.de> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
1feb57a2 |
|
21-Jan-2015 |
Olliver Schinagl <oliver@schinagl.nl> |
gpio: add parameter to allow the use named gpios The gpio binding document says that new code should always use named gpios. Patch 40b73183 added support to parse a list of gpios from child nodes, but does not make it possible to use named gpios. This patch adds the con_id property and implements it is done in gpiolib.c, where the old-style of using unnamed gpios still works. Signed-off-by: Olliver Schinagl <oliver@schinagl.nl> Acked-by: Bryan Wu <cooloney@gmail.com> Acked-by: Dmitry Torokhov <dmitry.torokhov@gmail.com> Reviewed-by: Alexandre Courbot <acourbot@nvidia.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
d34541bc |
|
07-Jan-2015 |
Olliver Schinagl <oliver@schinagl.nl> |
gpio: Make the vararg hacks not pass magic values Right now, in consumer.h, there's some vararg hacks that pass 0 as the flags. What actually is passed however is GPIOD_ASIS, which naturally is also 0. Using the define/enum rather then the magic 0 makes it the define more readable to a passer by. Signed-off-by: Olliver Schinagl <oliver@schinagl.nl> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
8e53b0f1 |
|
25-Nov-2014 |
Alexandre Courbot <acourbot@nvidia.com> |
gpio: remove const modifier from gpiod_get_direction() Although gpiod_get_direction() can be considered side-effect free for consumers, its internals involve setting or clearing bits in the affected GPIO descriptor, for which we need to force-cast the const descriptor variable to non-const. This could lead to incorrect behavior if the compiler decides to optimize here, so remove this const attribute. The intent is to make gpiod_get_direction() private anyway, so it does not really matter. Reported-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by: Alexandre Courbot <acourbot@nvidia.com> Acked-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
5f424243 |
|
04-Nov-2014 |
Rojhalat Ibrahim <imr@rtschenk.de> |
gpiolib: allow simultaneous setting of multiple GPIO outputs Introduce new functions gpiod_set_array & gpiod_set_raw_array to the consumer interface which allow setting multiple outputs with just one function call. Also add an optional set_multiple function to the driver interface. Without an implementation of that function in the chip driver outputs are set sequentially. Implementing the set_multiple function in a chip driver allows for: - Improved performance for certain use cases. The original motivation for this was the task of configuring an FPGA. In that specific case, where 9 GPIO lines have to be set many times, configuration time goes down from 48 s to 20 s when using the new function. - Simultaneous glitch-free setting of multiple pins on any kind of parallel bus attached to GPIOs provided they all reside on the same chip and bank. Limitations: Performance is only improved for normal high-low outputs. Open drain and open source outputs are always set separately from each other. Those kinds of outputs could probably be accelerated in a similar way if we could forgo the error checking when setting GPIO directions. Change log: v6: - rebase on current linux-gpio devel branch v5: - check can_sleep property per chip - remove superfluous checks - supplement documentation v4: - add gpiod_set_array function for setting logical values - change interface of the set_multiple driver function to use unsigned long as type for the bit fields - use generic bitops (which also use unsigned long for bit fields) - do not use ARCH_NR_GPIOS any more v3: - add documentation - change commit message v2: - use descriptor interface - allow arbitrary groups of GPIOs spanning multiple chips Signed-off-by: Rojhalat Ibrahim <imr@rtschenk.de> Reviewed-by: Alexandre Courbot <acourbot@nvidia.com> Reviewed-by: Mark Brown <broonie@linaro.org> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
40b73183 |
|
21-Oct-2014 |
Mika Westerberg <mika.westerberg@linux.intel.com> |
gpio: Support for unified device properties interface Some drivers need to deal with only firmware representation of its GPIOs. An example would be a GPIO button array driver where each button is described as a separate firmware node in device tree. Typically these child nodes do not have physical representation in the Linux device model. In order to help device drivers to handle such firmware child nodes we add dev[m]_get_named_gpiod_from_child() that takes a child firmware node pointer as its second argument (the first one is the parent device itself), finds the GPIO using whatever is the underlying firmware method, and requests the GPIO properly. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com> Acked-by: Alexandre Courbot <acourbot@nvidia.com> Acked-by: Grant Likely <grant.likely@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
#
0dbc8b7a |
|
01-Sep-2014 |
Linus Walleij <linus.walleij@linaro.org> |
gpio: move varargs hack outside #ifdef GPIOLIB commit 39b2bbe3d715cf5013b5c48695ccdd25bd3bf120 "gpio: add flags argument to gpiod_get*() functions" added a dynamic flags argument to all the GPIOD getter functions, however this did not cover the stubs so when people used gpiod stubs to compile out descriptor code, compilation failed. Solve this by: - Also rename all the stub functions __gpiod_* - Moving the vararg hack outside of #ifdef CONFIG_GPIOLIB so these will always be available. Reviewed-by: Alexandre Courbot <acourbot@nvidia.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
58b84f6a |
|
18-Aug-2014 |
Linus Walleij <linus.walleij@linaro.org> |
gpio: move GPIOD flags outside #ifdef The GPIOD flags are defined inside the #ifdef CONFIG_GPIOLIB switch, making the gpiolib stubs fail if these flags are used by a consumer. This is not correct: the stubs should compile fine without GPIOLIB. Reported-by: Ulf Hansson <ulf.hansson@linaro.org> Reviewed-by: Alexandre Courbot <acourbot@nvidia.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
39b2bbe3 |
|
25-Jul-2014 |
Alexandre Courbot <acourbot@nvidia.com> |
gpio: add flags argument to gpiod_get*() functions The huge majority of GPIOs have their direction and initial value set right after being obtained by one of the gpiod_get() functions. The integer GPIO API had gpio_request_one() that took a convenience flags parameter allowing to specify an direction and value applied to the returned GPIO. This feature greatly simplifies client code and ensures errors are always handled properly. A similar feature has been requested for the gpiod API. Since setting the direction of a GPIO is so often the very next action done after obtaining its descriptor, we prefer to extend the existing functions instead of introducing new functions that would raise the number of gpiod getters to 16 (!). The drawback of this approach is that all gpiod clients need to be updated. To limit the pain, temporary macros are introduced that allow gpiod_get*() to be called with or without the extra flags argument. They will be removed once all consumer code has been updated. Signed-off-by: Alexandre Courbot <acourbot@nvidia.com> Reviewed-by: Mark Brown <broonie@linaro.org> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
cdf86cd2 |
|
08-May-2014 |
Arnd Bergmann <arnd@arndb.de> |
gpio: include linux/bug.h in interface header Today's linux-next kernel started showing build errors for the use of WARN_ON in linux/gpio/consumer.h: In file included from drivers/video/backlight/pwm_bl.c:13:0: include/linux/gpio/consumer.h: In function 'gpiod_put': include/linux/gpio/consumer.h:81:2: error: implicit declaration of function 'WARN_ON' [-Werror=implicit-function-declaration] It's not clear why this never happened before, but this patch fixes it by including the header that contains the defintion of this macro. Signed-off-by: Arnd Bergmann <arnd@arnd.de> Acked-by: Alexandre Courbot <acourbot@nvidia.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
29a1f233 |
|
25-Apr-2014 |
Thierry Reding <treding@nvidia.com> |
gpio: Add helpers for optional GPIOs Introduce gpiod_get_optional() and gpiod_get_index_optional() helpers that make it easier for drivers to handle optional GPIOs. Currently in order to handle optional GPIOs, a driver needs to special case error handling for -ENOENT, such as this: gpio = gpiod_get(dev, "foo"); if (IS_ERR(gpio)) { if (PTR_ERR(gpio) != -ENOENT) return PTR_ERR(gpio); gpio = NULL; } if (gpio) { /* set up GPIO */ } With these new helpers the above is reduced to: gpio = gpiod_get_optional(dev, "foo"); if (IS_ERR(gpio)) return PTR_ERR(gpio); if (gpio) { /* set up GPIO */ } While at it, device-managed variants of these functions are also provided. Signed-off-by: Thierry Reding <treding@nvidia.com> Reviewed-by: Alexandre Courbot <acourbot@nvidia.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
bb1e88cc |
|
09-Feb-2014 |
Alexandre Courbot <acourbot@nvidia.com> |
gpiolib: add gpiochip_get_desc() driver function Some drivers dealing with a gpio_chip might need to act on its descriptors directly; one example is pinctrl drivers that need to lock a GPIO for being used as IRQ using gpiod_lock_as_irq(). This patch exports a gpiochip_get_desc() function that returns the GPIO descriptor at the requested index. It also sweeps the gpio_to_chip() function out of the consumer interface since any holder of a gpio_chip reference can manipulate its GPIOs way beyond what a consumer should be allowed to do. As a result, gpio_chip is not visible anymore to simple GPIO consumers. Signed-off-by: Alexandre Courbot <acourbot@nvidia.com> Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com> Reviewed-by: Jean-Jacques Hiblot <jjhiblot@traphandler.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
ef70bbe1 |
|
06-Jan-2014 |
Philipp Zabel <p.zabel@pengutronix.de> |
gpio: make gpiod_direction_output take a logical value The documentation was not clear about whether gpio_direction_output should take a logical value or the physical level on the output line, i.e. whether the ACTIVE_LOW status would be taken into account. This converts gpiod_direction_output to use the logical level and adds a new gpiod_direction_output_raw for the raw value. Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de> Reviewed-by: Alexandre Courbot <acourbot@nvidia.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
a3485d08 |
|
04-Feb-2014 |
Lars-Peter Clausen <lars@metafoo.de> |
gpio: consumer.h: Move forward declarations outside #ifdef Make sure that the forward declared structs in gpio/consumer.h are also visible on the else branch of the CONFIG_GPIOLIB #ifdef. Fixes the following warnings and their associated errors when CONFIG_GPIOLIB is not selected: include/linux/gpio/consumer.h:67:14: warning: 'struct device' declared inside parameter list include/linux/gpio/consumer.h:67:14: warning: its scope is only this definition or declaration, which is probably not what you want [...] Signed-off-by: Lars-Peter Clausen <lars@metafoo.de> Reviewed-by: Alexandre Courbot <acourbot@nvidia.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
bae48da2 |
|
17-Oct-2013 |
Alexandre Courbot <acourbot@nvidia.com> |
gpiolib: add gpiod_get() and gpiod_put() functions Add gpiod_get(), gpiod_get_index() and gpiod_put() functions that provide safer management of GPIOs. These functions put the GPIO framework in line with the conventions of other frameworks in the kernel, and help ensure every GPIO is declared properly and valid while it is used. Signed-off-by: Alexandre Courbot <acourbot@nvidia.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
79a9becd |
|
17-Oct-2013 |
Alexandre Courbot <acourbot@nvidia.com> |
gpiolib: export descriptor-based GPIO interface This patch exports the gpiod_* family of API functions, a safer alternative to the legacy GPIO interface. Differences between the gpiod and legacy gpio APIs are: - gpio works with integers, whereas gpiod operates on opaque handlers which cannot be forged or used before proper acquisition - gpiod get/set functions are aware of the active low state of a GPIO - gpio consumers should now include <linux/gpio/consumer.h> to access the new interface, whereas chips drivers will use <linux/gpio/driver.h> The legacy gpio API is now built as inline functions on top of gpiod. Signed-off-by: Alexandre Courbot <acourbot@nvidia.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|