#
52464f59 |
|
25-Mar-2024 |
Mark Brown <broonie@kernel.org> |
gpiolib: Add stubs for GPIO lookup functions The gpio_device_find_by_() functions do not have stubs which means that if they are referenced from code with an optiona dependency on gpiolib then the code will fail to link. Add stubs for lookups via fwnode and label. I have not added a stub for plain gpio_device_find() since it seems harder to see a use case for that which does not depend on gpiolib. With the addition of the GPIO reset controller (which lacks a gpiolib dependency) to the arm64 defconfig this is causing build breaks for arm64 virtconfig in -next: aarch64-linux-gnu-ld: drivers/reset/core.o: in function `__reset_add_reset_gpio_lookup': /build/stage/linux/drivers/reset/core.c:861:(.text+0xccc): undefined reference to `gpio_device_find_by_fwnode' Signed-off-by: Mark Brown <broonie@kernel.org> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
|
#
3d8bb3d3 |
|
22-Feb-2024 |
Bartosz Golaszewski <bartosz.golaszewski@linaro.org> |
gpio: provide for_each_hwgpio() We only provide iterators for requested GPIOs to provider drivers. In order to allow them to display debug information about all GPIOs, let's provide a variant for iterating over all GPIOs. Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org> Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
|
#
4a92857d |
|
16-Feb-2024 |
Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> |
gpio: constify opaque pointer "data" in gpio_device_find() The opaque pointer "data" in each match function used by gpio_device_find() is a pointer to const, thus the same argument passed to gpio_device_find() can adjusted similarly. Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
|
#
faf6efd2 |
|
08-Feb-2024 |
Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> |
gpio: constify opaque pointer in gpio_device_find() match function The match function used in gpio_device_find() should not modify the contents of passed opaque pointer, because such modification would not be necessary for actual matching and it could lead to quite unreadable, spaghetti code. Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> [Bartosz: fix coding style in header] Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
|
#
6933ba52 |
|
25-Jan-2024 |
Bartosz Golaszewski <bartosz.golaszewski@linaro.org> |
gpio: improve the API contract for setting direction If a GPIO driver returns a positive integer from one of the direction setter callbacks, we'll end up propagating it to user-space. Whether we should sanitize the values returned by callbacks is a different question but let's first improve the documentation and fortify the contract with GPIO providers. Reported-by: José Guilherme de Castro Rodrigues <joseguilhermebh@hotmail.com> Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org> Reviewed-by: Kent Gibson <warthog618@gmail.com>
|
#
88b70496 |
|
24-Jan-2024 |
Bartosz Golaszewski <bartosz.golaszewski@linaro.org> |
gpio: unexport GPIO irq domain functions only used internally There are no external users for the irq domain helpers so unexport them and remove the prototypes from the driver header. Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
|
#
2df8aa3c |
|
25-Jan-2024 |
Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> |
gpiolib: add gpio_device_get_label() stub for !GPIOLIB Add empty stub of gpio_device_get_label() when GPIOLIB is not enabled. Cc: <stable@vger.kernel.org> Fixes: d1f7728259ef ("gpiolib: provide gpio_device_get_label()") Suggested-by: kernel test robot <lkp@intel.com> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
|
#
ebe0c15b |
|
25-Jan-2024 |
Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> |
gpiolib: add gpio_device_get_base() stub for !GPIOLIB Add empty stub of gpio_device_get_base() when GPIOLIB is not enabled. Cc: <stable@vger.kernel.org> Fixes: 8c85a102fc4e ("gpiolib: provide gpio_device_get_base()") Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
|
#
6ac86372 |
|
25-Jan-2024 |
Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> |
gpiolib: add gpiod_to_gpio_device() stub for !GPIOLIB Add empty stub of gpiod_to_gpio_device() when GPIOLIB is not enabled. Cc: <stable@vger.kernel.org> Fixes: 370232d096e3 ("gpiolib: provide gpiod_to_gpio_device()") Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
|
#
832b3710 |
|
15-Jan-2024 |
Lukas Wunner <lukas@wunner.de> |
gpiolib: Fix scope-based gpio_device refcounting Commit 9e4555d1e54a ("gpiolib: add support for scope-based management to gpio_device") sought to add scope-based gpio_device refcounting, but erroneously forgot a negation of IS_ERR_OR_NULL(). As a result, gpio_device_put() is not called if the gpio_device pointer is valid (meaning the ref is leaked), but only called if the pointer is NULL or an ERR_PTR(). While at it drop a superfluous trailing semicolon. Fixes: 9e4555d1e54a ("gpiolib: add support for scope-based management to gpio_device") Signed-off-by: Lukas Wunner <lukas@wunner.de> Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
|
#
5a2a2cda |
|
18-Dec-2023 |
Wang Jinchao <wangjinchao@xfusion.com> |
gpiolib: remove duplicate inclusions Remove second `#include <linux/err.h>`. Remove `#include <asm/errno.h>` too as it's included by `err.h`. Signed-off-by: Wang Jinchao <wangjinchao@xfusion.com> Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
|
#
f8d05e27 |
|
04-Dec-2023 |
Bartosz Golaszewski <bartosz.golaszewski@linaro.org> |
gpiolib: remove gpiochip_is_requested() We have no external users of gpiochip_is_requested(). Let's remove it and replace its internal calls with direct testing of the REQUESTED flag. Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org> Acked-by: Linus Walleij <linus.walleij@linaro.org>
|
#
6fd9c993 |
|
04-Dec-2023 |
Bartosz Golaszewski <bartosz.golaszewski@linaro.org> |
gpiolib: use gpiochip_dup_line_label() in for_each helpers Rework for_each_requested_gpio_in_range() to use the new helper to retrieve a dynamically allocated copy of the descriptor label and free it at the end of each iteration. We need to leverage the CLASS()' destructor to make sure that the label is freed even when breaking out of the loop. Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org> Acked-by: Linus Walleij <linus.walleij@linaro.org>
|
#
ee25fba7 |
|
04-Dec-2023 |
Bartosz Golaszewski <bartosz.golaszewski@linaro.org> |
gpiolib: provide gpiochip_dup_line_label() gpiochip_is_requested() not only has a misleading name but it returns a pointer to a string that is freed when the descriptor is released. Provide a new helper meant to replace it, which returns a copy of the label string instead. Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org> Acked-by: Linus Walleij <linus.walleij@linaro.org>
|
#
d1f77282 |
|
15-Nov-2023 |
Bartosz Golaszewski <bartosz.golaszewski@linaro.org> |
gpiolib: provide gpio_device_get_label() Provide a getter for the GPIO device label string so that users don't have to dereference struct gpio_chip directly. Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
|
#
2654521d |
|
05-Sep-2023 |
Bartosz Golaszewski <bartosz.golaszewski@linaro.org> |
gpiolib: remove gpiochip_find() With all users of gpiochip_find() converted to using gpio_device_find(), we can now remove this function from the kernel. Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
|
#
8c85a102 |
|
05-Sep-2023 |
Bartosz Golaszewski <bartosz.golaszewski@linaro.org> |
gpiolib: provide gpio_device_get_base() Let's start adding getters for the opaque struct gpio_device. Start with a function allowing to retrieve the base GPIO number. Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org> Acked-by: Linus Walleij <linus.walleij@linaro.org>
|
#
370232d0 |
|
11-Oct-2023 |
Bartosz Golaszewski <bartosz.golaszewski@linaro.org> |
gpiolib: provide gpiod_to_gpio_device() Accessing struct gpio_chip backing a GPIO device is only allowed for the actual providers of that chip. Similarly to how we introduced gpio_device_find() in order to replace the abused gpiochip_find(), let's introduce a counterpart to gpiod_to_chip() that returns a reference to the GPIO device owning the descriptor. This is done in order to later remove gpiod_to_chip() entirely. Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org> Reviewed-by: Peter Rosin <peda@axentia.se> Acked-by: Linus Walleij <linus.walleij@linaro.org>
|
#
1559d149 |
|
11-Oct-2023 |
Bartosz Golaszewski <bartosz.golaszewski@linaro.org> |
gpiolib: provide gpio_device_to_device() There are users in the kernel who need to retrieve the address of the struct device backing the GPIO device. Currently they needlessly poke in the internals of GPIOLIB. Add a dedicated getter function. Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org> Reviewed-by: Peter Rosin <peda@axentia.se> Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> Acked-by: Linus Walleij <linus.walleij@linaro.org>
|
#
668706b1 |
|
11-Oct-2023 |
Andy Shevchenko <andriy.shevchenko@linux.intel.com> |
gpiolib: provide gpio_device_find_by_fwnode() One of the ways of looking up GPIO devices is using their fwnode. Provide a helper for that to avoid every user implementing their own matching function. Reviewed-by: Dipen Patel <dipenp@nvidia.com> Tested-by: Dipen Patel <dipenp@nvidia.com> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Link: https://lore.kernel.org/r/20231010151709.4104747-2-andriy.shevchenko@linux.intel.com Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
|
#
9b418780 |
|
27-Sep-2023 |
Bartosz Golaszewski <bartosz.golaszewski@linaro.org> |
gpiolib: reluctantly provide gpio_device_get_chip() The process of converting all unauthorized users of struct gpio_chip to using dedicated struct gpio_device function will be long so in the meantime we must provide a way of retrieving the pointer to struct gpio_chip from a GPIO device. Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org> Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
|
#
93548f8b |
|
27-Sep-2023 |
Bartosz Golaszewski <bartosz.golaszewski@linaro.org> |
gpiolib: provide gpio_device_get_desc() Getting the GPIO descriptor directly from the gpio_chip struct is dangerous as we don't take the reference to the underlying GPIO device. In order to start working towards removing gpiochip_get_desc(), let's provide a safer variant that works with an existing reference to struct gpio_device. Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org> Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
|
#
d62fcd9f |
|
27-Sep-2023 |
Bartosz Golaszewski <bartosz.golaszewski@linaro.org> |
gpiolib: provide gpio_device_find_by_label() By far the most common way of looking up GPIO devices is using their label. Provide a helpers for that to avoid every user implementing their own matching function. Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org> Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
|
#
cfe102f6 |
|
27-Sep-2023 |
Bartosz Golaszewski <bartosz.golaszewski@linaro.org> |
gpiolib: provide gpio_device_find() gpiochip_find() is wrong and its kernel doc is misleading as the function doesn't return a reference to the gpio_chip but just a raw pointer. The chip itself is not guaranteed to stay alive, in fact it can be deleted at any point. Also: other than GPIO drivers themselves, nobody else has any business accessing gpio_chip structs. Provide a new gpio_device_find() function that returns a real reference to the opaque gpio_device structure that is guaranteed to stay alive for as long as there are active users of it. Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org> Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
|
#
9e4555d1 |
|
27-Sep-2023 |
Bartosz Golaszewski <bartosz.golaszewski@linaro.org> |
gpiolib: add support for scope-based management to gpio_device As the few users that need to get the reference to the GPIO device often release it right after inspecting its properties, let's add support for the automatic reference release to struct gpio_device. Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
|
#
36aa129f |
|
27-Sep-2023 |
Bartosz Golaszewski <bartosz.golaszewski@linaro.org> |
gpiolib: make gpio_device_get() and gpio_device_put() public In order to start migrating away from accessing struct gpio_chip by users other than their owners, let's first make the reference management functions for the opaque struct gpio_device public in the driver.h header. Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
|
#
fe4fa2e4 |
|
01-Sep-2023 |
Bartosz Golaszewski <bartosz.golaszewski@linaro.org> |
gpiolib: make gpiochip_get_desc() public It makes sense for a GPIO driver to want to get its own descriptor without requesting it. After all, the driver knows that it'll still be valid. Let's move this helper to linux/gpio/driver.h. Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org> Reviewed-by: Andy Shevchenko <andy@kernel.org> Acked-by: Linus Walleij <linus.walleij@linaro.org>
|
#
37d42ab3 |
|
01-Sep-2023 |
Bartosz Golaszewski <bartosz.golaszewski@linaro.org> |
gpiolib: remove unnecessary extern specifiers from the driver header 'extern' doesn't do anything for function declarations. Remove it. Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
|
#
8de54392 |
|
01-Sep-2023 |
Bartosz Golaszewski <bartosz.golaszewski@linaro.org> |
gpiolib: remove stray newline in gpio/driver.h Fix a double newline in the GPIO provider header. Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
|
#
a48b3f7b |
|
16-Jun-2023 |
Andy Shevchenko <andriy.shevchenko@linux.intel.com> |
gpiolib: Drop unused domain_ops memeber of GPIO IRQ chip It seems there is no driver that requires custom IRQ chip domain options. Drop the member and respective code. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Acked-by: Marc Zyngier <maz@kernel.org> Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
|
#
ff7a1790 |
|
19-Jun-2023 |
Michael Walle <mwalle@kernel.org> |
gpiolib: Fix irq_domain resource tracking for gpiochip_irqchip_add_domain() Up until commit 6a45b0e2589f ("gpiolib: Introduce gpiochip_irqchip_add_domain()") all irq_domains were allocated by gpiolib itself and thus gpiolib also takes care of freeing it. With gpiochip_irqchip_add_domain() a user of gpiolib can associate an irq_domain with the gpio_chip. This irq_domain is not managed by gpiolib and therefore must not be freed by gpiolib. Fixes: 6a45b0e2589f ("gpiolib: Introduce gpiochip_irqchip_add_domain()") Reported-by: Jiawen Wu <jiawenwu@trustnetic.com> Signed-off-by: Michael Walle <mwalle@kernel.org> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Reviewed-by: Andy Shevchenko <andy@kernel.org> Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@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>
|
#
6cfd84c4 |
|
07-Feb-2023 |
Andy Shevchenko <andriy.shevchenko@linux.intel.com> |
gpiolib: Drop unused forward declaration from driver.h There is no struct device_node pointers anywhere in the header, drop unused forward declaration. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
|
#
9a7dcaef |
|
12-Jan-2023 |
Andy Shevchenko <andriy.shevchenko@linux.intel.com> |
gpiolib: Do not mention legacy API in the code Replace mentioning of legacy API by the latest one. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
|
#
70d0fc42 |
|
28-Dec-2022 |
Andy Shevchenko <andriy.shevchenko@linux.intel.com> |
gpiolib: Get rid of not used of_node member All new drivers should use fwnode and / or parent to provide the necessary information to the GPIO library. Cc: Thierry Reding <treding@nvidia.com> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
|
#
b8f9301c |
|
13-Jan-2023 |
Andy Shevchenko <andriy.shevchenko@linux.intel.com> |
Revert "gpiolib: of: Introduce hook for missing gpio-ranges" This reverts commit 3550bba25d5587a701e6edf20e20984d2ee72c78. No users for this one, revert it for good. The ->add_pin_ranges() can be used instead. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Tested-by: Stefan Wahren <stefan.wahren@i2se.com> Tested-by: Florian Fainelli <f.fainelli@gmail.com> Reviewed-by: Florian Fainelli <f.fainelli@gmail.com> Acked-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org> Link: https://lore.kernel.org/r/20230113215352.44272-5-andriy.shevchenko@linux.intel.com Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
13e7accb |
|
11-Nov-2022 |
Thomas Gleixner <tglx@linutronix.de> |
genirq: Get rid of GENERIC_MSI_IRQ_DOMAIN Adjust to reality and remove another layer of pointless Kconfig indirection. CONFIG_GENERIC_MSI_IRQ is good enough to serve all purposes. Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Reviewed-by: Jason Gunthorpe <jgg@nvidia.com> Link: https://lore.kernel.org/r/20221111122014.524842979@linutronix.de
|
#
08a149c4 |
|
06-Oct-2022 |
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 While at it, fix some awkward indentations. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
|
#
91a29af4 |
|
07-Jul-2022 |
Marc Zyngier <maz@kernel.org> |
gpio: Remove dynamic allocation from populate_parent_alloc_arg() The gpiolib is unique in the way it uses intermediate fwspecs when feeding an interrupt specifier to the parent domain, as it relies on the populate_parent_alloc_arg() callback to perform a dynamic allocation. This is pretty inefficient (we free the structure almost immediately), and the only reason this isn't a stack allocation is that our ThunderX friend uses MSIs rather than a FW-constructed structure. Let's solve it by providing a new type composed of the union of a struct irq_fwspec and a msi_info_t, which satisfies both requirements. This allows us to use a stack allocation, and we can move the handful of users to this new scheme. Also perform some additional cleanup, such as getting rid of the stub versions of the irq_domain_translate_*cell helpers, which are never used when CONFIG_IRQ_DOMAIN_HIERARCHY isn't selected. Tested on a Tegra186. Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Marc Zyngier <maz@kernel.org> Cc: Daniel Palmer <daniel@thingy.jp> Cc: Romain Perier <romain.perier@gmail.com> Cc: Bartosz Golaszewski <brgl@bgdev.pl> Cc: Thierry Reding <thierry.reding@gmail.com> Cc: Jonathan Hunter <jonathanh@nvidia.com> Cc: Robert Richter <rric@kernel.org> Cc: Nobuhiro Iwamatsu <nobuhiro1.iwamatsu@toshiba.co.jp> Cc: Andy Gross <agross@kernel.org> Cc: Bjorn Andersson <bjorn.andersson@linaro.org> Acked-by: Bartosz Golaszewski <brgl@bgdev.pl> Link: https://lore.kernel.org/r/20220707182314.66610-2-prabhakar.mahadev-lad.rj@bp.renesas.com
|
#
c7e1c443 |
|
05-Jun-2022 |
Akira Yokosawa <akiyks@gmail.com> |
gpio: Fix kernel-doc comments to nested union Commit 48ec13d36d3f ("gpio: Properly document parent data union") is supposed to have fixed a warning from "make htmldocs" regarding kernel-doc comments to union members. However, the same warning still remains [1]. Fix the issue by following the example found in section "Nested structs/unions" of Documentation/doc-guide/kernel-doc.rst. Signed-off-by: Akira Yokosawa <akiyks@gmail.com> Reported-by: Stephen Rothwell <sfr@canb.auug.org.au> Fixes: 48ec13d36d3f ("gpio: Properly document parent data union") Link: https://lore.kernel.org/r/20220606093302.21febee3@canb.auug.org.au/ [1] Cc: Linus Walleij <linus.walleij@linaro.org> Cc: Bartosz Golaszewski <brgl@bgdev.pl> Cc: Joey Gouly <joey.gouly@arm.com> Cc: Marc Zyngier <maz@kernel.org> Tested-by: Stephen Rothwell <sfr@canb.auug.org.au> Reviewed-by: Mauro Carvalho Chehab <mchehab@kernel.org> 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>
|
#
3550bba2 |
|
09-Apr-2022 |
Stefan Wahren <stefan.wahren@i2se.com> |
gpiolib: of: Introduce hook for missing gpio-ranges Since commit 2ab73c6d8323 ("gpio: Support GPIO controllers without pin-ranges") the device tree nodes of GPIO controller need the gpio-ranges property to handle gpio-hogs. Unfortunately it's impossible to guarantee that every new kernel is shipped with an updated device tree binary. In order to provide backward compatibility with those older DTB, we need a callback within of_gpiochip_add_pin_range() so the relevant platform driver can handle this case. Fixes: 2ab73c6d8323 ("gpio: Support GPIO controllers without pin-ranges") Signed-off-by: Stefan Wahren <stefan.wahren@i2se.com> Reviewed-by: Florian Fainelli <f.fainelli@gmail.com> Tested-by: Florian Fainelli <f.fainelli@gmail.com> Acked-by: Bartosz Golaszewski <brgl@bgdev.pl> Link: https://lore.kernel.org/r/20220409095129.45786-2-stefan.wahren@i2se.com Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
3c938cc5 |
|
18-Apr-2022 |
Schspa Shi <schspa@gmail.com> |
gpio: use raw spinlock for gpio chip shadowed data In case of PREEMPT_RT, there is a raw_spinlock -> spinlock dependency as the lockdep report shows. __irq_set_handler irq_get_desc_buslock __irq_get_desc_lock raw_spin_lock_irqsave(&desc->lock, *flags); // raw spinlock get here __irq_do_set_handler mask_ack_irq dwapb_irq_ack spin_lock_irqsave(&gc->bgpio_lock, flags); // sleep able spinlock irq_put_desc_busunlock Replace with a raw lock to avoid BUGs. This lock is only used to access registers, and It's safe to replace with the raw lock without bad influence. [ 15.090359][ T1] ============================= [ 15.090365][ T1] [ BUG: Invalid wait context ] [ 15.090373][ T1] 5.10.59-rt52-00983-g186a6841c682-dirty #3 Not tainted [ 15.090386][ T1] ----------------------------- [ 15.090392][ T1] swapper/0/1 is trying to lock: [ 15.090402][ T1] 70ff00018507c188 (&gc->bgpio_lock){....}-{3:3}, at: _raw_spin_lock_irqsave+0x1c/0x28 [ 15.090470][ T1] other info that might help us debug this: [ 15.090477][ T1] context-{5:5} [ 15.090485][ T1] 3 locks held by swapper/0/1: [ 15.090497][ T1] #0: c2ff0001816de1a0 (&dev->mutex){....}-{4:4}, at: __device_driver_lock+0x98/0x104 [ 15.090553][ T1] #1: ffff90001485b4b8 (irq_domain_mutex){+.+.}-{4:4}, at: irq_domain_associate+0xbc/0x6d4 [ 15.090606][ T1] #2: 4bff000185d7a8e0 (lock_class){....}-{2:2}, at: _raw_spin_lock_irqsave+0x1c/0x28 [ 15.090654][ T1] stack backtrace: [ 15.090661][ T1] CPU: 4 PID: 1 Comm: swapper/0 Not tainted 5.10.59-rt52-00983-g186a6841c682-dirty #3 [ 15.090682][ T1] Hardware name: Horizon Robotics Journey 5 DVB (DT) [ 15.090692][ T1] Call trace: ...... [ 15.090811][ T1] _raw_spin_lock_irqsave+0x1c/0x28 [ 15.090828][ T1] dwapb_irq_ack+0xb4/0x300 [ 15.090846][ T1] __irq_do_set_handler+0x494/0xb2c [ 15.090864][ T1] __irq_set_handler+0x74/0x114 [ 15.090881][ T1] irq_set_chip_and_handler_name+0x44/0x58 [ 15.090900][ T1] gpiochip_irq_map+0x210/0x644 Signed-off-by: Schspa Shi <schspa@gmail.com> Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> Acked-by: Linus Walleij <linus.walleij@linaro.org> Acked-by: Doug Berger <opendmb@gmail.com> Acked-by: Serge Semin <fancer.lancer@gmail.com> Signed-off-by: Bartosz Golaszewski <brgl@bgdev.pl>
|
#
af47d803 |
|
14-Apr-2022 |
Andy Shevchenko <andriy.shevchenko@linux.intel.com> |
gpiolib: Introduce a helper to get first GPIO controller node Introduce a helper to get first GPIO controller node which drivers may want to use. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Tested-by: Marek Szyprowski <m.szyprowski@samsung.com>
|
#
0b19dde9 |
|
01-Apr-2022 |
Andy Shevchenko <andriy.shevchenko@linux.intel.com> |
gpiolib: Introduce gpiochip_node_count() helper The gpiochip_node_count() helper iterates over the device child nodes that have the "gpio-controller" property set. It returns the number of such nodes under a given device. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be> Tested-by: Geert Uytterhoeven <geert+renesas@glider.be> Acked-by: Bartosz Golaszewski <brgl@bgdev.pl>
|
#
85ebb1a6 |
|
01-Apr-2022 |
Andy Shevchenko <andriy.shevchenko@linux.intel.com> |
gpiolib: Introduce for_each_gpiochip_node() loop helper Introduce for_each_gpiochip_node() loop helper which iterates over the GPIO controller child nodes of a given device. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be> Tested-by: Geert Uytterhoeven <geert+renesas@glider.be> Acked-by: Bartosz Golaszewski <brgl@bgdev.pl>
|
#
36b78aae |
|
19-Apr-2022 |
Marc Zyngier <maz@kernel.org> |
gpio: Add helpers to ease the transition towards immutable irq_chip Add a couple of new helpers to make it slightly simpler to convert drivers to immutable irq_chip structures: - GPIOCHIP_IRQ_RESOURCE_HELPERS populates the irq_chip structure with the resource management callbacks - gpio_irq_chip_set_chip() populates the gpio_irq_chip.chip structure, avoiding the proliferation of ugly casts Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> Reviewed-by: Bartosz Golaszewski <brgl@bgdev.pl> Signed-off-by: Marc Zyngier <maz@kernel.org> Link: https://lore.kernel.org/r/20220419141846.598305-4-maz@kernel.org
|
#
704f0875 |
|
19-Apr-2022 |
Marc Zyngier <maz@kernel.org> |
gpio: Expose the gpiochip_irq_re[ql]res helpers The GPIO subsystem has a couple of internal helpers to manage resources on behalf of the irqchip. Expose them so that GPIO drivers can use them directly. Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> Reviewed-by: Bartosz Golaszewski <brgl@bgdev.pl> Signed-off-by: Marc Zyngier <maz@kernel.org> Link: https://lore.kernel.org/r/20220419141846.598305-3-maz@kernel.org
|
#
5467801f |
|
21-Mar-2022 |
Shreeya Patel <shreeya.patel@collabora.com> |
gpio: Restrict usage of GPIO chip irq members before initialization GPIO chip irq members are exposed before they could be completely initialized and this leads to race conditions. One such issue was observed for the gc->irq.domain variable which was accessed through the I2C interface in gpiochip_to_irq() before it could be initialized by gpiochip_add_irqchip(). This resulted in Kernel NULL pointer dereference. Following are the logs for reference :- kernel: Call Trace: kernel: gpiod_to_irq+0x53/0x70 kernel: acpi_dev_gpio_irq_get_by+0x113/0x1f0 kernel: i2c_acpi_get_irq+0xc0/0xd0 kernel: i2c_device_probe+0x28a/0x2a0 kernel: really_probe+0xf2/0x460 kernel: RIP: 0010:gpiochip_to_irq+0x47/0xc0 To avoid such scenarios, restrict usage of GPIO chip irq members before they are completely initialized. Signed-off-by: Shreeya Patel <shreeya.patel@collabora.com> Cc: stable@vger.kernel.org Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Bartosz Golaszewski <brgl@bgdev.pl>
|
#
48ec13d3 |
|
17-Mar-2022 |
Joey Gouly <joey.gouly@arm.com> |
gpio: Properly document parent data union Suppress a warning in the html docs by documenting these fields separately. Signed-off-by: Joey Gouly <joey.gouly@arm.com> Link: https://lore.kernel.org/lkml/20211027220118.71a229ab@canb.auug.org.au/ Cc: Linus Walleij <linus.walleij@linaro.org> Cc: Bartosz Golaszewski <brgl@bgdev.pl> Cc: Marc Zyngier <maz@kernel.org> Cc: Stephen Rothwell <sfr@canb.auug.org.au> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Bartosz Golaszewski <brgl@bgdev.pl>
|
#
990f6756 |
|
13-Dec-2021 |
Bartosz Golaszewski <brgl@bgdev.pl> |
gpiolib: allow to specify the firmware node in struct gpio_chip Software nodes allow us to represent hierarchies for device components that don't have their struct device representation yet - for instance: banks of GPIOs under a common GPIO expander. The core gpiolib core however doesn't offer any way of passing this information from the drivers. This extends struct gpio_chip with a pointer to fwnode that can be set by the driver and used to pass device properties for child nodes. This is similar to how we handle device-tree sub-nodes with CONFIG_OF_GPIO enabled. Signed-off-by: Bartosz Golaszewski <brgl@bgdev.pl> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Acked-by: Linus Walleij <linus.walleij@linaro.org>
|
#
cfe6807d |
|
26-Oct-2021 |
Marc Zyngier <maz@kernel.org> |
gpio: Allow per-parent interrupt data The core gpiolib code is able to deal with multiple interrupt parents for a single gpio irqchip. It however only allows a single piece of data to be conveyed to all flow handlers (either the gpio_chip or some other, driver-specific data). This means that drivers have to go through some interesting dance to find the correct context, something that isn't great in interrupt context (see aebdc8abc9db86e2bd33070fc2f961012fff74b4 for a prime example). Instead, offer an optional way for a pinctrl/gpio driver to provide an array of pointers which gets used to provide the correct context to the flow handler. Signed-off-by: Marc Zyngier <maz@kernel.org> Signed-off-by: Joey Gouly <joey.gouly@arm.com> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Link: https://lore.kernel.org/r/20211026175815.52703-2-joey.gouly@arm.com Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
4e804c39 |
|
27-Jul-2021 |
Sergio Paracuellos <sergio.paracuellos@gmail.com> |
gpiolib: convert 'devprop_gpiochip_set_names' to support multiple gpiochip banks per device The default gpiolib-of implementation does not work with the multiple gpiochip banks per device structure used for example by the gpio-mt7621 and gpio-brcmstb drivers. To fix these kind of situations driver code is forced to fill the names to avoid the gpiolib code to set names repeated along the banks. Instead of continue with that antipattern fix the gpiolib core function to get expected behaviour for every single situation adding a field 'offset' in the gpiochip structure. Doing in this way, we can assume this offset will be zero for normal driver code where only one gpiochip bank per device is used but can be set explicitly in those drivers that really need more than one gpiochip. Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> Reviewed-by: Gregory Fong <gregory.0xf0@gmail.com> Signed-off-by: Sergio Paracuellos <sergio.paracuellos@gmail.com> Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
|
#
2d93018f |
|
23-Mar-2021 |
Randy Dunlap <rdunlap@infradead.org> |
gpiolib: some edits of kernel docs for clarity Fix a few typos and some punctuation. Also, change CONFIG_OF to CONFIG_OF_GPIO in one comment. Signed-off-by: Randy Dunlap <rdunlap@infradead.org> Cc: Linus Walleij <linus.walleij@linaro.org> Cc: Bartosz Golaszewski <bgolaszewski@baylibre.com> Cc: linux-gpio@vger.kernel.org Reviewed-by: Linus Walleij <linus.walleij@linaro.org> [Bartosz: tweaked the commit message] Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
|
#
9c7d2469 |
|
24-Mar-2021 |
Álvaro Fernández Rojas <noltari@gmail.com> |
gpio: guard gpiochip_irqchip_add_domain() with GPIOLIB_IRQCHIP The current code doesn't check if GPIOLIB_IRQCHIP is enabled, which results in a compilation error when trying to build gpio-regmap if CONFIG_GPIOLIB_IRQCHIP isn't enabled. Fixes: 6a45b0e2589f ("gpiolib: Introduce gpiochip_irqchip_add_domain()") Suggested-by: Michael Walle <michael@walle.cc> Signed-off-by: Álvaro Fernández Rojas <noltari@gmail.com> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Reviewed-by: Michael Walle <michael@walle.cc> Acked-by: Bartosz Golaszewski <bgolaszewski@baylibre.com> Link: https://lore.kernel.org/r/20210324081923.20379-2-noltari@gmail.com Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
f1f37abb |
|
19-Oct-2020 |
Linus Walleij <linus.walleij@linaro.org> |
gpio: Retire the explicit gpio irqchip code Now that all gpiolib irqchip users have been over to use the irqchip template, we can finally retire the old code path and leave just one way in to the irqchip: set up the template when registering the gpio_chip. For a while we had two code paths for this which was a bit confusing. This brings this work to a conclusion, there is now one way of doing this. Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> Cc: Thierry Reding <thierry.reding@gmail.com> Link: https://lore.kernel.org/r/20201019134046.65101-1-linus.walleij@linaro.org
|
#
32fc5aa2 |
|
09-Sep-2020 |
Bartosz Golaszewski <bgolaszewski@baylibre.com> |
gpiolib: unexport devprop_gpiochip_set_names() Now that devprop_gpiochip_set_names() is only used in a single place inside drivers/gpio/gpiolib.c, there's no need anymore for it to be exported or to even live in its own source file. Pull this function into the core source file for gpiolib. Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com> Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
|
#
7cba1a4d |
|
09-Sep-2020 |
Bartosz Golaszewski <bgolaszewski@baylibre.com> |
gpiolib: generalize devprop_gpiochip_set_names() for device properties devprop_gpiochip_set_names() is overly complicated with taking the fwnode argument (which requires using dev_fwnode() & of_fwnode_handle() in ACPI and OF GPIO code respectively). Let's just switch to using the generic device properties. This allows us to pull the code setting line names directly into gpiochip_add_data_with_key() instead of handling it separately for ACPI and OF. Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com>
|
#
5f402bb1 |
|
31-Jul-2020 |
Ahmad Fatoum <a.fatoum@pengutronix.de> |
gpio: don't use same lockdep class for all devm_gpiochip_add_data users Commit 959bc7b22bd2 ("gpio: Automatically add lockdep keys") documents in its commits message its intention to "create a unique class key for each driver". It does so by having gpiochip_add_data add in-place the definition of two static lockdep classes for LOCKDEP use. That way, every caller of the macro adds their gpiochip with unique lockdep classes. There are many indirect callers of gpiochip_add_data, however, via use of devm_gpiochip_add_data. devm_gpiochip_add_data has external linkage and all its users will share the same lockdep classes, which probably is not intended. Fix this by replicating the gpio_chip_add_data statics-in-macro for the devm_ version as well. Fixes: 959bc7b22bd2 ("gpio: Automatically add lockdep keys") Signed-off-by: Ahmad Fatoum <a.fatoum@pengutronix.de> Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> Reviewed-by: Bartosz Golaszewski <bgolaszewski@baylibre.com> Link: https://lore.kernel.org/r/20200731123835.8003-1-a.fatoum@pengutronix.de Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
8fc3ed3a |
|
23-Jul-2020 |
Colton Lewis <colton.w.lewis@protonmail.com> |
gpio: Correct kernel-doc inconsistency Fix kernel-doc comment to match parameter name change "chip" to "gc" in gpiochip_add_data function. Signed-off-by: Colton Lewis <colton.w.lewis@protonmail.com> Link: https://lore.kernel.org/r/20200723095658.234668-1-colton.w.lewis@protonmail.com Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
b3337eb2 |
|
15-Jun-2020 |
Andy Shevchenko <andriy.shevchenko@linux.intel.com> |
gpiolib: Introduce for_each_requested_gpio_in_range() macro Introduce for_each_requested_gpio_in_range() macro which helps to iterate over requested GPIO in a range. There are already potential users of it, which are going to be converted by the following patches. For most of them for_each_requested_gpio() shortcut has been added. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Link: https://lore.kernel.org/r/20200615150545.87964-2-andriy.shevchenko@linux.intel.com Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
e012d15a |
|
15-Jun-2020 |
Mauro Carvalho Chehab <mchehab+huawei@kernel.org> |
gpio: driver.h: fix kernel-doc markup There is one parameter with a wrong name at kernel-doc macro: ./include/linux/gpio/driver.h:499: warning: Function parameter or member 'gc' not described in 'gpiochip_add_data' ./include/linux/gpio/driver.h:499: warning: Excess function parameter 'chip' description in 'gpiochip_add_data' Fix it. Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org> Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
|
#
6a45b0e2 |
|
28-May-2020 |
Michael Walle <michael@walle.cc> |
gpiolib: Introduce gpiochip_irqchip_add_domain() The function connects an IRQ domain to a gpiochip and reuses gpiochip_to_irq() which is provided by gpiolib. gpiochip_irqchip_* and regmap_irq partially provide the same functionality. This function will help to connect just the minimal functionality of the gpiochip_irqchip which is needed to work together with regmap-irq. Signed-off-by: Michael Walle <michael@walle.cc> Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> Link: https://lore.kernel.org/r/20200528145845.31436-2-michael@walle.cc Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
a8173820 |
|
23-May-2020 |
Maulik Shah <mkshah@codeaurora.org> |
gpio: gpiolib: Allow GPIO IRQs to lazy disable With 'commit 461c1a7d4733 ("gpiolib: override irq_enable/disable")' gpiolib overrides irqchip's irq_enable and irq_disable callbacks. If irq_disable callback is implemented then genirq takes unlazy path to disable irq. Underlying irqchip may not want to implement irq_disable callback to lazy disable irq when client drivers invokes disable_irq(). By overriding irq_disable callback, gpiolib ends up always unlazy disabling IRQ. Allow gpiolib to lazy disable IRQs by overriding irq_disable callback only if irqchip implemented irq_disable. In cases where irq_disable is not implemented irq_mask is overridden. Similarly override irq_enable callback only if irqchip implemented irq_enable otherwise irq_unmask is overridden. Fixes: 461c1a7d4733 ("gpiolib: override irq_enable/disable") Signed-off-by: Maulik Shah <mkshah@codeaurora.org> Tested-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Link: https://lore.kernel.org/r/1590253873-11556-2-git-send-email-mkshah@codeaurora.org Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
8d091012 |
|
28-Apr-2020 |
Douglas Anderson <dianders@chromium.org> |
gpio: Make "offset" and "unsigned int", not just "unsigned" When I copied the function prototypes from the GPIO header file into my own driver, checkpatch yelled at me saying that I shouldn't use use "unsigned" but instead should say "unsigned int". Let's make the header file use "unsigned int" so others who copy like I did won't get yelled at. Signed-off-by: Douglas Anderson <dianders@chromium.org> Link: https://lore.kernel.org/r/20200428172322.2.Iacb3c8152c3cf9015a91308678155a578b0cc050@changeid Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
36b52154 |
|
28-Apr-2020 |
Douglas Anderson <dianders@chromium.org> |
gpio: Document proper return value for gpio drivers The legacy defines GPIOF_DIR_XXX are only for consumers. Document the proper ones. Also: don't use "_XXX" since that's harder to find with "git grep". Just list both of the values. Signed-off-by: Douglas Anderson <dianders@chromium.org> Link: https://lore.kernel.org/r/20200428172322.1.I396f351e364f3c09df7c7606e79abefb8682c092@changeid Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
a0b66a73 |
|
29-Mar-2020 |
Linus Walleij <linus.walleij@linaro.org> |
gpio: Rename variable in core APIs There is struct gpio *gc, *chip and *gpiochip, and yes I am responsible for some of the inconsistencies. I want this to be just gc everywhere for minimizing cognitive resistance when reading the code: more compact function signatures and less clutter. Purely syntactic changes intended. No semantic effects. Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Link: https://lore.kernel.org/r/20200329140405.52276-1-linus.walleij@linaro.org Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
d19d2de6 |
|
15-Mar-2020 |
Chuanhong Guo <gch981213@gmail.com> |
gpio: mmio: introduce BGPIOF_NO_SET_ON_INPUT Some gpio controllers ignores pin value writing when that pin is configured as input mode. As a result, bgpio_dir_out should set pin to output before configuring pin values or gpio pin values can't be set up properly. Introduce two variants of bgpio_dir_out: bgpio_dir_out_val_first and bgpio_dir_out_dir_first, and assign direction_output according to a new flag: BGPIOF_NO_SET_ON_INPUT. Signed-off-by: Chuanhong Guo <gch981213@gmail.com> Tested-by: René van Dorst <opensource@vdorst.com> Reviewed-by: Sergio Paracuellos <sergio.paracuellos@gmail.com> Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
|
#
72780ce5 |
|
13-Jan-2020 |
Linus Walleij <linus.walleij@linaro.org> |
gpio: Drop the chained IRQ handler assign function gpiochip_set_chained_irqchip() would assign a chained handler to a GPIO chip. We now populate struct gpio_irq_chip for all chained GPIO irqchips so drop this function. Cc: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Link: https://lore.kernel.org/r/20200113220800.77817-1-linus.walleij@linaro.org Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
9c6722d8 |
|
16-Jan-2020 |
Kevin Hao <haokexin@gmail.com> |
gpio: Fix the no return statement warning In commit 242587616710 ("gpiolib: Add support for the irqdomain which doesn't use irq_fwspec as arg") we have changed the return type of gpiochip_populate_parent_fwspec_twocell/fourcell() from void to void *, but forgot to add a return statement for these two dummy functions. Add "return NULL" to fix the build warnings. Reported-by: kbuild test robot <lkp@intel.com> Signed-off-by: Kevin Hao <haokexin@gmail.com> Link: https://lore.kernel.org/r/20200116095003.30324-1-haokexin@gmail.com Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
24258761 |
|
14-Jan-2020 |
Kevin Hao <haokexin@gmail.com> |
gpiolib: Add support for the irqdomain which doesn't use irq_fwspec as arg Some gpio's parent irqdomain may not use the struct irq_fwspec as argument, such as msi irqdomain. So rename the callback populate_parent_fwspec() to populate_parent_alloc_arg() and make it allocate and populate the specific struct which is needed by the parent irqdomain. Signed-off-by: Kevin Hao <haokexin@gmail.com> Link: https://lore.kernel.org/r/20200114082821.14015-3-haokexin@gmail.com Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
06863620 |
|
24-Dec-2019 |
Bartosz Golaszewski <bgolaszewski@baylibre.com> |
gpiolib: convert the type of hwnum to unsigned int in gpiochip_get_desc() gpiochip_get_desc() takes a u16 hwnum, but it turns out most users don't respect that and usually pass an unsigned int. Since implicit casting to a smaller type is dangerous - let's change the type of hwnum to unsigned int in gpiochip_get_desc() and in gpiochip_request_own_desc() where the size of hwnum is not respected either and who's a user of the former. This is safe as we then check the hwnum against the number of lines before proceeding in gpiochip_get_desc(). Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com> Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
|
#
b056ca1c |
|
04-Nov-2019 |
Andy Shevchenko <andriy.shevchenko@linux.intel.com> |
gpiolib: Introduce ->add_pin_ranges() callback When IRQ chip is being added by GPIO library, the ACPI based platform expects GPIO <-> pin mapping ranges to be initialized in order to correctly initialize ACPI event mechanism on affected platforms. Unfortunately this step is missed. Introduce ->add_pin_ranges() callback to fill the above mentioned gap. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com> Reviewed-by: Hans de Goede <hdegoede@redhat.com> Tested-by: Hans de Goede <hdegoede@redhat.com>
|
#
9208b1e7 |
|
06-Nov-2019 |
Matti Vaittinen <matti.vaittinen@fi.rohmeurope.com> |
gpio: Add definition for GPIO direction At least for me it is difficult to remember the meaning of GPIO direction values. Define GPIO_LINE_DIRECTION_IN and GPIO_LINE_DIRECTION_OUT so that occasional GPIO contributors would not need to always check the meaning of hard coded values 1 and 0. Signed-off-by: Matti Vaittinen <matti.vaittinen@fi.rohmeurope.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
9411e3aa |
|
09-Oct-2019 |
Andy Shevchenko <andriy.shevchenko@linux.intel.com> |
gpiolib: Initialize the hardware with a callback After changing the drivers to use GPIO core to add an IRQ chip it appears that some of them requires a hardware initialization before adding the IRQ chip. Add an optional callback ->init_hw() to allow that drivers to initialize hardware if needed. This change is a part of the fix NULL pointer dereference brought to the several drivers recently. Cc: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
5fbe5b58 |
|
04-Sep-2019 |
Linus Walleij <linus.walleij@linaro.org> |
gpio: Initialize the irqchip valid_mask with a callback After changing the valid_mask for the struct gpio_chip to detect the need and presence of a valid mask with the presence of a .init_valid_mask() callback to fill it in, we augment the gpio_irq_chip to use the same logic. Switch all driver using the gpio_irq_chio valid_mask over to this new method. This makes sure the valid_mask for the gpio_irq_chip gets filled in when we add the gpio_chip, which makes it a little easier to switch over drivers using the old way of setting up gpio_irq_chip over to the new method of passing the gpio_irq_chip along with the gpio_chip. (See drivers/gpio/TODO for details.) Cc: Joel Stanley <joel@jms.id.au> Cc: Thierry Reding <treding@nvidia.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Tested-by: Hans de Goede <hdegoede@redhat.com> Reviewed-by: Andrew Jeffery <andrew@aj.id.au> Acked-by: Mika Westerberg <mika.westerberg@linux.intel.com> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Reviewed-by: Patrice Chotard <patrice.chotard@st.com> Link: https://lore.kernel.org/r/20190904140104.32426-1-linus.walleij@linaro.org
|
#
ae0755b5 |
|
05-Sep-2019 |
Linus Walleij <linus.walleij@linaro.org> |
gpio: Fix up merge collision in include file The merge of two different patch sets cleaning around in the main driver include file collided making the function declarations for gpiochip_[un]lock_as_irq() be defined twice when gpiolib was unselected. Fix it up. Cc: YueHaibing <yuehaibing@huawei.com> Cc: Masahiro Yamada <yamada.masahiro@socionext.com> Reported-by: kbuild test robot <lkp@intel.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
c7663fa2 |
|
21-Aug-2019 |
YueHaibing <yuehaibing@huawei.com> |
gpio: Move gpiochip_lock/unlock_as_irq to gpio/driver.h If CONFIG_GPIOLIB is not, gpiochip_lock/unlock_as_irq will conflict as this: In file included from sound/soc/codecs/wm5100.c:18:0: ./include/linux/gpio.h:224:19: error: static declaration of gpiochip_lock_as_irq follows non-static declaration static inline int gpiochip_lock_as_irq(struct gpio_chip *chip, ^~~~~~~~~~~~~~~~~~~~ In file included from sound/soc/codecs/wm5100.c:17:0: ./include/linux/gpio/driver.h:494:5: note: previous declaration of gpiochip_lock_as_irq was here int gpiochip_lock_as_irq(struct gpio_chip *chip, unsigned int offset); ^~~~~~~~~~~~~~~~~~~~ In file included from sound/soc/codecs/wm5100.c:18:0: ./include/linux/gpio.h:231:20: error: static declaration of gpiochip_unlock_as_irq follows non-static declaration static inline void gpiochip_unlock_as_irq(struct gpio_chip *chip, ^~~~~~~~~~~~~~~~~~~~~~ In file included from sound/soc/codecs/wm5100.c:17:0: ./include/linux/gpio/driver.h:495:6: note: previous declaration of gpiochip_unlock_as_irq was here void gpiochip_unlock_as_irq(struct gpio_chip *chip, unsigned int offset); ^~~~~~~~~~~~~~~~~~~~~~ Move them to gpio/driver.h and use CONFIG_GPIOLIB guard this. Reported-by: Hulk Robot <hulkci@huawei.com> Fixes: d74be6dfea1b ("gpio: remove gpiod_lock/unlock_as_irq()") Signed-off-by: YueHaibing <yuehaibing@huawei.com> Link: https://lore.kernel.org/r/20190822031817.32888-1-yuehaibing@huawei.com Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
eb1e8bd6 |
|
19-Aug-2019 |
Linus Walleij <linus.walleij@linaro.org> |
gpio: Use callback presence to determine need of valid_mask After we switched the two drivers that have .need_valid_mask set to use the callback for setting up the .valid_mask, we can just use the presence of the .init_valid_mask() callback (or the OF reserved ranges, nota bene) to determine whether to allocate the mask or not and we can drop the .need_valid_mask field altogether. Cc: Benjamin Gaignard <benjamin.gaignard@st.com> Cc: Amelie Delaunay <amelie.delaunay@st.com> Cc: Stephen Boyd <swboyd@chromium.org> Cc: Bjorn Andersson <bjorn.andersson@linaro.org> Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Link: https://lore.kernel.org/r/20190819093058.10863-1-linus.walleij@linaro.org
|
#
c9fc5aff |
|
19-Aug-2019 |
Linus Walleij <linus.walleij@linaro.org> |
gpio: Pass mask and size with the init_valid_mask() It is more helpful for drivers to have the affected fields directly available when we use the callback to set up the valid mask. Change this and switch over the only user (MSM) to use the passed parameters. If we do this we can also move the mask out of publicly visible struct fields. Cc: Stephen Boyd <swboyd@chromium.org> Cc: Bjorn Andersson <bjorn.andersson@linaro.org> Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Link: https://lore.kernel.org/r/20190819084904.30027-1-linus.walleij@linaro.or Reviewed-by: Stephen Boyd <swboyd@chromium.org> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
f52a0c7b |
|
16-Aug-2019 |
Stephen Rothwell <sfr@canb.auug.org.au> |
gpio: stubs in headers should be inline Fixes: fdd61a013a24 ("gpio: Add support for hierarchical IRQ domains") Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au> Link: https://lore.kernel.org/r/20190816213812.40a130db@canb.auug.org.au Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
fdd61a01 |
|
08-Aug-2019 |
Linus Walleij <linus.walleij@linaro.org> |
gpio: Add support for hierarchical IRQ domains Hierarchical IRQ domains can be used to stack different IRQ controllers on top of each other. Bring hierarchical IRQ domains into the GPIOLIB core with the following basic idea: Drivers that need their interrupts handled hierarchically specify a callback to translate the child hardware IRQ and IRQ type for each GPIO offset to a parent hardware IRQ and parent hardware IRQ type. Users have to pass the callback, fwnode, and parent irqdomain before calling gpiochip_irqchip_add(). We use the new method of just filling in the struct gpio_irq_chip before adding the gpiochip for all hierarchical irqchips of this type. The code path for device tree is pretty straight-forward, while the code path for old boardfiles or anything else will be more convoluted requireing upfront allocation of the interrupts when adding the chip. One specific use-case where this can be useful is if a power management controller has top-level controls for wakeup interrupts. In such cases, the power management controller can be a parent to other interrupt controllers and program additional registers when an IRQ has its wake capability enabled or disabled. The hierarchical irqchip helper code will only be available when IRQ_DOMAIN_HIERARCHY is selected to GPIO chips using this should select or depend on that symbol. When using hierarchical IRQs, the parent interrupt controller must also be hierarchical all the way up to the top interrupt controller wireing directly into the CPU, so on systems that do not have this we can get rid of all the extra code for supporting hierarchical irqs. Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Marc Zyngier <marc.zyngier@arm.com> Cc: Lina Iyer <ilina@codeaurora.org> Cc: Jon Hunter <jonathanh@nvidia.com> Cc: Sowjanya Komatineni <skomatineni@nvidia.com> Cc: Bitan Biswas <bbiswas@nvidia.com> Cc: linux-tegra@vger.kernel.org Cc: David Daney <david.daney@cavium.com> Cc: Masahiro Yamada <yamada.masahiro@socionext.com> Cc: Brian Masney <masneyb@onstation.org> Signed-off-by: Thierry Reding <treding@nvidia.com> Signed-off-by: Brian Masney <masneyb@onstation.org> Co-developed-by: Brian Masney <masneyb@onstation.org> Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Link: https://lore.kernel.org/r/20190808123242.5359-1-linus.walleij@linaro.org
|
#
9091373a |
|
29-Jul-2019 |
Masahiro Yamada <yamada.masahiro@socionext.com> |
gpio: remove less important #ifdef around declarations The whole struct/function declarations in this header are surrounded by #ifdef. As far as I understood, the motivation of this is probably to break the build earlier if a driver misses to select or depend on correct CONFIG options in Kconfig. Since commit 94bed2a9c4ae ("Add -Werror-implicit-function-declaration") no one cannot call functions that have not been declared. So, I see some benefit in doing this in the cost of uglier headers. In reality, it would not be so easy to catch missed 'select' or 'depends on' because GPIOLIB, GPIOLIB_IRQCHIP etc. are already selected by someone else eventually. So, this kind of error, if any, will be caught by randconfig bots. In summary, I am not a big fan of cluttered #ifdef nesting, and this does not matter for normal developers. The code readability wins. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
|
#
f99d479b |
|
01-Jul-2019 |
Geert Uytterhoeven <geert+renesas@glider.be> |
gpiolib: Document new gpio_chip.init_valid_mask field A new field init_valid_mask was added to struct gpio_chip, but it was not documented. Fixes: f8ec92a9f63b3b11 ("gpiolib: Add init_valid_mask exported function") Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Link: https://lore.kernel.org/r/20190701142650.25122-1-geert+renesas@glider.be Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
f310f2ef |
|
17-Jun-2019 |
Enrico Weigelt <info@metux.net> |
gpio: Add comments on #if/#else/#endif Improve readability a bit by commenting #if/#else/#endif statements with the checked preprocessor symbols. Signed-off-by: Enrico Weigelt <info@metux.net> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
4892d3a6 |
|
14-Jun-2019 |
Linus Walleij <linus.walleij@linaro.org> |
gpio: Drop the parent_irq from gpio_irq_chip We already have an array named "parents" so instead of letting one point to the other, simply allocate a dynamic array to hold the parents, just one if desired and drop the number of members in gpio_irq_chip by 1. Rename gpiochip to gc in the process. Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
d664c439 |
|
12-Jun-2019 |
Enrico Weigelt <info@metux.net> |
gpio: Fix build warnings on undefined struct pinctrl_dev This fixes the warnings: * include/linux/gpio.h:254:11: warning: 'struct pinctrl_dev' declared inside parameter list will not be visible outside of this definition or declaration * include/linux/gpio/driver.h:602:11: warning: 'struct pinctrl_dev' declared inside parameter list will not be visible outside of this definition or declaration Fixes: 78b99577b393 ("pinctrl: remove unused pin_is_valid()") Reported-by: kbuild test robot <lkp@intel.com> Signed-off-by: Enrico Weigelt <info@metux.net> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
5923ea6c |
|
26-Apr-2019 |
Linus Walleij <linus.walleij@linaro.org> |
gpio: pass lookup and descriptor flags to request_own When a gpio_chip wants to request a descriptor from itself using gpiochip_request_own_desc() it needs to be able to specify fully how to use the descriptor, notably line inversion semantics. The workaround in the gpiolib.c can be removed and cases (such as SPI CS) where we need at times to request a GPIO with line inversion semantics directly on a chip for workarounds, can be fully supported with this call. Fix up some users of the API that weren't really using the last flag to set up the line as input or output properly but instead just calling direction setting explicitly after requesting the line. Cc: Martin Sperl <kernel@martin.sperl.org> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
27157af6 |
|
04-Apr-2019 |
Linus Walleij <linus.walleij@linaro.org> |
gpio: mmio: Drop bgpio_dir_inverted The direction inversion semantics are now handled by simply using the registers for in/out available, no need to keep track of inversion semantics exmplicitly anymore. Reviewed-by: Bartosz Golaszewski <bgolaszewski@baylibre.com> Reviewed-by: Jan Kotas <jank@cadence.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
f69e00bd |
|
22-Feb-2019 |
Linus Walleij <linus.walleij@linaro.org> |
gpio: mmio: Support two direction registers It turns out that one specific hardware has two direction registers: one to set a GPIO line as input and another one to set a GPIO line as output. So in theory a line can be configured as input and output at the same time. Make the MMIO GPIO helper deal with this: store both registers in the state container, use both in the generic code if present. Synchronize the input register to the output register when we register a GPIO chip, with the output settings taking precedence. Keep the helper variable to detect inverted direction semantics (only direction in register) but augment the code to be more straight-forward for the generic case when setting the registers. Fix some flunky with unreadable direction registers at the same time as we're touching this code. Cc: David Woods <dwoods@mellanox.com> Cc: Shravan Kumar Ramani <sramani@mellanox.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
64ebde5b |
|
07-Mar-2019 |
Jan Kundrát <jan.kundrat@cesnet.cz> |
gpiolib: export devprop_gpiochip_set_names() This function is needed in mcp23s08. That driver is a special snowflake because it supports several hardware chips as a single "GPIO chip" under Linux. Signed-off-by: Jan Kundrát <jan.kundrat@cesnet.cz> Cc: Linus Walleij <linus.walleij@linaro.org> Cc: Phil Reid <preid@electromag.com.au> Acked-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
ef74f70e |
|
19-Jan-2019 |
Brian Masney <masneyb@onstation.org> |
gpio: add irq domain activate/deactivate functions This adds the two new functions gpiochip_irq_domain_activate and gpiochip_irq_domain_deactivate that can be used as the activate and deactivate functions in the struct irq_domain_ops. This is for situations where only gpiochip_{lock,unlock}_as_irq needs to be called. SPMI and SSBI GPIO are two users that will initially use these functions. Signed-off-by: Brian Masney <masneyb@onstation.org> Suggested-by: Stephen Boyd <sboyd@kernel.org> Reviewed-by: Stephen Boyd <sboyd@kernel.org> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
21abf103 |
|
04-Sep-2018 |
Linus Walleij <linus.walleij@linaro.org> |
gpio: Pass a flag to gpiochip_request_own_desc() Before things go out of hand, make it possible to pass flags when requesting "own" descriptors from a gpio_chip. This is necessary if the chip wants to request a GPIO with active low semantics, for example. Cc: Janusz Krzysztofik <jmkrzyszt@gmail.com> Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Cc: Jason Cooper <jason@lakedaemon.net> Cc: Jiri Kosina <jkosina@suse.cz> Cc: Roger Quadros <rogerq@ti.com> Reviewed-by: Gregory CLEMENT <gregory.clement@free-electrons.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
eee3919c |
|
12-Nov-2018 |
Johan Hovold <johan@kernel.org> |
gpio: drop broken to_gpio_irq_chip() helper Drop the broken to_gpio_irq_chip() container_of() helper, which would break the build for anyone who tries to use it. Specifically, struct gpio_irq_chip only holds a pointer to a struct irq_chip so using container_of() on an irq-chip pointer makes no sense. Fixes: da80ff81a8f5 ("gpio: Move irqchip into struct gpio_irq_chip") Cc: Thierry Reding <treding@nvidia.com> Cc: Grygorii Strashko <grygorii.strashko@ti.com> Signed-off-by: Johan Hovold <johan@kernel.org> Reviewed-by: Bartosz Golaszewski <bgolaszewski@baylibre.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
48207d75 |
|
05-Oct-2018 |
Uwe Kleine-König <u.kleine-koenig@pengutronix.de> |
gpio: drop devm_gpiochip_remove() There is hardly any reason to call devm_gpiochip_remove() because the driver core handles calling gpiochip_remove() automatically. To make it harder to introduce new (and probably unneeded) callers, drop the function. Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
3e779a2e |
|
08-Oct-2018 |
Stephen Boyd <swboyd@chromium.org> |
gpio: Assign gpio_irq_chip::parents to non-stack pointer gpiochip_set_cascaded_irqchip() is passed 'parent_irq' as an argument and then the address of that argument is assigned to the gpio chips gpio_irq_chip 'parents' pointer shortly thereafter. This can't ever work, because we've just assigned some stack address to a pointer that we plan to dereference later in gpiochip_irq_map(). I ran into this issue with the KASAN report below when gpiochip_irq_map() tried to setup the parent irq with a total junk pointer for the 'parents' array. BUG: KASAN: stack-out-of-bounds in gpiochip_irq_map+0x228/0x248 Read of size 4 at addr ffffffc0dde472e0 by task swapper/0/1 CPU: 7 PID: 1 Comm: swapper/0 Not tainted 4.14.72 #34 Call trace: [<ffffff9008093638>] dump_backtrace+0x0/0x718 [<ffffff9008093da4>] show_stack+0x20/0x2c [<ffffff90096b9224>] __dump_stack+0x20/0x28 [<ffffff90096b91c8>] dump_stack+0x80/0xbc [<ffffff900845a350>] print_address_description+0x70/0x238 [<ffffff900845a8e4>] kasan_report+0x1cc/0x260 [<ffffff900845aa14>] __asan_report_load4_noabort+0x2c/0x38 [<ffffff900897e098>] gpiochip_irq_map+0x228/0x248 [<ffffff900820cc08>] irq_domain_associate+0x114/0x2ec [<ffffff900820d13c>] irq_create_mapping+0x120/0x234 [<ffffff900820da78>] irq_create_fwspec_mapping+0x4c8/0x88c [<ffffff900820e2d8>] irq_create_of_mapping+0x180/0x210 [<ffffff900917114c>] of_irq_get+0x138/0x198 [<ffffff9008dc70ac>] spi_drv_probe+0x94/0x178 [<ffffff9008ca5168>] driver_probe_device+0x51c/0x824 [<ffffff9008ca6538>] __device_attach_driver+0x148/0x20c [<ffffff9008ca14cc>] bus_for_each_drv+0x120/0x188 [<ffffff9008ca570c>] __device_attach+0x19c/0x2dc [<ffffff9008ca586c>] device_initial_probe+0x20/0x2c [<ffffff9008ca18bc>] bus_probe_device+0x80/0x154 [<ffffff9008c9b9b4>] device_add+0x9b8/0xbdc [<ffffff9008dc7640>] spi_add_device+0x1b8/0x380 [<ffffff9008dcbaf0>] spi_register_controller+0x111c/0x1378 [<ffffff9008dd6b10>] spi_geni_probe+0x4dc/0x6f8 [<ffffff9008cab058>] platform_drv_probe+0xdc/0x130 [<ffffff9008ca5168>] driver_probe_device+0x51c/0x824 [<ffffff9008ca59cc>] __driver_attach+0x100/0x194 [<ffffff9008ca0ea8>] bus_for_each_dev+0x104/0x16c [<ffffff9008ca58c0>] driver_attach+0x48/0x54 [<ffffff9008ca1edc>] bus_add_driver+0x274/0x498 [<ffffff9008ca8448>] driver_register+0x1ac/0x230 [<ffffff9008caaf6c>] __platform_driver_register+0xcc/0xdc [<ffffff9009c4b33c>] spi_geni_driver_init+0x1c/0x24 [<ffffff9008084cb8>] do_one_initcall+0x240/0x3dc [<ffffff9009c017d0>] kernel_init_freeable+0x378/0x468 [<ffffff90096e8240>] kernel_init+0x14/0x110 [<ffffff9008086fcc>] ret_from_fork+0x10/0x18 The buggy address belongs to the page: page:ffffffbf037791c0 count:0 mapcount:0 mapping: (null) index:0x0 flags: 0x4000000000000000() raw: 4000000000000000 0000000000000000 0000000000000000 00000000ffffffff raw: ffffffbf037791e0 ffffffbf037791e0 0000000000000000 0000000000000000 page dumped because: kasan: bad access detected Memory state around the buggy address: ffffffc0dde47180: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ffffffc0dde47200: f1 f1 f1 f1 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f2 f2 >ffffffc0dde47280: f2 f2 00 00 00 00 00 00 00 00 00 00 f3 f3 f3 f3 ^ ffffffc0dde47300: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ffffffc0dde47380: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 Let's leave around one unsigned int in the gpio_irq_chip struct for the single parent irq case and repoint the 'parents' array at it. This way code is left mostly intact to setup parents and we waste an extra few bytes per structure of which there should be only a handful in a system. Cc: Evan Green <evgreen@chromium.org> Cc: Thierry Reding <treding@nvidia.com> Cc: Grygorii Strashko <grygorii.strashko@ti.com> Fixes: e0d897289813 ("gpio: Implement tighter IRQ chip integration") Signed-off-by: Stephen Boyd <swboyd@chromium.org> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
f8ec92a9 |
|
05-Oct-2018 |
Ricardo Ribalda <ribalda@kernel.org> |
gpiolib: Add init_valid_mask exported function Add a function that allows initializing the valid_mask from gpiochip_add_data. This prevents race conditions during gpiochip initialization. If the function is not exported, then the old behaviour is respected, this is, set all gpios as valid. Signed-off-by: Ricardo Ribalda Delgado <ricardo.ribalda@gmail.com> Tested-by: Jeffrey Hugo <jhugo@codeaurora.org> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
e48d194d |
|
25-Sep-2018 |
Linus Walleij <linus.walleij@linaro.org> |
gpio: Add comments on single direction chips A patch from Ricardo got me thinking about some gpio chip semantics so let's drop in some comments to make things more clear around that. Cc: Ricardo Ribalda Delgado <ricardo.ribalda@gmail.com> Cc: Bartosz Golaszewski <brgl@bgdev.pl> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
461c1a7d |
|
08-Sep-2018 |
Hans Verkuil <hans.verkuil@cisco.com> |
gpiolib: override irq_enable/disable 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>
|
#
4e9439dd |
|
08-Sep-2018 |
Hans Verkuil <hans.verkuil@cisco.com> |
gpiolib: add flag to indicate if the irq is disabled 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>
|
#
4e6b8238 |
|
08-Sep-2018 |
Hans Verkuil <hans.verkuil@cisco.com> |
gpiolib: export gpiochip_irq_reqres/relres() GPIO drivers that do not use GPIOLIB_IRQCHIP can hook these into the irq_request_resource and irq_release_resource callbacks of the irq_chip so they correctly 'get' the module and lock the gpio line for IRQ use. This will simplify driver code. Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
02ad0437 |
|
03-Sep-2018 |
Randy Dunlap <rdunlap@infradead.org> |
gpio: fix kernel-doc notation warning for 'request_key' Fix kernel-doc warning for missing struct member 'request_key': ../include/linux/gpio/driver.h:142: warning: Function parameter or member 'request_key' not described in 'gpio_irq_chip' Fixes: 39c3fd58952d ("kernel/irq: Extend lockdep class for request mutex") Signed-off-by: Randy Dunlap <rdunlap@infradead.org> Cc: Andrew Lunn <andrew@lunn.ch> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Linus Walleij <linus.walleij@linaro.org> Cc: linux-gpio@vger.kernel.org Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
d799a4de |
|
02-Aug-2018 |
Linus Walleij <linus.walleij@linaro.org> |
gpio: mmio: Fix up inverted direction registers The bgpio_init() takes one of two arguments to specify a register to set the direction of the GPIO line: either dirout that indicates that a 1 in the bit in that register sets the corresponding line to output, or dirin which indicates that a 1 in the bit in that register sets the corresponding line to input. Conversely setting the bit to 0 on these will turn the line into input and output respectively. One of these can be defined but not both. This means that a platform that sets a bit to 1 for output only defines dirout and a platform that sets a bit to 0 for output only defines dirin. In short this defines the polarity of the direction register. Both can also be left as NULL meaning the GPIO chip is either input only or output only. Tomer Maimon discovered that for get/set chips (those where the get and set registers are defined but no separate clear register, and specifying BGPIOF_READ_OUTPUT_REG_SET so that we say we want to read the output value from the SET register) we are unconditionally reading the value from the SET register when the direction bit is 1 and from the DAT register when the direction bit is 0, not taking the direction bit polarity into account. It would be expected that when the direction bit is inverted (dirin is defined but not dirout) we read the current value from the DAT register when the bit is 1 and from the SET register when the bit is 0. Currently only some versions of ATH79, brcmstb, some versions of CLP711x, GE, IOP and Loongson use the dirin mode (a 1 in the register means input). They are unaffected because BGPIOF_READ_OUTPUT_REG_SET is not set on any of them. (They do not read back the SET register to figure out the output value.) So this is no regression with current drivers. However the behaviour is wrong and does not work with Tomer's new driver where he needs to use the BGIOF_READ_OUTPUT_REG_SET. This fixes the above issue by: - Instead of defining separate functions for the inverted case, set up a flag in the gpio_chip that indicates that the direction is inverted. - Remove the special inverted functions for setting input/output and getting the direction, rely on the flag instead. - Respect this flag in bgpio_get_set() and bgpio_get_set_multiple() Reported-by: Tomer Maimon <tmaimon77@gmail.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
726cb3ba |
|
23-Mar-2018 |
Stephen Boyd <sboyd@codeaurora.org> |
gpiolib: Support 'gpio-reserved-ranges' property Some qcom platforms make some GPIOs or pins unavailable for use by non-secure operating systems, and thus reading or writing the registers for those pins will cause access control issues. Add support for a DT property to describe the set of GPIOs that are available for use so that higher level OSes are able to know what pins to avoid reading/writing. Non-DT platforms can add support by directly updating the chip->valid_mask. Signed-off-by: Stephen Boyd <sboyd@codeaurora.org> Signed-off-by: Stephen Boyd <swboyd@chromium.org> Tested-by: Timur Tabi <timur@codeaurora.org> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
64ff2c8e |
|
09-Jan-2018 |
Stephen Boyd <sboyd@codeaurora.org> |
gpiolib: Export gpiochip_irqchip_irq_valid() to drivers Some pinctrl drivers can use the gpiochip irq valid information to figure out if certain gpios are exposed to the kernel for usage or not. Expose this API so we can use it in the pinmux_ops::request ops. Signed-off-by: Stephen Boyd <sboyd@codeaurora.org> Acked-by: Bjorn Andersson <bjorn.andersson@linaro.org> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
39c3fd58 |
|
02-Dec-2017 |
Andrew Lunn <andrew@lunn.ch> |
kernel/irq: Extend lockdep class for request mutex The IRQ code already has support for lockdep class for the lock mutex in an interrupt descriptor. Extend this to add a second class for the request mutex in the descriptor. Not having a class is resulting in false positive splats in some code paths. Signed-off-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Acked-by: linus.walleij@linaro.org Cc: grygorii.strashko@ti.com Cc: f.fainelli@gmail.com Link: https://lkml.kernel.org/r/1512234664-21555-1-git-send-email-andrew@lunn.ch
|
#
959bc7b2 |
|
07-Nov-2017 |
Thierry Reding <treding@nvidia.com> |
gpio: Automatically add lockdep keys In order to avoid lockdep boilerplate in individual drivers, turn the gpiochip_add_data() function into a macro that creates a unique class key for each driver. Note that this has the slight disadvantage of adding a key for each driver registered with the system. However, these keys are 8 bytes in size, which is negligible and a small price to pay for generic infrastructure. Suggested-by: Grygorii Strashko <grygorii.strashko@ti.com> Signed-off-by: Thierry Reding <treding@nvidia.com> Acked-by: Grygorii Strashko <grygorii.strashko@ti.com> [renane __gpiochip_add_data() to gpiochip_add_data_with_key] Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
8302cf58 |
|
07-Nov-2017 |
Thierry Reding <treding@nvidia.com> |
gpio: Introduce struct gpio_irq_chip.first Some GPIO chips cannot support sparse IRQ numbering and therefore need to manually allocate their interrupt descriptors statically. For these cases, a driver can pass the first allocated IRQ via the struct gpio_irq_chip's "first" field and thereby cause the IRQ domain to map all IRQs during initialization. Suggested-by: Grygorii Strashko <grygorii.strashko@ti.com> Signed-off-by: Thierry Reding <treding@nvidia.com> Acked-by: Grygorii Strashko <grygorii.strashko@ti.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
60ed54ca |
|
07-Nov-2017 |
Thierry Reding <treding@nvidia.com> |
gpio: Disambiguate struct gpio_irq_chip.nested The nested field in struct gpio_irq_chip currently has two meanings. On one hand it marks an IRQ chip as being nested (as opposed to chained), while on the other hand it also means that an IRQ chip uses nested thread handlers. However, nested IRQ chips can already be identified by the fact that they don't pass a parent handler (the driver would instead already have installed a nested handler using request_irq()). Therefore, the only use for the nested attribute is to inform gpiolib that an IRQ chip uses nested thread handlers (as opposed to regular, non-threaded handlers). To clarify its purpose, rename the field to "threaded". Signed-off-by: Thierry Reding <treding@nvidia.com> Acked-by: Grygorii Strashko <grygorii.strashko@ti.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
1b95b4eb |
|
07-Nov-2017 |
Thierry Reding <treding@nvidia.com> |
gpio: Export gpiochip_irq_{map,unmap}() Export these functions so that drivers can explicitly use these when setting up their IRQ domain. Signed-off-by: Thierry Reding <treding@nvidia.com> Acked-by: Grygorii Strashko <grygorii.strashko@ti.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
e0d89728 |
|
07-Nov-2017 |
Thierry Reding <treding@nvidia.com> |
gpio: Implement tighter IRQ chip integration Currently GPIO drivers are required to add the GPIO chip and its corresponding IRQ chip separately, which can result in a lot of boilerplate. Use the newly introduced struct gpio_irq_chip, embedded in struct gpio_chip, that drivers can fill in if they want the GPIO core to automatically register the IRQ chip associated with a GPIO chip. Signed-off-by: Thierry Reding <treding@nvidia.com> Acked-by: Grygorii Strashko <grygorii.strashko@ti.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
ca9df053 |
|
07-Nov-2017 |
Thierry Reding <treding@nvidia.com> |
gpio: Move lock_key into struct gpio_irq_chip In order to consolidate the multiple ways to associate an IRQ chip with a GPIO chip, move more fields into the new struct gpio_irq_chip. Signed-off-by: Thierry Reding <treding@nvidia.com> Acked-by: Grygorii Strashko <grygorii.strashko@ti.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
dc7b0387 |
|
07-Nov-2017 |
Thierry Reding <treding@nvidia.com> |
gpio: Move irq_valid_mask into struct gpio_irq_chip In order to consolidate the multiple ways to associate an IRQ chip with a GPIO chip, move more fields into the new struct gpio_irq_chip. Signed-off-by: Thierry Reding <treding@nvidia.com> Acked-by: Grygorii Strashko <grygorii.strashko@ti.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
dc6bafee |
|
07-Nov-2017 |
Thierry Reding <treding@nvidia.com> |
gpio: Move irq_nested into struct gpio_irq_chip In order to consolidate the multiple ways to associate an IRQ chip with a GPIO chip, move more fields into the new struct gpio_irq_chip. Signed-off-by: Thierry Reding <treding@nvidia.com> Acked-by: Grygorii Strashko <grygorii.strashko@ti.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
39e5f096 |
|
07-Nov-2017 |
Thierry Reding <treding@nvidia.com> |
gpio: Move irq_chained_parent to struct gpio_irq_chip In order to consolidate the multiple ways to associate an IRQ chip with a GPIO chip, move more fields into the new struct gpio_irq_chip. Signed-off-by: Thierry Reding <treding@nvidia.com> Acked-by: Grygorii Strashko <grygorii.strashko@ti.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
3634eeb0 |
|
07-Nov-2017 |
Thierry Reding <treding@nvidia.com> |
gpio: Move irq_default_type to struct gpio_irq_chip In order to consolidate the multiple ways to associate an IRQ chip with a GPIO chip, move more fields into the new struct gpio_irq_chip. Signed-off-by: Thierry Reding <treding@nvidia.com> Acked-by: Grygorii Strashko <grygorii.strashko@ti.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
c7a0aa59 |
|
07-Nov-2017 |
Thierry Reding <treding@nvidia.com> |
gpio: Move irq_handler to struct gpio_irq_chip In order to consolidate the multiple ways to associate an IRQ chip with a GPIO chip, move more fields into the new struct gpio_irq_chip. Signed-off-by: Thierry Reding <treding@nvidia.com> Acked-by: Grygorii Strashko <grygorii.strashko@ti.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
f0fbe7bc |
|
07-Nov-2017 |
Thierry Reding <treding@nvidia.com> |
gpio: Move irqdomain into struct gpio_irq_chip In order to consolidate the multiple ways to associate an IRQ chip with a GPIO chip, move more fields into the new struct gpio_irq_chip. Signed-off-by: Thierry Reding <treding@nvidia.com> Acked-by: Grygorii Strashko <grygorii.strashko@ti.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
da80ff81 |
|
07-Nov-2017 |
Thierry Reding <treding@nvidia.com> |
gpio: Move irqchip into struct gpio_irq_chip In order to consolidate the multiple ways to associate an IRQ chip with a GPIO chip, move more fields into the new struct gpio_irq_chip. Signed-off-by: Thierry Reding <treding@nvidia.com> Acked-by: Grygorii Strashko <grygorii.strashko@ti.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
c44eafd7 |
|
07-Nov-2017 |
Thierry Reding <treding@nvidia.com> |
gpio: Introduce struct gpio_irq_chip This new structure will be used to group all fields related to interrupt handling in a GPIO chip. Doing so will properly namespace these fields and make it easier to distinguish which fields are used for IRQ support. Signed-off-by: Thierry Reding <treding@nvidia.com> Acked-by: Grygorii Strashko <grygorii.strashko@ti.com> 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>
|
#
24efd94b |
|
20-Oct-2017 |
Linus Walleij <linus.walleij@linaro.org> |
gpio: mmio: Make pin2mask() a private business The vtable call pin2mask() was introducing a vtable function call in every gpiochip callback for a generic MMIO GPIO chip. This was not exactly efficient. (Maybe link-time optimization could get rid of it, I don't know.) After removing all external calls into this API we can make it a boolean flag in the struct gpio_chip call and sink the function into the gpio-mmio driver yielding encapsulation and potential speedups. Cc: Anton Vorontsov <anton@enomsg.org> 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>
|
#
f628ba9e |
|
09-Oct-2017 |
Grygorii Strashko <grygorii.strashko@ti.com> |
gpiolib: drop irq_base field from gpio_chip struct Hence, the last user of irq_base field was removed by commit b4c495f03ae3 ("gpio: mockup: use irq_sim") it can be removed safely. Signed-off-by: Grygorii Strashko <grygorii.strashko@ti.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
e3b445d7 |
|
24-Jul-2017 |
Thierry Reding <treding@nvidia.com> |
gpio: Use unsigned int for of_gpio_n_cells The cell count for GPIO specifiers can never be negative, so make the field unsigned. Signed-off-by: Thierry Reding <treding@nvidia.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
67049c50 |
|
24-Jul-2017 |
Thierry Reding <treding@nvidia.com> |
gpio: of: Improve kerneldoc Add descriptions for missing fields and fix up some parameter references to match the code. Signed-off-by: Thierry Reding <treding@nvidia.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
950d55f5 |
|
24-Jul-2017 |
Thierry Reding <treding@nvidia.com> |
gpio: Cleanup kerneldoc Some kerneldoc has become stale or wasn't quite correct from the outset. Fix up the most serious issues to silence warnings when building the documentation. Signed-off-by: Thierry Reding <treding@nvidia.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
05f479bf |
|
23-May-2017 |
Charles Keepax <ckeepax@opensource.wolfsonmicro.com> |
gpio: Add new flags to control sleep status of GPIOs Add new flags to allow users to specify that they are not concerned with the status of GPIOs whilst in a sleep/low power state. Signed-off-by: Charles Keepax <ckeepax@opensource.wolfsonmicro.com> Acked-by: Rob Herring <robh@kernel.org> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
6f79309a |
|
03-Apr-2017 |
Thierry Reding <treding@nvidia.com> |
gpio: Use unsigned int for interrupt numbers Interrupt numbers are never negative, zero serves as the special invalid value. Signed-off-by: Thierry Reding <treding@nvidia.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
2956b5d9 |
|
23-Jan-2017 |
Mika Westerberg <mika.westerberg@linux.intel.com> |
pinctrl / gpio: Introduce .set_config() callback for GPIO chips Currently we already have two pin configuration related callbacks available for GPIO chips .set_single_ended() and .set_debounce(). In future we expect to have even more, which does not scale well if we need to add yet another callback to the GPIO chip structure for each possible configuration parameter. Better solution is to reuse what we already have available in the generic pinconf. To support this, we introduce a new .set_config() callback for GPIO chips. The callback takes a single packed pin configuration value as parameter. This can then be extended easily beyond what is currently supported by just adding new types to the generic pinconf enum. If the GPIO driver is backed up by a pinctrl driver the GPIO driver can just assign gpiochip_generic_config() (introduced in this patch) to .set_config and that will take care configuration requests are directed to the pinctrl driver. We then convert the existing drivers over .set_config() and finally remove the .set_single_ended() and .set_debounce() callbacks. Suggested-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
739e6f59 |
|
11-Jan-2017 |
Linus Walleij <linus.walleij@linaro.org> |
gpio: provide lockdep keys for nested/unnested irqchips The helper function for adding a GPIO chip compiles in a lockdep key for debugging, the same key is needed for nested chips as well. The macro construction is unreadable, replace this with two static inlines instead. The _gpiochip_irqchip_add prefixed function is not helpful, rename it with gpiochip_irqchip_add_key() that tell us what the function is actually doing. Fixes: d245b3f9bd36 ("gpio: simplify adding threaded interrupts") Cc: Roger Quadros <rogerq@ti.com> Reported-by: Clemens Gruber <clemens.gruber@pqgruber.com> Reported-by: Roger Quadros <rogerq@ti.com> Reported-by: Grygorii Strashko <grygorii.strashko@ti.com> Tested-by: Clemens Gruber <clemens.gruber@pqgruber.com> Tested-by: Grygorii Strashko <grygorii.strashko@ti.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
d245b3f9 |
|
24-Nov-2016 |
Linus Walleij <linus.walleij@linaro.org> |
gpio: simplify adding threaded interrupts This tries to simplify the use of CONFIG_GPIOLIB_IRQCHIP when using threaded interrupts: add a new call gpiochip_irqchip_add_nested() to indicate that we're dealing with a nested rather than a chained irqchip, then create a separate gpiochip_set_nested_irqchip() to mirror the gpiochip_set_chained_irqchip() call to connect the parent and child interrupts. In the nested case gpiochip_set_nested_irqchip() does nothing more than call irq_set_parent() on each valid child interrupt, which has little semantic effect in the kernel, but this is probably still formally correct. Update all drivers using nested interrupts to use gpiochip_irqchip_add_nested() so we can now see clearly which these users are. The DLN2 driver can drop its specific hack with .irq_not_threaded as we now recognize whether a chip is threaded or not from its use of gpiochip_irqchip_add_nested() signature rather than from inspecting .can_sleep. We rename the .irq_parent to .irq_chained_parent since this parent IRQ is only really kept around for the chained interrupt handlers. Cc: Lars Poeschel <poeschel@lemonage.de> Cc: Octavian Purdila <octavian.purdila@intel.com> Cc: Daniel Baluta <daniel.baluta@intel.com> Cc: Bin Gao <bin.gao@linux.intel.com> Cc: Mika Westerberg <mika.westerberg@linux.intel.com> Cc: Ajay Thomas <ajay.thomas.david.rajamanickam@intel.com> Cc: Semen Protsenko <semen.protsenko@globallogic.com> Cc: Alexander Stein <alexander.stein@systec-electronic.com> Cc: Phil Reid <preid@electromag.com.au> Cc: Bartosz Golaszewski <bgolaszewski@baylibre.com> Cc: Patrice Chotard <patrice.chotard@st.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
08bcd3ed |
|
04-Oct-2016 |
Anthony Best <anthonybest@bestanthony.com> |
gpio: fix struct gpio_chip comment It should have been @reg_clr instead of @reg_clk Signed-off-by: Anthony Best <anthonybest@bestanthony.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
97139d4a |
|
11-Oct-2016 |
Masahiro Yamada <yamada.masahiro@socionext.com> |
treewide: remove redundant #include <linux/kconfig.h> Kernel source files need not include <linux/kconfig.h> explicitly because the top Makefile forces to include it with: -include $(srctree)/include/linux/kconfig.h This commit removes explicit includes except the following: * arch/s390/include/asm/facilities_src.h * tools/testing/radix-tree/linux/kernel.h These two are used for host programs. Link: http://lkml.kernel.org/r/1473656164-11929-1-git-send-email-yamada.masahiro@socionext.com Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
|
#
79b804cb |
|
20-Sep-2016 |
Mika Westerberg <mika.westerberg@linux.intel.com> |
gpiolib: Make it possible to exclude GPIOs from IRQ domain When using GPIO irqchip helpers to setup irqchip for a gpiolib based driver, it is not possible to select which GPIOs to add to the IRQ domain. Instead it just adds all GPIOs which is not always desired. For example there might be GPIOs that for some reason cannot generated normal interrupts at all. To support this we add a flag irq_need_valid_mask to struct gpio_chip. When this flag is set the core allocates irq_valid_mask that holds one bit for each GPIO the chip has. By default all bits are set but drivers can manipulate this using set_bit() and clear_bit() accordingly. Then when gpiochip_irqchip_add() is called, this mask is checked and all GPIOs with bit is set are added to the IRQ domain created for the GPIO chip. Suggested-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
d47529b2 |
|
12-Sep-2016 |
Paul Gortmaker <paul.gortmaker@windriver.com> |
gpio: don't include module.h in shared driver header Most shared headers in include/linux don't need to know what the internals of a struct module are; all they care about is that it is a struct and hence they may require a pointer to one. The advantage in this is that module.h is including a lot of stuff itself, and an otherwise empty C file that just contains module.h will result in ~750kB from CPP (compared to say 12kB from init.h) So we have approximately 50 instances of "struct module;" in the various include/linux headers already that help us keep module.h out of other headers; here we do the same for gpio. Cc: Linus Walleij <linus.walleij@linaro.org> Cc: Alexandre Courbot <gnurou@gmail.com> Cc: linux-gpio@vger.kernel.org Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
c663e5f5 |
|
22-Mar-2016 |
Linus Walleij <linus.walleij@linaro.org> |
gpio: support native single-ended hardware drivers Some GPIO controllers has a special hardware bit we can flip to support open drain / source. This means that on these hardwares we do not need to emulate OD/OS by setting the line to input instead of actively driving it high/low. Add an optional vtable callback to the driver set_single_ended() so that driver can implement this in hardware if they have it. We may need a pinctrl_gpio_set_config() call at some point to propagate this down to a backing pin control device on systems with split GPIO/pin control. Reported-by: Michael Hennerich <michael.hennerich@analog.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
0cf3292c |
|
15-Feb-2016 |
Laxman Dewangan <ldewangan@nvidia.com> |
gpio: Add devm_ apis for gpiochip_add_data and gpiochip_remove Add device managed APIs devm_gpiochip_add_data() and devm_gpiochip_remove() for the APIs gpiochip_add_data() and gpiochip_remove(). This helps in reducing code in error path and sometimes removal of .remove callback for driver unbind. Signed-off-by: Laxman Dewangan <ldewangan@nvidia.com>
|
#
df4878e9 |
|
12-Feb-2016 |
Linus Walleij <linus.walleij@linaro.org> |
gpio: store reflect the label to userspace The gpio_chip label is useful for userspace to understand what kind of GPIO chip it is dealing with. Let's store a copy of this label in the gpio_device, add it to the struct passed to userspace for GPIO_GET_CHIPINFO_IOCTL and modify lsgpio to show it. Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
143b65d6 |
|
16-Feb-2016 |
Linus Walleij <linus.walleij@linaro.org> |
gpio: create an API to detect open drain/source on lines My left hand merges code to privatize the descriptor handling while my right hand merges drivers that poke around and disrespect with the same gpiolib internals. So let's expose the proper APIs for drivers to ask the gpiolib core if a line is marked as open drain or open source and get some order around things so this driver compiles again. Reported-by: Stephen Rothwell <sfr@canb.auug.org.au> Cc: Nicolas Saenz Julienne <nicolassaenzj@gmail.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
43c54eca |
|
11-Feb-2016 |
Linus Walleij <linus.walleij@linaro.org> |
gpio: move the subdriver data pointer into gpio_device We move to manage this pointer under gpiolib control rather than leave it in the subdevice's gpio_chip. We can not NULL it after gpiochip_remove so at to keep things tight. Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
20ec3e39 |
|
11-Feb-2016 |
Linus Walleij <linus.walleij@linaro.org> |
gpio: move the pin ranges into gpio_device Instead of keeping this reference to the pin ranges in the client driver-supplied gpio_chip, move it to the internal gpio_device as the drivers have no need to inspect this. Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
6cee3821 |
|
11-Feb-2016 |
Linus Walleij <linus.walleij@linaro.org> |
gpio/pinctrl: sunxi: stop poking around in private vars This kind of hacks disturbs the refactoring of the gpiolib. The descriptor table belongs to the gpiolib, if we want to know something about something in it, use or define the proper accessor functions. Let's add this gpiochip_lins_is_irq() to do what the sunxi driver is trying at so we can privatize the descriptors properly. Cc: Maxime Ripard <maxime.ripard@free-electrons.com> Cc: Chen-Yu Tsai <wens@csie.org> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
1c3cdb18 |
|
09-Feb-2016 |
Linus Walleij <linus.walleij@linaro.org> |
gpio: move descriptors into gpio_device We need gpio_device to hold the descriptors so that they can be lifecycled with the struct gpio_device held from userspace. Move the descriptor array into gpio_device. Also rename it from "desc" (singularis) to "descs" (pluralis) to reflect the fact that it is an array. Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
afbc4f31 |
|
09-Feb-2016 |
Linus Walleij <linus.walleij@linaro.org> |
gpio: move sysfs mock device to the gpio_device Since gpio_device is the struct that survives if the backing gpio_chip is removed, move the sysfs mock device to this state container so it becomes part of the dangling state of the GPIO device on removal. Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
ff2b1359 |
|
20-Oct-2015 |
Linus Walleij <linus.walleij@linaro.org> |
gpio: make the gpiochip a real device GPIO chips have been around for years, but were never real devices, instead they were piggy-backing on a parent device (such as a platform_device or amba_device) but this was always optional. GPIO chips could also exist without any device at all, with its struct device *parent (ex *dev) pointer being set to null. When sysfs was in use, a mock device would be created, with the optional parent assigned, or just floating orphaned with NULL as parent. If sysfs is active, it will use this device as parent. We now create a gpio_device struct containing a real struct device and move the subsystem over to using that. The list of struct gpio_chip:s is augmented to hold struct gpio_device:s and we find gpio_chips:s by first looking up the struct gpio_device. The struct gpio_device is designed to stay around even if the gpio_chip is removed, so as to satisfy users in userspace that need a backing data structure to hold the state of the session initiated with e.g. a character device even if there is no physical chip anymore. From this point on, gpiochips are devices. Cc: Johan Hovold <johan@kernel.org> Cc: Michael Welling <mwelling@ieee.org> Cc: Markus Pargmann <mpa@pengutronix.de> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
c474e348 |
|
09-Jan-2016 |
Arnd Bergmann <arnd@arndb.de> |
gpio: generic: make bgpio_pdata always visible Board files that define their own bgpio_pdata are broken when CONFIG_GPIO_GENERIC is disabled and the bgpio_pdata structure definition is hidden by the #ifdef: arch/arm/mach-clps711x/board-autcpu12.c:148:15: error: variable 'autcpu12_mmgpio_pdata' has initializer but incomplete type static struct bgpio_pdata autcpu12_mmgpio_pdata __initdata = { arch/arm/mach-clps711x/board-autcpu12.c:149:2: error: unknown field 'base' specified in initializer .base = AUTCPU12_MMGPIO_BASE, Since the board files should generally not care what drivers are enabled, this makes the structure definition visible again. Signed-off-by: Arnd Bergmann <arnd@arndb.de> Fixes: 0f4630f3720e ("gpio: generic: factor into gpio_chip struct") Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
0f4630f3 |
|
04-Dec-2015 |
Linus Walleij <linus.walleij@linaro.org> |
gpio: generic: factor into gpio_chip struct The separate struct bgpio_chip has been a pain to handle, both by being confusingly similar in name to struct gpio_chip and for being contained inside a struct so that struct gpio_chip is contained in a struct contained in a struct, making several steps of dereferencing necessary. Make things simpler: include the fields directly into <linux/gpio/driver.h>, #ifdef:ed for CONFIG_GENERIC_GPIO, and get rid of the <linux/basic_mmio_gpio.h> altogether. Prefix some of the member variables with bgpio_* and add proper kerneldoc while we're at it. Modify all users to handle the change and use a struct gpio_chip directly. And while we're at it: replace all container_of() dereferencing by gpiochip_get_data() and registering the gpio_chip with gpiochip_add_data(). Cc: arm@kernel.org Cc: Alexander Shiyan <shc_work@mail.ru> Cc: Shawn Guo <shawnguo@kernel.org> Cc: Sascha Hauer <kernel@pengutronix.de> Cc: Kukjin Kim <kgene@kernel.org> Cc: Alexandre Courbot <gnurou@gmail.com> Cc: Brian Norris <computersforpeace@gmail.com> Cc: Florian Fainelli <f.fainelli@gmail.com> Cc: Sudeep Holla <sudeep.holla@arm.com> Cc: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Cc: Nicolas Pitre <nicolas.pitre@linaro.org> Cc: Olof Johansson <olof@lixom.net> Cc: Vladimir Zapolskiy <vladimir_zapolskiy@mentor.com> Cc: Rabin Vincent <rabin@rab.in> Cc: linux-arm-kernel@lists.infradead.org Cc: linux-omap@vger.kernel.org Cc: linux-samsung-soc@vger.kernel.org Cc: bcm-kernel-feedback-list@broadcom.com Acked-by: Gregory Fong <gregory.0xf0@gmail.com> Acked-by: Liviu Dudau <Liviu.Dudau@arm.com> Acked-by: H Hartley Sweeten <hsweeten@visionengravers.com> Acked-by: Tony Lindgren <tony@atomide.com> Acked-by: Krzysztof Kozlowski <k.kozlowski@samsung.com> Acked-by: Lee Jones <lee.jones@linaro.org> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
b08ea35a |
|
03-Dec-2015 |
Linus Walleij <linus.walleij@linaro.org> |
gpio: add a data pointer to gpio_chip This adds a void * pointer to gpio_chip so that driver can assign and retrieve some states. This is done to get rid of container_of() calls for gpio_chips embedded inside state containers, so we can remove the need to have the gpio_chip or later (planned) struct gpio_device be dynamically allocated at registration time, so that its struct device can be properly reference counted and not bound to its parent device (e.g. a platform_device) but instead live on after unregistration if it is opened by e.g. a char device or sysfs. The data is added with the new function gpiochip_add_data() and for compatibility we add static inline wrapper function gpiochip_add() that will call gpiochip_add_data() with NULL as argument. The latter will be removed once we have exorcised gpiochip_add() from the kernel. gpiochip_get_data() is added as a static inline accessor for drivers to quickly get their data out. Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
60befd2e |
|
22-Dec-2015 |
Vladimir Zapolskiy <vladimir_zapolskiy@mentor.com> |
gpio: update gpiochip .get() callback description Since gpiochip .get() callback may return a negative error value, it strictly limits the range of possible non-error returned values to a subset of [30:0] bitmask, however on practice on success all gpiochip drivers return either 0 for low signal or 1 for high signal, this is assured by "gpio: *: Be sure to clamp return value" series of changes. To avoid any confusion, misinterpretation and potential errors while developing gpiochip drivers in future convert this implicit assumption to a mandatory rule. For output signals with unknown output signal state gpiochip drivers should return a negative error instead of 0. Signed-off-by: Vladimir Zapolskiy <vladimir_zapolskiy@mentor.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
58383c78 |
|
04-Nov-2015 |
Linus Walleij <linus.walleij@linaro.org> |
gpio: change member .dev to .parent The name .dev in a struct is normally reserved for a struct device that is let us say a superclass to the thing described by the struct. struct gpio_chip stands out by confusingly using a struct device *dev to point to the parent device (such as a platform_device) that represents the hardware. As we want to give gpio_chip:s real devices, this is not working. We need to rename this member to parent. This was done by two coccinelle scripts, I guess it is possible to combine them into one, but I don't know such stuff. They look like this: @@ struct gpio_chip *var; @@ -var->dev +var->parent and: @@ struct gpio_chip var; @@ -var.dev +var.parent and: @@ struct bgpio_chip *var; @@ -var->gc.dev +var->gc.parent Plus a few instances of bgpio that I couldn't figure out how to teach Coccinelle to rewrite. This patch hits all over the place, but I *strongly* prefer this solution to any piecemal approaches that just exercise patch mechanics all over the place. It mainly hits drivers/gpio and drivers/pinctrl which is my own backyard anyway. Cc: Haavard Skinnemoen <hskinnemoen@gmail.com> Cc: Rafał Miłecki <zajec5@gmail.com> Cc: Richard Purdie <rpurdie@rpsys.net> Cc: Mauro Carvalho Chehab <mchehab@osg.samsung.com> Cc: Alek Du <alek.du@intel.com> Cc: Jaroslav Kysela <perex@perex.cz> Cc: Takashi Iwai <tiwai@suse.com> Acked-by: Dmitry Torokhov <dmitry.torokhov@gmail.com> Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Acked-by: Lee Jones <lee.jones@linaro.org> Acked-by: Jiri Kosina <jkosina@suse.cz> Acked-by: Hans-Christian Egtvedt <egtvedt@samfundet.no> Acked-by: Jacek Anaszewski <j.anaszewski@samsung.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
c771c2f4 |
|
11-Oct-2015 |
Jonas Gorski <jogo@openwrt.org> |
gpiolib: provide generic request/free implementations Provide generic request/free implementations that pinctrl aware gpio drivers can use instead of open coding if they use a 1:1 pin to gpio signal mapping. Signed-off-by: Jonas Gorski <jogo@openwrt.org> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
41d6bb4c |
|
17-Aug-2015 |
Grygorii Strashko <grygorii.strashko@ti.com> |
gpiolib: add description for gpio irqchip fields in struct gpio_chip Add missed description for GPIO irqchip fields in struct gpio_chip. Signed-off-by: Grygorii Strashko <grygorii.strashko@ti.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
a0a8bcf4 |
|
17-Aug-2015 |
Grygorii Strashko <grygorii.strashko@ti.com> |
gpiolib: irqchip: use different lockdep class for each gpio irqchip Since IRQ chip helpers were introduced drivers lose ability to register separate lockdep classes for each registered GPIO IRQ chip and the gpiolib now is using shared lockdep class for all GPIO IRQ chips (gpiochip_irq_lock_class). As result, lockdep will produce warning when there are min two stacked GPIO chips and all of them are interrupt controllers. HW configuration which generates lockdep warning (TI dra7-evm): [SOC GPIO bankA.gpioX] <- irq - [pcf875x.gpioY] <- irq - DevZ.enable_irq_wake(pcf_gpioY_irq); The issue was reported in [1] and discussed [2]. ============================================= [ INFO: possible recursive locking detected ] 4.2.0-rc6-00013-g5d050ed-dirty #55 Not tainted --------------------------------------------- sh/63 is trying to acquire lock: (class){......}, at: [<c009b91c>] __irq_get_desc_lock+0x50/0x94 but task is already holding lock: (class){......}, at: [<c009b91c>] __irq_get_desc_lock+0x50/0x94 other info that might help us debug this: Possible unsafe locking scenario: CPU0 ---- lock(class); lock(class); *** DEADLOCK *** May be due to missing lock nesting notation 7 locks held by sh/63: #0: (sb_writers#4){.+.+.+}, at: [<c016bbb8>] vfs_write+0x13c/0x164 #1: (&of->mutex){+.+.+.}, at: [<c01debf4>] kernfs_fop_write+0x4c/0x1a0 #2: (s_active#36){.+.+.+}, at: [<c01debfc>] kernfs_fop_write+0x54/0x1a0 #3: (pm_mutex){+.+.+.}, at: [<c009758c>] pm_suspend+0xec/0x4c4 #4: (&dev->mutex){......}, at: [<c03f77f8>] __device_suspend+0xd4/0x398 #5: (&gpio->lock){+.+.+.}, at: [<c009b940>] __irq_get_desc_lock+0x74/0x94 #6: (class){......}, at: [<c009b91c>] __irq_get_desc_lock+0x50/0x94 stack backtrace: CPU: 0 PID: 63 Comm: sh Not tainted 4.2.0-rc6-00013-g5d050ed-dirty #55 Hardware name: Generic DRA74X (Flattened Device Tree) [<c0016e24>] (unwind_backtrace) from [<c0013338>] (show_stack+0x10/0x14) [<c0013338>] (show_stack) from [<c05f6b24>] (dump_stack+0x84/0x9c) [<c05f6b24>] (dump_stack) from [<c00903f4>] (__lock_acquire+0x19c0/0x1e20) [<c00903f4>] (__lock_acquire) from [<c0091098>] (lock_acquire+0xa8/0x128) [<c0091098>] (lock_acquire) from [<c05fd61c>] (_raw_spin_lock_irqsave+0x38/0x4c) [<c05fd61c>] (_raw_spin_lock_irqsave) from [<c009b91c>] (__irq_get_desc_lock+0x50/0x94) [<c009b91c>] (__irq_get_desc_lock) from [<c009c4f4>] (irq_set_irq_wake+0x20/0xfc) [<c009c4f4>] (irq_set_irq_wake) from [<c0393ac4>] (pcf857x_irq_set_wake+0x24/0x54) [<c0393ac4>] (pcf857x_irq_set_wake) from [<c009c560>] (irq_set_irq_wake+0x8c/0xfc) [<c009c560>] (irq_set_irq_wake) from [<c04a02ac>] (gpio_keys_suspend+0x70/0xd4) [<c04a02ac>] (gpio_keys_suspend) from [<c03f6a00>] (dpm_run_callback+0x50/0x124) [<c03f6a00>] (dpm_run_callback) from [<c03f7830>] (__device_suspend+0x10c/0x398) [<c03f7830>] (__device_suspend) from [<c03f90f0>] (dpm_suspend+0x134/0x2f4) [<c03f90f0>] (dpm_suspend) from [<c0096e20>] (suspend_devices_and_enter+0xa8/0x728) [<c0096e20>] (suspend_devices_and_enter) from [<c00977cc>] (pm_suspend+0x32c/0x4c4) [<c00977cc>] (pm_suspend) from [<c0096060>] (state_store+0x64/0xb8) [<c0096060>] (state_store) from [<c01dec64>] (kernfs_fop_write+0xbc/0x1a0) [<c01dec64>] (kernfs_fop_write) from [<c016b280>] (__vfs_write+0x20/0xd8) [<c016b280>] (__vfs_write) from [<c016bb0c>] (vfs_write+0x90/0x164) [<c016bb0c>] (vfs_write) from [<c016c330>] (SyS_write+0x44/0x9c) [<c016c330>] (SyS_write) from [<c000f500>] (ret_fast_syscall+0x0/0x54) Lets fix it by using separate lockdep class for each registered GPIO IRQ Chip. This is done by wrapping gpiochip_irqchip_add call into macros. The implementation of this patch inspired by solution done by Nicolas Boichat for regmap [3] [1] http://www.spinics.net/lists/linux-gpio/msg05844.html [2] http://www.spinics.net/lists/linux-gpio/msg06021.html [3] http://www.spinics.net/lists/arm-kernel/msg429834.html Cc: Geert Uytterhoeven <geert@linux-m68k.org> Cc: Roger Quadros <rogerq@ti.com> Reported-by: Roger Quadros <rogerq@ti.com> Tested-by: Roger Quadros <rogerq@ti.com> Signed-off-by: Grygorii Strashko <grygorii.strashko@ti.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
30bb6fb3 |
|
15-Jun-2015 |
Geert Uytterhoeven <geert+renesas@glider.be> |
gpio: Remove double "base" in comment Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
af6c235d |
|
13-May-2015 |
Linus Walleij <linus.walleij@linaro.org> |
gpio: discourage passing base to gpio_chip Passing a fixed base in struct gpio_chip is done for legacy systems that cannot handle dynamic allocation. Discourage this behaviour in the kerneldoc. Acked-by: Alexandre Courbot <acourbot@nvidia.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
25e4fe92 |
|
12-May-2015 |
Dmitry Baryshkov <dbaryshkov@gmail.com> |
gpiolib: cleanup chained handler and data Clean up chained handler and handler data if they were set by gpiochip_set_chained_irqchip(). Signed-off-by: Dmitry Eremin-Solenikov <dbaryshkov@gmail.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
6a4b6b0a |
|
04-May-2015 |
Johan Hovold <johan@kernel.org> |
gpio: sysfs: clean up chip class-device handling Clean gpio-chip class device registration and deregistration. The class device is registered when a gpio-chip is added (or from gpiolib_sysfs_init post-core init call), and deregistered when the chip is removed. Store the class device in struct gpio_chip directly rather than do a class-device lookup on deregistration. This also removes the need for the exported flag. Signed-off-by: Johan Hovold <johan@kernel.org> Reviewed-by: Alexandre Courbot <acourbot@nvidia.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
964cb341 |
|
17-Mar-2015 |
Linus Walleij <linus.walleij@linaro.org> |
gpio: move pincontrol calls to <linux/gpio/driver.h> These functions do not belong in <asm-generic/gpio.h> since the split into separate GPIO headers under <linux/gpio/*>. Move them to <linux/gpio/driver.h> as is apropriate. Acked-by: Alexandre Courbot <acourbot@nvidia.com> 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>
|
#
e3a2e878 |
|
23-Oct-2014 |
Alexandre Courbot <acourbot@nvidia.com> |
gpio: rename gpio_lock_as_irq to gpiochip_lock_as_irq This function actually operates on a gpio_chip, so its prefix should reflect that fact for consistency with other functions defined in gpio/driver.h. Signed-off-by: Alexandre Courbot <acourbot@nvidia.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
295494af |
|
19-Sep-2014 |
Octavian Purdila <octavian.purdila@intel.com> |
gpiolib: add irq_not_threaded flag to gpio_chip Some GPIO chips (e.g. the DLN2 USB adapter) have blocking get/set operation but do not need a threaded irq handler. Signed-off-by: Octavian Purdila <octavian.purdila@intel.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
e1db1706 |
|
05-Jul-2014 |
abdoulaye berthe <berthe.ab@gmail.com> |
gpio: gpiolib: set gpiochip_remove retval to void This avoids handling gpiochip remove error in device remove handler. Signed-off-by: Abdoulaye Berthe <berthe.ab@gmail.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
7d75a871 |
|
05-Sep-2014 |
Paul Bolle <pebolle@tiscali.nl> |
gpio: fix 'CONFIG_GPIO_IRQCHIP' comments These two typos were introduced in commit 1425052097b5 ("gpio: add IRQ chip helpers in gpiolib"). The correct symbol name is CONFIG_GPIOLIB_IRQCHIP. [jkosina@suse.cz: add changelog] Signed-off-by: Paul Bolle <pebolle@tiscali.nl> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
|
#
abdc08a3 |
|
19-Aug-2014 |
Alexandre Courbot <acourbot@nvidia.com> |
gpio: change gpiochip_request_own_desc() prototype The current prototype of gpiochip_request_own_desc() requires to obtain a pointer to a descriptor. This is in contradiction to all other GPIO request schemes, and imposes an extra step of obtaining a descriptor to drivers. Most drivers actually cannot even perform that step since the function that does it (gpichip_get_desc()) is gpiolib-private. Change gpiochip_request_own_desc() to return a descriptor from a (chip, hwnum) tuple and update users of this function (currently gpiolib-acpi only). Signed-off-by: Alexandre Courbot <acourbot@nvidia.com> Tested-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
0a6d3158 |
|
24-Jul-2014 |
Linus Walleij <linus.walleij@linaro.org> |
gpio: split gpiod board registration into machine header As per example from the regulator subsystem: put all defines and functions related to registering board info for GPIO descriptors into a separate <linux/gpio/machine.h> header. Cc: Andrew Victor <linux@maxim.org.za> Cc: Nicolas Ferre <nicolas.ferre@atmel.com> Cc: Jean-Christophe Plagniol-Villard <plagnioj@jcrosoft.com> Cc: Ralf Baechle <ralf@linux-mips.org> Cc: Thierry Reding <thierry.reding@gmail.com> Acked-by: Stephen Warren <swarren@wwwdotorg.org> Reviewed-by: Alexandre Courbot <gnurou@gmail.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
f7d4ad98 |
|
22-Jul-2014 |
Guenter Roeck <linux@roeck-us.net> |
gpiolib: Export gpiochip_request_own_desc and gpiochip_free_own_desc Both functions were introduced to let gpio drivers request their own gpio pins. Without exporting the functions, this can however only be used by gpio drivers built into the kernel. Secondary impact is that the functions can not currently be used by platform initialization code associated with the gpio-pca953x driver. This code permits auto-export of gpio pins through platform data, but if this functionality is used, the module can no longer be unloaded due to the problem solved with the introduction of gpiochip_request_own_desc and gpiochip_free_own_desc. Export both function so they can be used from modules and from platform initialization code. Reviewed-by: Alexandre Courbot <acourbot@nvidia.com> Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Guenter Roeck <linux@roeck-us.net> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
d74be6df |
|
22-Jul-2014 |
Alexandre Courbot <acourbot@nvidia.com> |
gpio: remove gpiod_lock/unlock_as_irq() gpio_lock/unlock_as_irq() are working with (chip, offset) arguments and are thus not using the old integer namespace. Therefore, there is no reason to have gpiod variants of these functions working with descriptors, especially since the (chip, offset) tuple is more suitable to the users of these functions (GPIO drivers, whereas GPIO descriptors are targeted at GPIO consumers). Signed-off-by: Alexandre Courbot <acourbot@nvidia.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
1bd6b601 |
|
22-Jul-2014 |
Alexandre Courbot <acourbot@nvidia.com> |
gpio: make gpiochip_get_desc() gpiolib-private As GPIO descriptors are not going to remain unique anymore, having this function public is not safe. Restrain its use to gpiolib since we have no user outside of it. Signed-off-by: Alexandre Courbot <acourbot@nvidia.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
14c8a620 |
|
23-Jul-2014 |
Linus Walleij <linus.walleij@linaro.org> |
gpio: drop retval check enforcing from gpiochip_remove() As we start to decomission the return value from gpiochip_remove() the compilers emit warnings due to the function being tagged __must_check. So drop this until we remove the return value altogether. Cc: Abdoulaye Berthe <berthe.ab@gmail.com> Suggested-by: Stephen Rothwell <sfr@canb.auug.org.au> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
1c8732bb |
|
09-Apr-2014 |
Linus Walleij <linus.walleij@linaro.org> |
gpio: support threaded interrupts in irqchip helpers Some off-chip GPIO expanders need to be communicated by I2C or SPI traffic, but may still support IRQs. By the sleeping nature of such buses, such IRQ handlers need to be threaded. Support such handlers in the gpiochip irqchip helpers by flagging IRQs as threaded if the .can_sleep property of the gpiochip is true. Helpfully deny registration of chained IRQ handlers if the .can_sleep property is set, as such chips will invariably need a nested handler rather than a chained handler. Cc: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
c3626fde |
|
28-Mar-2014 |
Linus Walleij <linus.walleij@linaro.org> |
gpio: unmap gpio irqs properly When using the irqchip helper inside the gpiolib, make sure the IRQs are unmapped/disposed before the irqdomain is removed as part of removing the gpiochip. Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
14250520 |
|
25-Mar-2014 |
Linus Walleij <linus.walleij@linaro.org> |
gpio: add IRQ chip helpers in gpiolib This provides a function gpiochip_irqchip_add() to set up an irqchip for a GPIO controller, and a function gpiochip_set_chained_irqchip() to chain it to a parent irqchip. Most GPIOs are of the type where a number of lines form a cascaded interrupt controller chained onto the primary system interrupt controller (or further down the chain) so let's add this helper and factor the code to request the lines to be used as IRQs, the .to_irq() function and the irqdomain into the core as well. Acked-by: Thomas Gleixner <tglx@linutronix.de> Acked-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>
|
#
f9244ae5 |
|
05-Dec-2013 |
Andy Shevchenko <andriy.shevchenko@linux.intel.com> |
gpiolib: convert gpiod_lookup description to kernel-doc The patch moves description of the fields to the top of struct definition and converts them to the kernel-doc format. There is no functional change. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Acked-by: Alexandre Courbot <acourbot@nvidia.com> Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
ad824783 |
|
02-Dec-2013 |
Alexandre Courbot <acourbot@nvidia.com> |
gpio: better lookup method for platform GPIOs Change the format of the platform GPIO lookup tables to make them less confusing and improve lookup efficiency. The previous format was a single linked-list that required to compare the device name and function ID of every single GPIO defined for each lookup. Switch that to a list of per-device tables, so that the lookup can be done in two steps, omitting the GPIOs that are not relevant for a particular device. The matching rules are now defined as follows: - The device name must match *exactly*, and can be NULL for GPIOs not assigned to a particular device, - If the function ID in the lookup table is NULL, the con_id argument of gpiod_get() will not be used for lookup. However, if it is defined, it must match exactly. - The index must always match. Signed-off-by: Alexandre Courbot <acourbot@nvidia.com> Acked-by: Mika Westerberg <mika.westerberg@linux.intel.com> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
9fb1f39e |
|
04-Dec-2013 |
Linus Walleij <linus.walleij@linaro.org> |
gpio/pinctrl: make gpio_chip members typed boolean This switches the two members of struct gpio_chip that were defined as unsigned foo:1 to bool, because that is indeed what they are. Switch all users in the gpio and pinctrl subsystems to assign these values with true/false instead of 0/1. The users outside these subsystems will survive since true/false is 1/0, atleast we set some kind of more strict typing example. Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
c9a9972b |
|
25-Nov-2013 |
Alexandre Courbot <acourbot@nvidia.com> |
gpiolib: add missing declarations Add declaration of 'struct of_phandle_args' to avoid the following warning: In file included from arch/arm/mach-tegra/board-paz00.c:21:0: include/linux/gpio/driver.h:102:17: warning: 'struct of_phandle_args' declared inside parameter list include/linux/gpio/driver.h:102:17: warning: its scope is only this definition or declaration, which is probably not what you want Also proactively add other definitions/includes that could be missing in other contexts. Signed-off-by: Alexandre Courbot <acourbot@nvidia.com> Reported-by: Stephen Warren <swarren@wwwdotorg.org> Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
53e7cac3 |
|
16-Nov-2013 |
Alexandre Courbot <acourbot@nvidia.com> |
gpiolib: use dedicated flags for GPIO properties GPIO mapping properties were defined using the GPIOF_* flags, which are declared in linux/gpio.h. This file is not included when using the GPIO descriptor interface. This patch declares the flags that can be used as GPIO mappings properties in linux/gpio/driver.h, and uses them in gpiolib, so that no deprecated declarations are used by the GPIO descriptor interface. This patch also allows GPIO_OPEN_DRAIN and GPIO_OPEN_SOURCE to be specified as GPIO mapping properties. Signed-off-by: Alexandre Courbot <acourbot@nvidia.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
f3ed0b66 |
|
28-Oct-2013 |
Stephen Rothwell <sfr@canb.auug.org.au> |
gpiolib: provide a declaration of seq_file in gpio/driver.h Fixes this build error: In file included from include/asm-generic/gpio.h:13:0, from include/linux/gpio.h:51, from include/linux/of_gpio.h:20, from arch/powerpc/sysdev/ppc4xx_gpio.c:29: include/linux/gpio/driver.h:85:14: error: 'struct seq_file' declared inside= parameter list [-Werror] include/linux/gpio/driver.h:85:14: error: its scope is only this definition= or declaration, which is probably not what you want [-Werror] Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au> 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>
|