summaryrefslogtreecommitdiff
path: root/drivers/gpio
AgeCommit message (Collapse)Author
2020-04-04Merge tag 'gpio-v5.7-1' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-gpio Pull GPIO updates from Linus Walleij: "This is the bulk of GPIO development for the v5.7 kernel cycle. Core and userspace API: - The userspace API KFIFOs have been imoproved with locks that do not block interrupts. This makes us better at getting events to userspace without blocking or disturbing new events arriving in the same time. This was reviewed by the KFIFO maintainer Stefani. This is a generic improvement which paves the road for similar improvements in other subsystems. - We provide a new ioctl() for monitoring changes in the line information, such as when multiple clients are taking lines and giving them back, possibly reconfiguring them in the process: we can now monitor that and not get stuck with stale static information. - An example tool 'gpio-watch' is provided to showcase this functionality. - Timestamps for events are switched to ktime_get_ns() which is monotonic. We previously had a 'realtime' stamp which could move forward and *backward* in time, which probably would just cause silent bugs and weird behaviour. In the long run we see two relevant timestamps: ktime_get_ns() or the timestamp sometimes provided by the GPIO hardware itself, if that exists. - Device Tree overlay support for GPIO hogs. On systems that load overlays, these overlays can now contain hogs, and will then be respected. - Handle pin control interaction with nonexisting pin ranges in the GPIO library core instead of in the individual drivers. New drivers: - New driver for the Mellanox BlueField 2 GPIO controller. Driver improvements: - Introduce the BGPIOF_NO_SET_ON_INPUT flag to the generic MMIO GPIO library and use this flag in the MT7621 driver. - Texas Instruments OMAP CPU power management improvements, such as blocking of idle on pending GPIO interrupts" * tag 'gpio-v5.7-1' of git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-gpio: (59 commits) Revert "gpio: eic-sprd: Use devm_platform_ioremap_resource()" pinctrl: Unconditionally assign .request()/.free() gpio: Unconditionally assign .request()/.free() gpio: export of_pinctrl_get to modules pinctrl: Define of_pinctrl_get() dummy for !PINCTRL gpio: Rename variable in core APIs gpio: Avoid using pin ranges with !PINCTRL gpiolib: Remove unused gpio_chip parameter from gpio_set_bias() gpiolib: Pass gpio_desc to gpio_set_config() gpiolib: Introduce gpiod_set_config() tools: gpio: Fix out-of-tree build regression gpio: gpiolib: fix a doc warning gpio: tegra186: Add Tegra194 pin ranges for GG.0 and GG.1 gpio: tegra186: Add support for pin ranges gpio: Support GPIO controllers without pin-ranges ARM: integrator: impd1: Use GPIO_LOOKUP() helper macro gpio: brcmstb: support gpio-line-names property tools: gpio: Fix typo in gpio-utils tools: gpio-hammer: Apply scripts/Lindent and retain good changes gpiolib: gpio_name_to_desc: factor out !name check ...
2020-04-02Merge tag 'pinctrl-v5.7-1' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-pinctrl Pull pin control updates from Linus Walleij: "This is the bulk of pin control changes for the v5.7 kernel cycle. There are no core changes this time, only driver developments: - New driver for the Dialog Semiconductor DA9062 Power Management Integrated Circuit (PMIC). - Renesas SH-PFC has improved consistency, with group and register checks in the configuration checker. - New subdriver for the Qualcomm IPQ6018. - Add the RGMII pin control functionality to Qualcomm IPQ8064. - Performance and code quality cleanups in the Mediatek driver. - Improve the Broadcom BCM2835 support to cover all the GPIOs that exist in it. - The Allwinner/Sunxi driver properly masks non-wakeup IRQs on suspend. - Add some missing groups and functions to the Ingenic driver. - Convert some of the Freescale device tree bindings to use the new and all improved JSON YAML markup. - Refactorings and support for the SFIO/GPIO in the Tegra194 SoC driver. - Support high impedance mode in the Spreadtrum/Unisoc driver" * tag 'pinctrl-v5.7-1' of git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-pinctrl: (64 commits) pinctrl: qcom: fix compilation error pinctrl: qcom: use scm_call to route GPIO irq to Apps pinctrl: sprd: Add pin high impedance mode support pinctrl: sprd: Use the correct pin output configuration pinctrl: tegra: Add SFIO/GPIO programming on Tegra194 pinctrl: tegra: Renumber the GG.0 and GG.1 pins pinctrl: tegra: Do not add default pin range on Tegra194 pinctrl: tegra: Pass struct tegra_pmx for pin range check pinctrl: tegra: Fix "Scmitt" -> "Schmitt" typo pinctrl: tegra: Fix whitespace issues for improved readability pinctrl: mediatek: Use scnprintf() for avoiding potential buffer overflow pinctrl: freescale: drop the dependency on ARM64 for i.MX8M Revert "pinctrl: mvebu: armada-37xx: use use platform api" dt-bindings: pinctrl: at91: Fix a typo ("descibe") pinctrl: meson: add tsin pinctrl for meson gxbb/gxl/gxm pinctrl: sprd: Fix the kconfig warning pinctrl: ingenic: add hdmi-ddc pin control group pinctrl: sirf/atlas7: Replace zero-length array with flexible-array member pinctrl: sprd: Allow the SPRD pinctrl driver building into a module pinctrl: Export some needed symbols at module load time ...
2020-04-02Revert "gpio: eic-sprd: Use devm_platform_ioremap_resource()"Baolin Wang
This reverts commit 0f5cb8cc27a266c81e6523b436479802e9aafc9e. This commit will cause below warnings, since our EIC controller can support differnt banks on different Spreadtrum SoCs, and each bank has its own base address, we will get invalid resource warning if the bank number is less than SPRD_EIC_MAX_BANK on some Spreadtrum SoCs. So we should not use devm_platform_ioremap_resource() here to remove the warnings. [ 1.118508] sprd-eic 40210000.gpio: invalid resource [ 1.118535] sprd-eic 40210000.gpio: invalid resource [ 1.119034] sprd-eic 40210080.gpio: invalid resource [ 1.119055] sprd-eic 40210080.gpio: invalid resource [ 1.119462] sprd-eic 402100a0.gpio: invalid resource [ 1.119482] sprd-eic 402100a0.gpio: invalid resource [ 1.119893] sprd-eic 402100c0.gpio: invalid resource [ 1.119913] sprd-eic 402100c0.gpio: invalid resource Signed-off-by: Baolin Wang <baolin.wang7@gmail.com> Link: https://lore.kernel.org/r/8d3579f4b49bb675dc805035960f24852898be28.1585734060.git.baolin.wang7@gmail.com Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2020-04-02gpio: Unconditionally assign .request()/.free()Thierry Reding
The gpiochip_generic_request() and gpiochip_generic_free() functions can now deal properly with chips that don't have any pin-ranges defined, so they can be assigned unconditionally. Suggested-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Thierry Reding <treding@nvidia.com> Link: https://lore.kernel.org/r/20200401200527.2982450-1-thierry.reding@gmail.com Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2020-03-31gpio: Rename variable in core APIsLinus Walleij
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>
2020-03-31gpio: Avoid using pin ranges with !PINCTRLThierry Reding
Do not use the struct gpio_device's .pin_ranges field if the PINCTRL Kconfig symbol is not selected to avoid build failures. Fixes: 2ab73c6d8323fa1e ("gpio: Support GPIO controllers without pin-ranges") Reported-by: Stephen Rothwell <sfr@canb.auug.org.au> Reported-by: kbuild test robot <lkp@intel.com> Signed-off-by: Thierry Reding <treding@nvidia.com> Link: https://lore.kernel.org/r/20200330090257.2332864-1-thierry.reding@gmail.com Reviewed-by: Geert Uytterhoeven <geert@linux-m68k.org> Tested-by: Geert Uytterhoeven <geert@linux-m68k.org> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2020-03-27gpiolib: Remove unused gpio_chip parameter from gpio_set_bias()Geert Uytterhoeven
gpio_set_bias() no longer uses the passed gpio_chip pointer parameter. Remove it. Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Link: https://lore.kernel.org/r/20200325100439.14000-3-geert+renesas@glider.be Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2020-03-27gpiolib: Pass gpio_desc to gpio_set_config()Geert Uytterhoeven
All callers of gpio_set_config() have to convert a gpio_desc to a gpio_chip and offset. Avoid these duplicated conversion steps by letting gpio_set_config() take a gpio_desc pointer directly. Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Link: https://lore.kernel.org/r/20200325100439.14000-2-geert+renesas@glider.be Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2020-03-27gpiolib: Introduce gpiod_set_config()Geert Uytterhoeven
The GPIO Aggregator will need a method to forward a .set_config() call to its parent gpiochip. This requires obtaining the gpio_chip and offset for a given gpio_desc. While gpiod_to_chip() is public, gpio_chip_hwgpio() is not, so there is currently no method to obtain the needed GPIO offset parameter. Hence introduce a public gpiod_set_config() helper, which invokes the .set_config() callback through a gpio_desc pointer, like is done for most other gpio_chip callbacks. Rewrite the existing gpiod_set_debounce() helper as a wrapper around gpiod_set_config(), to avoid duplication. Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Link: https://lore.kernel.org/r/20200324135653.6676-5-geert+renesas@glider.be Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2020-03-27Merge tag 'v5.6-rc7' into develLinus Walleij
Linux 5.6-rc7
2020-03-27gpio: gpiolib: fix a doc warningMauro Carvalho Chehab
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: Bartosz Golaszewski <bgolaszewski@baylibre.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2020-03-27gpio: tegra186: Add Tegra194 pin ranges for GG.0 and GG.1Thierry Reding
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: Linus Walleij <linus.walleij@linaro.org>
2020-03-27gpio: tegra186: Add support for pin rangesThierry Reding
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 <treding@nvidia.com> Link: https://lore.kernel.org/r/20200319122737.3063291-3-thierry.reding@gmail.com Tested-by: Vidya Sagar <vidyas@nvidia.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2020-03-27gpio: Support GPIO controllers without pin-rangesThierry Reding
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: Thierry Reding <treding@nvidia.com> Link: https://lore.kernel.org/r/20200319122737.3063291-2-thierry.reding@gmail.com Tested-by: Vidya Sagar <vidyas@nvidia.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2020-03-26gpio: brcmstb: support gpio-line-names propertyDoug Berger
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: Linus Walleij <linus.walleij@linaro.org>
2020-03-25gpiolib: gpio_name_to_desc: factor out !name checkMichał Mirosław
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: Bartosz Golaszewski <bgolaszewski@baylibre.com>
2020-03-25gpio: mt7621: add BGPIOF_NO_SET_ON_INPUT flagChuanhong Guo
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: Bartosz Golaszewski <bgolaszewski@baylibre.com>
2020-03-25gpio: mmio: introduce BGPIOF_NO_SET_ON_INPUTChuanhong Guo
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>
2020-03-25gpio: mvebu: avoid error message for optional IRQChris Packham
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: Bartosz Golaszewski <bgolaszewski@baylibre.com>
2020-03-25gpio: mxs: add COMPILE_TEST support for GPIO_MXSAnson Huang
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: Bartosz Golaszewski <bgolaszewski@baylibre.com>
2020-03-25gpio: mxc: Add COMPILE_TEST support for GPIO_MXCAnson Huang
Add COMPILE_TEST support to GPIO_MXC driver for better compile testing coverage. Signed-off-by: Anson Huang <Anson.Huang@nxp.com> Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
2020-03-25gpio: pl061: Warn when IRQ line has not been configuredAlexander Sverdlin
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: Bartosz Golaszewski <bgolaszewski@baylibre.com>
2020-03-24gpiolib: acpi: Add quirk to ignore EC wakeups on HP x2 10 CHT + AXP288 modelHans de Goede
There are at least 3 models of the HP x2 10 models: Bay Trail SoC + AXP288 PMIC Cherry Trail SoC + AXP288 PMIC Cherry Trail SoC + TI PMIC Like on the other HP x2 10 models we need to ignore wakeup for ACPI GPIO events on the external embedded-controller pin to avoid spurious wakeups on the HP x2 10 CHT + AXP288 model too. This commit adds an extra DMI based quirk for the HP x2 10 CHT + AXP288 model, ignoring wakeups for ACPI GPIO events on the EC interrupt pin on this model. This fixes spurious wakeups from suspend on this model. Fixes: aa23ca3d98f7 ("gpiolib: acpi: Add honor_wakeup module-option + quirk mechanism") Reported-and-tested-by: Marc Lehmann <schmorp@schmorp.de> Signed-off-by: Hans de Goede <hdegoede@redhat.com> Link: https://lore.kernel.org/r/20200302111225.6641-4-hdegoede@redhat.com Acked-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2020-03-20gpio: Move devres calls to devres fileLinus Walleij
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: Bartosz Golaszewski <bgolaszewski@baylibre.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2020-03-11gpiolib: acpi: Add quirk to ignore EC wakeups on HP x2 10 BYT + AXP288 modelHans de Goede
Commit aa23ca3d98f7 ("gpiolib: acpi: Add honor_wakeup module-option + quirk mechanism") was added to deal with spurious wakeups on one specific model of the HP x2 10 series. In the mean time I have learned that there are at least 3 different HP x2 10 models: Bay Trail SoC + AXP288 PMIC Cherry Trail SoC + AXP288 PMIC Cherry Trail SoC + TI PMIC And the original quirk is only correct for (and only matches the) Cherry Trail SoC + TI PMIC model. The Bay Trail SoC + AXP288 PMIC model has different DMI strings, has the external EC interrupt on a different GPIO pin and only needs to ignore wakeups on the EC interrupt, the INT0002 device works fine on this model. This commit adds an extra DMI based quirk for the HP x2 10 BYT + AXP288 model, ignoring wakeups for ACPI GPIO events on the EC interrupt pin on this model. This fixes spurious wakeups from suspend on this model. Fixes: aa23ca3d98f7 ("gpiolib: acpi: Add honor_wakeup module-option + quirk mechanism") Signed-off-by: Hans de Goede <hdegoede@redhat.com> Link: https://lore.kernel.org/r/20200302111225.6641-3-hdegoede@redhat.com Acked-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2020-03-11gpiolib: acpi: Rework honor_wakeup option into an ignore_wake optionHans de Goede
Commit aa23ca3d98f7 ("gpiolib: acpi: Add honor_wakeup module-option + quirk mechanism") was added to deal with spurious wakeups on one specific model of the HP x2 10 series. The approach taken there was to add a bool controlling wakeup support for all ACPI GPIO events. This was sufficient for the specific HP x2 10 model the commit was trying to fix, but in the mean time other models have turned up which need a similar workaround to avoid spurious wakeups from suspend, but only for one of the pins on which the ACPI tables request ACPI GPIO events. Since the honor_wakeup option was added to be able to ignore wake events, the name was perhaps not the best, this commit renames it to ignore_wake and changes it to a string with the following format: gpiolib_acpi.ignore_wake=controller@pin[,controller@pin[,...]] This allows working around spurious wakeup issues on a per pin basis. This commit also reworks the existing quirk for the HP x2 10 so that it functions as before. Note: -This removes the honor_wakeup parameter. This has only been upstream for a short time and to the best of my knowledge there are no users using this module parameter. -The controller@pin[,controller@pin[,...]] syntax is based on an existing kernel module parameter using the same controller@pin format. That version uses ';' as separator, but in practice that is problematic because grub2 cannot handle this without taking special care to escape the ';', so here we are using a ',' as separator instead which does not have this issue. Fixes: aa23ca3d98f7 ("gpiolib: acpi: Add honor_wakeup module-option + quirk mechanism") Signed-off-by: Hans de Goede <hdegoede@redhat.com> Link: https://lore.kernel.org/r/20200302111225.6641-2-hdegoede@redhat.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>
2020-03-11gpiolib: acpi: Correct comment for HP x2 10 honor_wakeup quirkHans de Goede
Commit aa23ca3d98f7 ("gpiolib: acpi: Add honor_wakeup module-option + quirk mechanism") added a quirk for some models of the HP x2 10 series. There are 2 issues with the comment describing the quirk: 1) The comment claims the DMI quirk applies to all Cherry Trail based HP x2 10 models. In the mean time I have learned that there are at least 3 models of the HP x2 10 models: Bay Trail SoC + AXP288 PMIC Cherry Trail SoC + AXP288 PMIC Cherry Trail SoC + TI PMIC And this quirk's DMI matches only match the Cherry Trail SoC + TI PMIC SoC, which is good because we want a slightly different quirk for the others. This commit updates the comment to make it clear that the quirk is only for the Cherry Trail SoC + TI PMIC models. 2) The comment says that it is ok to disable wakeup on all ACPI GPIO event handlers, because there is only the one for the embedded-controller events. This is not true, there also is a handler for the special INT0002 device which is related to USB wakeups. We need to also disable wakeups on that one because the device turns of the USB-keyboard built into the dock when closing the lid. The XHCI controller takes a while to notice this, so it only notices it when already suspended, causing a spurious wakeup because of this. So disabling wakeup on all handlers is the right thing to do, but not because there only is the one handler for the EC events. This commit updates the comment to correctly reflect this. Fixes: aa23ca3d98f7 ("gpiolib: acpi: Add honor_wakeup module-option + quirk mechanism") Signed-off-by: Hans de Goede <hdegoede@redhat.com> Link: https://lore.kernel.org/r/20200302111225.6641-1-hdegoede@redhat.com Acked-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2020-03-11gpiolib: Fix irq_disable() semanticsLinus Walleij
The implementation if .irq_disable() which kicks in between the gpiolib and the driver is not properly mimicking the expected semantics of the irqchip core: the irqchip will call .irq_disable() if that exists, else it will call mask_irq() which first checks if .irq_mask() is defined before calling it. Since we are calling it unconditionally, we get this bug from drivers/pinctrl/qcom/pinctrl-ssbi-gpio.c, as it only defines .irq_mask_ack and not .irq_mask: Unable to handle kernel NULL pointer dereference at virtual address 00000000 pgd = (ptrval) (...) PC is at 0x0 LR is at gpiochip_irq_disable+0x20/0x30 Fix this by only calling .irq_mask() if it exists. Cc: Brian Masney <masneyb@onstation.org> Cc: Hans Verkuil <hans.verkuil@cisco.com> Cc: stable@vger.kernel.org Reviewed-by: Bartosz Golaszewski <bgolaszewski@baylibre.com> Fixes: 461c1a7d4733 ("gpiolib: override irq_enable/disable") Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Link: https://lore.kernel.org/r/20200306132326.1329640-1-linus.walleij@linaro.org
2020-03-09Merge branch 'ib-omap-block-idle' into develLinus Walleij
2020-03-09Revert "gpio: omap: Fix lost edge wake-up interrupts"Tony Lindgren
This reverts commit a522f1d0c381c42f3ace13b8bbeeccabdd6d2e5c. 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: Linus Walleij <linus.walleij@linaro.org> Link: https://lore.kernel.org/r/20200304225433.37336-4-tony@atomide.com Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2020-03-09gpio: omap: Block idle on pending gpio interruptsTony Lindgren
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 <tony@atomide.com> Link: https://lore.kernel.org/r/20200304225433.37336-3-tony@atomide.com Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2020-03-09gpio: add driver for Mellanox BlueField 2 GPIO controllerAsmaa Mnebhi
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: Linus Walleij <linus.walleij@linaro.org>
2020-03-03Merge tag 'gpio-updates-for-v5.7-part2' of ↵Linus Walleij
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()
2020-03-03gpiolib: Fix inverted check in gpiochip_remove()Geert Uytterhoeven
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: 869233f81337bfb3 ("gpiolib: Optimize gpiochip_remove() when check for requested line") Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Link: https://lore.kernel.org/r/20200302082448.11795-1-geert+renesas@glider.be Acked-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2020-03-02gpiolib: fix bitmap operations related to line event watchingBartosz Golaszewski
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: 51c1064e82e7 ("gpiolib: add new ioctl() for monitoring changes in line info") Reported-by: Kent Gibson <warthog618@gmail.com> Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com> Tested-by: Kent Gibson <warthog618@gmail.com>
2020-03-02gpiolib: fix unwatch ioctl()Kent Gibson
Fix the field having a bit cleared by the unwatch ioctl(). Fixes: 51c1064e82e7 ("gpiolib: add new ioctl() for monitoring changes in line info") Signed-off-by: Kent Gibson <warthog618@gmail.com> Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
2020-03-02gpiolib: Rename 'event' to 'ge' to be consistent with other useAndy Shevchenko
Rename 'event' to 'ge' to be consistent with other use. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
2020-03-02gpio: uniphier: Replace zero-length array with flexible-array memberGustavo A. R. Silva
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 76497732932f ("cxgb3/l2t: Fix undefined behaviour") Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com> Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
2020-02-28gpiolib: Optimize gpiochip_remove() when check for requested lineAndy Shevchenko
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: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Link: https://lore.kernel.org/r/20200225114725.839-1-andriy.shevchenko@linux.intel.com Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2020-02-25gpiolib: export gpiochip_get_descMarco Felsch
The function was currently used internal by the gpiolib. Since commit 56cc3af4e8c8 ("pinctrl: da9062: add driver support") it is also used by drivers so we need to export the symbol. Signed-off-by: Marco Felsch <m.felsch@pengutronix.de> Link: https://lore.kernel.org/r/20200225093102.10964-1-m.felsch@pengutronix.de Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2020-02-21gpio: of: Add DT overlay support for GPIO hogsGeert Uytterhoeven
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: Geert Uytterhoeven <geert+renesas@glider.be> Link: https://lore.kernel.org/r/20200220130149.26283-3-geert+renesas@glider.be Reviewed-by: Frank Rowand <frank.rowand@sony.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2020-02-21gpio: of: Extract of_gpiochip_add_hog()Geert Uytterhoeven
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: Geert Uytterhoeven <geert+renesas@glider.be> Link: https://lore.kernel.org/r/20200220130149.26283-2-geert+renesas@glider.be Reviewed-by: Frank Rowand <frank.rowand@sony.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2020-02-21gpio: Switch timestamps to ktime_get_ns()Linus Walleij
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 <bgolaszewski@baylibre.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2020-02-21gpiolib: use gpiochip_get_desc() where applicableBartosz Golaszewski
Whenever retrieving a descriptor from a gpiochip: use the provided helper which checks for errors. Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com> Link: https://lore.kernel.org/r/20200219094702.6463-1-brgl@bgdev.pl Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2020-02-21gpio: siox: use raw spinlock for irq related lockingUwe Kleine-König
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: be8c8facc707 ("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: Linus Walleij <linus.walleij@linaro.org>
2020-02-20gpio: mockup: coding-style fixBartosz Golaszewski
The indentation is wrong in gpio_mockup_apply_pull(). This patch makes the code more readable. Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com> Link: https://lore.kernel.org/r/20200210155059.29609-1-brgl@bgdev.pl Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2020-02-20gpio: rcar: Fix typo in commentAshish Chavan
"Positive" is spelled incorrectly as "Postive" in comment fix this. Signed-off-by: Ashish Chavan <ashish.gschavan@gmail.com> Link: https://lore.kernel.org/r/20200209095600.16394-1-ashish.gschavan@gmail.com Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2020-02-12gpiolib: add new ioctl() for monitoring changes in line infoBartosz Golaszewski
Currently there is no way for user-space to be informed about changes in status of GPIO lines e.g. when someone else requests the line or its config changes. We can only periodically re-read the line-info. This is fine for simple one-off user-space tools, but any daemon that provides a centralized access to GPIO chips would benefit hugely from an event driven line info synchronization. This patch adds a new ioctl() that allows user-space processes to reuse the file descriptor associated with the character device for watching any changes in line properties. Every such event contains the updated line information. Currently the events are generated on three types of status changes: when a line is requested, when it's released and when its config is changed. The first two are self-explanatory. For the third one: this will only happen when another user-space process calls the new SET_CONFIG ioctl() as any changes that can happen from within the kernel (i.e. set_transitory() or set_debounce()) are of no interest to user-space. Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com> Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
2020-02-12gpiolib: provide a dedicated function for setting lineinfoBartosz Golaszewski
We'll soon be filling out the gpioline_info structure in multiple places. Add a separate function that given a gpio_desc sets all relevant fields. Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
2020-02-12gpiolib: emit a debug message when adding events to a full kfifoBartosz Golaszewski
Currently if the line-event kfifo is full, we just silently drop any new events. Add a ratelimited debug message so that we at least have some trace in the kernel log of event overflow. Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>