- Mar 28, 2020
-
-
Anssi Hannula authored
Commit 0161a94e ("tools: gpio: Correctly add make dependencies for gpio_utils") added a make rule for gpio-utils-in.o but used $(output) instead of the correct $(OUTPUT) for the output directory, breaking out-of-tree build (O=xx) with the following error: No rule to make target 'out/tools/gpio/gpio-utils-in.o', needed by 'out/tools/gpio/lsgpio-in.o'. Stop. Fix that. Fixes: 0161a94e ("tools: gpio: Correctly add make dependencies for gpio_utils") Cc: <stable@vger.kernel.org> Cc: Laura Abbott <labbott@redhat.com> Signed-off-by:
Anssi Hannula <anssi.hannula@bitwise.fi> Link: https://lore.kernel.org/r/20200325103154.32235-1-anssi.hannula@bitwise.fi Reviewed-by:
Bartosz Golaszewski <bgolaszewski@baylibre.com> Signed-off-by:
Linus Walleij <linus.walleij@linaro.org>
-
Mauro Carvalho Chehab authored
Use a different markup for the ERR_PTR, as %FOO doesn't work if there are parenthesis. So, use, instead: ``ERR_PTR(-EINVAL)`` This fixes the following warning: ./drivers/gpio/gpiolib.c:139: WARNING: Inline literal start-string without end-string. Signed-off-by:
Mauro Carvalho Chehab <mchehab+huawei@kernel.org> Link: https://lore.kernel.org/r/51197e3568f073e22c280f0584bfa20b44436708.1584456635.git.mchehab+huawei@kernel.org Reviewed-by:
-
- Mar 27, 2020
-
-
Thierry Reding authored
The GG.0 and GG.1 GPIOs serve as CLKREQ and RST pins, respectively, for PCIe controller 5 on Tegra194. When this controller is configured in endpoint mode, these pins need to be used as GPIOs by the PCIe endpoint driver. Typically the mode programming of these pins (GPIO vs. SFIO) is performed by early boot firmware to ensure that the configuration is consistent. However, the GG.0 and GG.1 pins are part of a special power partition that is not enabled during early boot, and hence the early boot firmware cannot program these pins to be GPIOs (they are SFIO by default). Adding them as pin ranges for the pin controller allows the pin controller to be involved when these pins are requested as GPIOs and allows the proper programming to take place. Signed-off-by:
Thierry Reding <treding@nvidia.com> Link: https://lore.kernel.org/r/20200319122737.3063291-4-thierry.reding@gmail.com Tested-by:
Vidya Sagar <vidyas@nvidia.com> Signed-off-by:
-
Thierry Reding authored
Add support for Tegra SoC generations to specify a list of pin ranges that map GPIOs to ranges of pins in the pin controller. Signed-off-by:
-
Thierry Reding authored
Wake gpiochip_generic_request() call into the pinctrl helpers only if a GPIO controller had any pin-ranges assigned to it. This allows a driver to unconditionally use this helper if it supports multiple devices of which only a subset have pin-ranges assigned to them. Signed-off-by:
-
Geert Uytterhoeven authored
impd1_probe() fills in the GPIO lookup table by manually populating an array of gpiod_lookup structures. Use the existing GPIO_LOOKUP() helper macro instead, to relax a dependency on the gpiod_lookup structure's member names. Signed-off-by:
Geert Uytterhoeven <geert+renesas@glider.be> Cc: linux-arm-kernel@lists.infradead.org Link: https://lore.kernel.org/r/20200324135653.6676-1-geert+renesas@glider.be Signed-off-by:
-
- Mar 26, 2020
-
-
Doug Berger authored
The default handling of the gpio-line-names property by the gpiolib-of implementation does not work with the multiple gpiochip banks per device structure used by the gpio-brcmstb driver. This commit adds driver level support for the device tree property so that GPIO lines can be assigned friendly names. Signed-off-by:
Doug Berger <opendmb@gmail.com> Link: https://lore.kernel.org/r/1583780521-45702-1-git-send-email-opendmb@gmail.com Acked-by:
Gregory Fong <gregory.0xf0@gmail.com> Acked-by:
Florian Fainelli <f.fainelli@gmail.com> Signed-off-by:
-
- Mar 25, 2020
-
-
Linus Walleij authored
Merge tag 'gpio-updates-for-v5.7-part4' of git://git.kernel.org/pub/scm/linux/kernel/git/brgl/linux into devel gpio updates for v5.7 part 4 - improve comments in the uapi header - fix documentation issues - add a warning to gpio-pl061 when the IRQ line is not configured - allow building gpio-mxc and gpio-mxs with COMPILE_TEST enabled - don't print an error message when an optional IRQ is missing in gpio-mvebu - fix a potential segfault in gpio-hammer - fix a couple typos and coding style issues in gpio tools - provide a new flag in gpio-mmio and use it in mt7621 to fix an issue with the controller ignoring value setting when a GPIO is in input mode - slightly refactor gpio_name_to_desc()
-
Mykyta Poturai authored
Replace COMSUMER with proper CONSUMER Signed-off-by:
Mykyta Poturai <mykyta.poturai@gmail.com> Signed-off-by:
-
Gabriel Ravier authored
"retain good changes" means that I left the help string split up instead of having this weird thing where it tries to merge together the last three lines and it looks **really** bad Signed-off-by:
Gabriel Ravier <gabravier@gmail.com> Signed-off-by:
-
Michał Mirosław authored
Since name == NULL can't ever match, move the check out of IRQ-disabled region. Signed-off-by:
Michał Mirosław <mirq-linux@rere.qmqm.pl> Signed-off-by:
-
Colin Ian King authored
There is a spelling mistake in an error message. Fix it. Signed-off-by:
Colin Ian King <colin.king@canonical.com> Signed-off-by:
-
Chuanhong Guo authored
DSET/DCLR registers only works on output pins. Add corresponding BGPIOF_NO_SET_ON_INPUT flag to bgpio_init call to fix direction_out behavior. 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:
-
Chuanhong Guo authored
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:
-
Gabriel Ravier authored
If '-o' was used more than 64 times in a single invocation of gpio-hammer, this could lead to an overflow of the 'lines' array. This commit fixes this by avoiding the overflow and giving a proper diagnostic back to the user Signed-off-by:
-
Chris Packham authored
platform_get_irq() will generate an error message if the requested irq is not present mvebu-gpio f1010140.gpio: IRQ index 3 not found use platform_get_irq_optional() to avoid the error message being generated. Signed-off-by:
Chris Packham <chris.packham@alliedtelesis.co.nz> Acked-by:
Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by:
-
Anson Huang authored
Add COMPILE_TEST support to GPIO_MXS driver for better compile testing coverage. Signed-off-by:
Anson Huang <Anson.Huang@nxp.com> Reported-by:
kbuild test robot <lkp@intel.com> Signed-off-by:
-
Anson Huang authored
Add COMPILE_TEST support to GPIO_MXC driver for better compile testing coverage. Signed-off-by:
-
Alexander Sverdlin authored
Existing (irq < 0) condition is always false because adev->irq has unsigned type and contains 0 in case of failed irq_of_parse_and_map(). Up to now all the mapping errors were silently ignored. Seems that repairing this check would be backwards-incompatible and might break the probe() for the implementations without IRQ support. Therefore warn the user instead. Signed-off-by:
Alexander Sverdlin <alexander.sverdlin@nokia.com> Signed-off-by:
-
Mauro Carvalho Chehab authored
Two literal blocks there are marked with both "::" and .. code-block:: c This causes Sphinx (2.4.1) to do the wrong thing, causing lots of warnings: Documentation/driver-api/gpio/driver.rst:425: WARNING: Unexpected indentation. Documentation/driver-api/gpio/driver.rst:423: WARNING: Inline emphasis start-string without end-string. Documentation/driver-api/gpio/driver.rst:427: WARNING: Block quote ends without a blank line; unexpected unindent. Documentation/driver-api/gpio/driver.rst:429: WARNING: Inline emphasis start-string without end-string. Documentation/driver-api/gpio/driver.rst:429: WARNING: Inline emphasis start-string without end-string. Documentation/driver-api/gpio/driver.rst:429: WARNING: Inline emphasis start-string without end-string. Documentation/driver-api/gpio/driver.rst:433: WARNING: Inline emphasis start-string without end-string. Documentation/driver-api/gpio/driver.rst:446: WARNING: Unexpected indentation. Documentation/driver-api/gpio/driver.rst:440: WARNING: Inline emphasis start-string without end-string. Documentation/driver-api/gpio/driver.rst:440: WARNING: Inline emphasis start-string without end-string. Documentation/driver-api/gpio/driver.rst:447: WARNING: Block quote ends without a blank line; unexpected unindent. Documentation/driver-api/gpio/driver.rst:449: WARNING: Definition list ends without a blank line; unexpected unindent. Documentation/driver-api/gpio/driver.rst:462: WARNING: Unexpected indentation. Documentation/driver-api/gpio/driver.rst:460: WARNING: Inline emphasis start-string without end-string. Documentation/driver-api/gpio/driver.rst:462: WARNING: Inline emphasis start-string without end-string. Documentation/driver-api/gpio/driver.rst:465: WARNING: Block quote ends without a blank line; unexpected unindent. Documentation/driver-api/gpio/driver.rst:467: WARNING: Inline emphasis start-string without end-string. Documentation/driver-api/gpio/driver.rst:467: WARNING: Inline emphasis start-string without end-string. Documentation/driver-api/gpio/driver.rst:467: WARNING: Inline emphasis start-string without end-string. Documentation/driver-api/gpio/driver.rst:471: WARNING: Inline emphasis start-string without end-string. Documentation/driver-api/gpio/driver.rst:478: WARNING: Inline emphasis start-string without end-string. Signed-off-by: -
Jonathan Neuschäfer authored
Character arrays can be considered empty strings (if they are immediately terminated), but they cannot be NULL. Signed-off-by:
Jonathan Neuschäfer <j.neuschaefer@gmx.net> Signed-off-by:
-
- Mar 20, 2020
-
-
Linus Walleij authored
These two devres functions devm_gpiochip_[add|remove]() were in the wrong file. They should be in gpiolib-devres.c not gpiolib.c. Link: https://lore.kernel.org/r/20200313081522.35143-1-linus.walleij@linaro.org Reviewed-by:
-
- Mar 09, 2020
-
-
Linus Walleij authored
-
Tony Lindgren authored
This reverts commit a522f1d0 . With cpu_pm handling fixed for omaps, and with gpio-omap now returning notify error on pending interrupts, we can drop the old workaround for seeing if there may be pending edge interrupts. Depends-on: ARM: OMAP2+: Handle errors for cpu_pm Depends-on: gpio: omap: Block idle on pending gpio interrupts Cc: Aaro Koskinen <aaro.koskinen@iki.fi> Cc: Grygorii Strashko <grygorii.strashko@ti.com> Cc: Keerthy <j-keerthy@ti.com> Cc: Ladislav Michl <ladis@linux-mips.org> Cc: Peter Ujfalusi <peter.ujfalusi@ti.com> Cc: Russell King <rmk+kernel@armlinux.org.uk> Cc: Tero Kristo <t-kristo@ti.com> Signed-off-by:
Tony Lindgren <tony@atomide.com> Signed-off-by:
-
Tony Lindgren authored
With the SoC cpuidle handling fixed for cpu_pm, we can now start to return NOTIFY_BAD if there there are pending gpio interrupts. This way the deeper SoC idle states can get blocked, and gpio latency is improved in some cases. Note that this will not help with the latency if the SoC has already entered a deeper idle state. Note that this patch depends on cpu_pm properly handling the errors returned by notifiers. For omap variants, this is fixed with patch "ARM: OMAP2+: Handle errors for cpu_pm". Cc: Dave Gerlach <d-gerlach@ti.com> Cc: Grygorii Strashko <grygorii.strashko@ti.com> Cc: Keerthy <j-keerthy@ti.com> Cc: Ladislav Michl <ladis@linux-mips.org> Cc: Russell King <rmk+kernel@armlinux.org.uk> Cc: Tero Kristo <t-kristo@ti.com> Signed-off-by:
-
Tony Lindgren authored
We need to check for errors when calling cpu_pm_enter() and cpu_cluster_pm_enter(). And we need to bail out on errors as otherwise we can enter a deeper idle state when not desired. I'm not aware of the lack of error handling causing issues yet, but we need this at least for blocking deeper idle states when a GPIO instance has pending interrupts. Cc: Dave Gerlach <d-gerlach@ti.com> Cc: Grygorii Strashko <grygorii.strashko@ti.com> Cc: Keerthy <j-keerthy@ti.com> Cc: Ladislav Michl <ladis@linux-mips.org> Cc: Russell King <rmk+kernel@armlinux.org.uk> Cc: Tero Kristo <t-kristo@ti.com> Signed-off-by:
-
Asmaa Mnebhi authored
This patch adds support for the GPIO controller used by Mellanox BlueField 2 SOCs. Signed-off-by:
Asmaa Mnebhi <Asmaa@mellanox.com> Link: https://lore.kernel.org/r/1680de9eb6d2b8855228dde9a2dd065f0dcbe1fb.1583182325.git.Asmaa@mellanox.com Signed-off-by:
-
- Mar 03, 2020
-
-
Linus Walleij authored
Merge tag 'gpio-updates-for-v5.7-part2' of git://git.kernel.org/pub/scm/linux/kernel/git/brgl/linux into devel gpio updates for v5.7 part 2 - replace z zero-length array with flexible-array member in gpio-uniphier - make naming of variables consistent in uapi line event code - fix the behavior of line watch/unwatch ioctl()
-
Geert Uytterhoeven authored
The optimization to check for requested lines actually optimized for the uncomon error case, where one of the GPIO lines is still in use. Hence the error message must be printed when the loop is terminated early, not when it went through all available GPIO lines. Fixes: 869233f8 ("gpiolib: Optimize gpiochip_remove() when check for requested line") Signed-off-by:
Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by:
-
- Mar 02, 2020
-
-
Bartosz Golaszewski authored
When operating on the bits of watched_lines bitmap, we're using desc_to_gpio() which returns the GPIO number from the global numberspace. This leads to all sorts of memory corruptions and invalid behavior. We should switch to using gpio_chip_hwgpio() instead. Fixes: 51c1064e ("gpiolib: add new ioctl() for monitoring changes in line info") Reported-by:
Kent Gibson <warthog618@gmail.com> Signed-off-by:
-
Kent Gibson authored
Fix the field having a bit cleared by the unwatch ioctl(). Fixes: 51c1064e ("gpiolib: add new ioctl() for monitoring changes in line info") Signed-off-by:
-
Andy Shevchenko authored
Rename 'event' to 'ge' to be consistent with other use. Signed-off-by:
-
Gustavo A. R. Silva authored
The current codebase makes use of the zero-length array language extension to the C90 standard, but the preferred mechanism to declare variable-length types such as these ones is a flexible array member[1][2], introduced in C99: struct foo { int stuff; struct boo array[]; }; By making use of the mechanism above, we will get a compiler warning in case the flexible array does not occur last in the structure, which will help us prevent some kind of undefined behavior bugs from being inadvertenly introduced[3] to the codebase from now on. This issue was found with the help of Coccinelle. [1] https://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html [2] https://github.com/KSPP/linux/issues/21 [3] commit 76497732 ("cxgb3/l2t: Fix undefined behaviour") Signed-off-by:Gustavo A. R. Silva <gustavo@embeddedor.com> Signed-off-by:
-
- Feb 29, 2020
-
-
Andy Shevchenko authored
Here are the following optimizations have been done: - break the loop after first found requested line - due to above, drop redundant boolean variable - replace open coded variant of gpiochip_is_requested() - due to above, drop redundant pointer to struct gpio_desc - use 'unsigned int' instead of 'unsigned' for loop counter Note, pointer to struct gpio_chip followed by pointer to struct gpio_device is still valid, back link is not. Signed-off-by:
-
- Feb 22, 2020
-
-
Geert Uytterhoeven authored
As GPIO hogs are configured at GPIO controller initialization time, adding/removing GPIO hogs in DT overlays does not work. Add support for GPIO hogs described in DT overlays by registering an OF reconfiguration notifier, to handle the addition and removal of GPIO hog subnodes to/from a GPIO controller device node. Note that when a GPIO hog device node is being removed, its "gpios" properties is no longer available, so we have to keep track of which node a hog belongs to, which is done by adding a pointer to the hog's device node to struct gpio_desc. Signed-off-by:
Frank Rowand <frank.rowand@sony.com> Signed-off-by:
-
Geert Uytterhoeven authored
Extract the code to add all GPIO hogs of a gpio-hog node into its own function, so it can be reused. Signed-off-by:
-
- Feb 21, 2020
-
-
Linus Walleij authored
The existing use of ktime_get_real_ns() in the timestamps from the GPIO events is dubious. We have had several discussions about this timestamp, and it is unclear whether userspace has ever taken into account that a timestamp from ktime_get_real_ns() can actually move backwards in time relative the previous timetamp, and userspace is more likely to expect a monotonic counter. Background: https://lore.kernel.org/linux-gpio/CAK8P3a1Skvm48sje8FNDPLYqyz9Lf8q0qX1QETWtyZTxuX4k1g@mail.gmail.com/ https://marc.info/?l=linux-gpio&m=151661955709074&w=2 The change is ABI incompatible, but incompatible in a way that is IMO more likely to fix future bugs rather than break current userspace. To the best of my knowledge all userspace expects a monotonic timestamp and users are just lucky that they very seldom move backwards in time. Cc: Arnd Bergmann <arnd@arndb.de> Acked-by:
-
Bartosz Golaszewski authored
Whenever retrieving a descriptor from a gpiochip: use the provided helper which checks for errors. Signed-off-by:
-
Uwe Kleine-König authored
All the irq related callbacks are called with the (raw) spinlock desc->lock being held. So the lock here must be raw as well. Also irqs were already disabled by the caller for the irq chip callbacks, so the non-irq variants of spin_lock must be used there. Fixes: be8c8fac ("gpio: new driver to work with a 8x12 siox") Signed-off-by:
Uwe Kleine-König <uwe@kleine-koenig.org> Link: https://lore.kernel.org/r/20200211135121.15752-1-uwe@kleine-koenig.org Signed-off-by:
-
- Feb 20, 2020
-
-
Bartosz Golaszewski authored
The indentation is wrong in gpio_mockup_apply_pull(). This patch makes the code more readable. Signed-off-by:
-
