aboutsummaryrefslogtreecommitdiff
path: root/drivers/gpio
AgeCommit message (Collapse)AuthorFilesLines
2020-03-27gpio: tegra186: Add Tegra194 pin ranges for GG.0 and GG.1Thierry Reding1-0/+8
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 <[email protected]> Link: https://lore.kernel.org/r/[email protected] Tested-by: Vidya Sagar <[email protected]> Signed-off-by: Linus Walleij <[email protected]>
2020-03-27gpio: tegra186: Add support for pin rangesThierry Reding1-0/+56
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 <[email protected]> Link: https://lore.kernel.org/r/[email protected] Tested-by: Vidya Sagar <[email protected]> Signed-off-by: Linus Walleij <[email protected]>
2020-03-27gpio: Support GPIO controllers without pin-rangesThierry Reding1-1/+4
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 <[email protected]> Link: https://lore.kernel.org/r/[email protected] Tested-by: Vidya Sagar <[email protected]> Signed-off-by: Linus Walleij <[email protected]>
2020-03-26gpio: brcmstb: support gpio-line-names propertyDoug Berger1-0/+44
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 <[email protected]> Link: https://lore.kernel.org/r/[email protected] Acked-by: Gregory Fong <[email protected]> Acked-by: Florian Fainelli <[email protected]> Signed-off-by: Linus Walleij <[email protected]>
2020-03-25gpiolib: gpio_name_to_desc: factor out !name checkMichał Mirosław1-1/+4
Since name == NULL can't ever match, move the check out of IRQ-disabled region. Signed-off-by: Michał Mirosław <[email protected]> Signed-off-by: Bartosz Golaszewski <[email protected]>
2020-03-25gpio: mt7621: add BGPIOF_NO_SET_ON_INPUT flagChuanhong Guo1-2/+2
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 <[email protected]> Tested-by: René van Dorst <[email protected]> Reviewed-by: Sergio Paracuellos <[email protected]> Signed-off-by: Bartosz Golaszewski <[email protected]>
2020-03-25gpio: mmio: introduce BGPIOF_NO_SET_ON_INPUTChuanhong Guo1-4/+19
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 <[email protected]> Tested-by: René van Dorst <[email protected]> Reviewed-by: Sergio Paracuellos <[email protected]> Signed-off-by: Bartosz Golaszewski <[email protected]>
2020-03-25gpio: mvebu: avoid error message for optional IRQChris Packham1-1/+1
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 <[email protected]> Acked-by: Uwe Kleine-König <[email protected]> Signed-off-by: Bartosz Golaszewski <[email protected]>
2020-03-25gpio: mxs: add COMPILE_TEST support for GPIO_MXSAnson Huang1-1/+1
Add COMPILE_TEST support to GPIO_MXS driver for better compile testing coverage. Signed-off-by: Anson Huang <[email protected]> Reported-by: kbuild test robot <[email protected]> Signed-off-by: Bartosz Golaszewski <[email protected]>
2020-03-25gpio: mxc: Add COMPILE_TEST support for GPIO_MXCAnson Huang1-1/+1
Add COMPILE_TEST support to GPIO_MXC driver for better compile testing coverage. Signed-off-by: Anson Huang <[email protected]> Signed-off-by: Bartosz Golaszewski <[email protected]>
2020-03-25gpio: pl061: Warn when IRQ line has not been configuredAlexander Sverdlin1-4/+2
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 <[email protected]> Signed-off-by: Bartosz Golaszewski <[email protected]>
2020-03-24gpiolib: acpi: Add quirk to ignore EC wakeups on HP x2 10 CHT + AXP288 modelHans de Goede1-0/+15
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 <[email protected]> Signed-off-by: Hans de Goede <[email protected]> Link: https://lore.kernel.org/r/[email protected] Acked-by: Mika Westerberg <[email protected]> Signed-off-by: Linus Walleij <[email protected]>
2020-03-20gpio: Move devres calls to devres fileLinus Walleij2-46/+46
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/[email protected] Reviewed-by: Bartosz Golaszewski <[email protected]> Signed-off-by: Linus Walleij <[email protected]>
2020-03-11gpiolib: acpi: Add quirk to ignore EC wakeups on HP x2 10 BYT + AXP288 modelHans de Goede1-0/+15
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 <[email protected]> Link: https://lore.kernel.org/r/[email protected] Acked-by: Mika Westerberg <[email protected]> Signed-off-by: Linus Walleij <[email protected]>
2020-03-11gpiolib: acpi: Rework honor_wakeup option into an ignore_wake optionHans de Goede1-20/+76
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 <[email protected]> Link: https://lore.kernel.org/r/[email protected] Acked-by: Mika Westerberg <[email protected]> Reviewed-by: Andy Shevchenko <[email protected]> Signed-off-by: Linus Walleij <[email protected]>
2020-03-11gpiolib: acpi: Correct comment for HP x2 10 honor_wakeup quirkHans de Goede1-6/+8
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 <[email protected]> Link: https://lore.kernel.org/r/[email protected] Acked-by: Mika Westerberg <[email protected]> Signed-off-by: Linus Walleij <[email protected]>
2020-03-11gpiolib: Fix irq_disable() semanticsLinus Walleij1-1/+8
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 <[email protected]> Cc: Hans Verkuil <[email protected]> Cc: [email protected] Reviewed-by: Bartosz Golaszewski <[email protected]> Fixes: 461c1a7d4733 ("gpiolib: override irq_enable/disable") Signed-off-by: Linus Walleij <[email protected]> Link: https://lore.kernel.org/r/[email protected]
2020-03-09Merge branch 'ib-omap-block-idle' into develLinus Walleij1-15/+14
2020-03-09Revert "gpio: omap: Fix lost edge wake-up interrupts"Tony Lindgren1-11/+1
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 <[email protected]> Cc: Grygorii Strashko <[email protected]> Cc: Keerthy <[email protected]> Cc: Ladislav Michl <[email protected]> Cc: Peter Ujfalusi <[email protected]> Cc: Russell King <[email protected]> Cc: Tero Kristo <[email protected]> Signed-off-by: Tony Lindgren <[email protected]> Signed-off-by: Linus Walleij <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Linus Walleij <[email protected]>
2020-03-09gpio: omap: Block idle on pending gpio interruptsTony Lindgren1-4/+13
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 <[email protected]> Cc: Grygorii Strashko <[email protected]> Cc: Keerthy <[email protected]> Cc: Ladislav Michl <[email protected]> Cc: Russell King <[email protected]> Cc: Tero Kristo <[email protected]> Signed-off-by: Tony Lindgren <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Linus Walleij <[email protected]>
2020-03-09gpio: add driver for Mellanox BlueField 2 GPIO controllerAsmaa Mnebhi3-0/+343
This patch adds support for the GPIO controller used by Mellanox BlueField 2 SOCs. Signed-off-by: Asmaa Mnebhi <[email protected]> Link: https://lore.kernel.org/r/1680de9eb6d2b8855228dde9a2dd065f0dcbe1fb.1583182325.git.Asmaa@mellanox.com Signed-off-by: Linus Walleij <[email protected]>
2020-03-03Merge tag 'gpio-updates-for-v5.7-part2' of ↵Linus Walleij2-10/+10
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 Uytterhoeven1-1/+1
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 <[email protected]> Link: https://lore.kernel.org/r/[email protected] Acked-by: Andy Shevchenko <[email protected]> Signed-off-by: Linus Walleij <[email protected]>
2020-03-02gpiolib: fix bitmap operations related to line event watchingBartosz Golaszewski1-3/+3
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 <[email protected]> Signed-off-by: Bartosz Golaszewski <[email protected]> Tested-by: Kent Gibson <[email protected]>
2020-03-02gpiolib: fix unwatch ioctl()Kent Gibson1-1/+1
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 <[email protected]> Signed-off-by: Bartosz Golaszewski <[email protected]>
2020-03-02gpiolib: Rename 'event' to 'ge' to be consistent with other useAndy Shevchenko1-6/+6
Rename 'event' to 'ge' to be consistent with other use. Signed-off-by: Andy Shevchenko <[email protected]> Signed-off-by: Bartosz Golaszewski <[email protected]>
2020-03-02gpio: uniphier: Replace zero-length array with flexible-array memberGustavo A. R. Silva1-1/+1
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 <[email protected]> Signed-off-by: Bartosz Golaszewski <[email protected]>
2020-02-28gpiolib: Optimize gpiochip_remove() when check for requested lineAndy Shevchenko1-7/+4
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 <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Linus Walleij <[email protected]>
2020-02-25gpiolib: export gpiochip_get_descMarco Felsch1-0/+1
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 <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Linus Walleij <[email protected]>
2020-02-21gpio: of: Add DT overlay support for GPIO hogsGeert Uytterhoeven4-3/+106
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 <[email protected]> Link: https://lore.kernel.org/r/[email protected] Reviewed-by: Frank Rowand <[email protected]> Signed-off-by: Linus Walleij <[email protected]>
2020-02-21gpio: of: Extract of_gpiochip_add_hog()Geert Uytterhoeven1-16/+33
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 <[email protected]> Link: https://lore.kernel.org/r/[email protected] Reviewed-by: Frank Rowand <[email protected]> Signed-off-by: Linus Walleij <[email protected]>
2020-02-21gpio: Switch timestamps to ktime_get_ns()Linus Walleij1-2/+2
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 <[email protected]> Acked-by: Bartosz Golaszewski <[email protected]> Signed-off-by: Linus Walleij <[email protected]>
2020-02-21gpiolib: use gpiochip_get_desc() where applicableBartosz Golaszewski1-1/+3
Whenever retrieving a descriptor from a gpiochip: use the provided helper which checks for errors. Signed-off-by: Bartosz Golaszewski <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Linus Walleij <[email protected]>
2020-02-21gpio: siox: use raw spinlock for irq related lockingUwe Kleine-König1-14/+14
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 <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Linus Walleij <[email protected]>
2020-02-20gpio: mockup: coding-style fixBartosz Golaszewski1-1/+1
The indentation is wrong in gpio_mockup_apply_pull(). This patch makes the code more readable. Signed-off-by: Bartosz Golaszewski <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Linus Walleij <[email protected]>
2020-02-20gpio: rcar: Fix typo in commentAshish Chavan1-2/+2
"Positive" is spelled incorrectly as "Postive" in comment fix this. Signed-off-by: Ashish Chavan <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Linus Walleij <[email protected]>
2020-02-12gpiolib: add new ioctl() for monitoring changes in line infoBartosz Golaszewski2-8/+179
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 <[email protected]> Reviewed-by: Linus Walleij <[email protected]>
2020-02-12gpiolib: provide a dedicated function for setting lineinfoBartosz Golaszewski1-43/+55
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 <[email protected]> Reviewed-by: Andy Shevchenko <[email protected]>
2020-02-12gpiolib: emit a debug message when adding events to a full kfifoBartosz Golaszewski1-0/+2
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 <[email protected]>
2020-02-12gpiolib: rework the locking mechanism for lineevent kfifoBartosz Golaszewski1-29/+35
The read_lock mutex is supposed to prevent collisions between reading and writing to the line event kfifo but it's actually only taken when the events are being read from it. Drop the mutex entirely and reuse the spinlock made available to us in the waitqueue struct. Take the lock whenever the fifo is modified or inspected. Drop the call to kfifo_to_user() and instead first extract the new element from kfifo when the lock is taken and only then pass it on to the user after the spinlock is released. Signed-off-by: Bartosz Golaszewski <[email protected]> Reviewed-by: Andy Shevchenko <[email protected]>
2020-02-10gpio: sifive: fix static checker warningYash Shah1-3/+3
Typcasting "irq_state" leads to the below static checker warning: The fix is to declare "irq_state" as unsigned long instead of u32. drivers/gpio/gpio-sifive.c:97 sifive_gpio_irq_enable() warn: passing casted pointer '&chip->irq_state' to 'assign_bit()' 32 vs 64. Fixes: 96868dce644d ("gpio/sifive: Add GPIO driver for SiFive SoCs") Reported-by: Dan Carpenter <[email protected]> Signed-off-by: Yash Shah <[email protected]> Link: https://lore.kernel.org/r/[email protected] Reviewed-by: Marc Zyngier <[email protected]> Signed-off-by: Linus Walleij <[email protected]>
2020-02-10gpio: xilinx: Fix bug where the wrong GPIO register is written toPaul Thomas1-2/+3
Care is taken with "index", however with the current version the actual xgpio_writereg is using index for data but xgpio_regoffset(chip, i) for the offset. And since i is already incremented it is incorrect. This patch fixes it so that index is used for the offset too. Cc: [email protected] Signed-off-by: Paul Thomas <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Linus Walleij <[email protected]>
2020-02-10gpiolib: remove unnecessary argument from set_config callKent Gibson1-1/+0
Remove unnecessary argument when setting PIN_CONFIG_BIAS_DISABLE. No argument is expected by pinctrl, so removing it should be harmless. Fixes: 2148ad7790ea ("gpiolib: add support for disabling line bias") Signed-off-by: Kent Gibson <[email protected]> Signed-off-by: Bartosz Golaszewski <[email protected]>
2020-02-10gpio: bd71828: Remove unneeded defines for GPIO_LINE_DIRECTION_IN/OUTAxel Lin1-10/+0
They are defined in gpio/driver.h now. Signed-off-by: Axel Lin <[email protected]> Signed-off-by: Bartosz Golaszewski <[email protected]>
2020-02-10gpiolib: fix gpio_do_set_config()Bartosz Golaszewski1-3/+3
Commit d90f36851d65 ("gpiolib: have a single place of calling set_config()") introduced a regression where we don't pass the right variable as argument to the set_config() callback of gpio driver from gpio_set_config(). After reverting two additional patches that came on top of it - this addresses the issue by changing the type of the last argument of gpio_do_set_config() to unsigned long and making sure the packed config variable is actually used in gpio_set_config(). Fixes: d90f36851d65 ("gpiolib: have a single place of calling set_config()") Signed-off-by: Bartosz Golaszewski <[email protected]> Tested-by: Guenter Roeck <[email protected]>
2020-02-10Revert "gpiolib: remove set but not used variable 'config'"Bartosz Golaszewski1-0/+2
This reverts commit e5e42ad224a040f93bf112e96f82b3a0ed97ffab. This patch came on top of another patch that introduced a regression. Revert it before addressing the culprit. Signed-off-by: Bartosz Golaszewski <[email protected]> Tested-by: Guenter Roeck <[email protected]>
2020-02-10Revert "gpiolib: Remove duplicated function gpio_do_set_config()"Bartosz Golaszewski1-4/+23
This reverts commit d18fddff061d2796525e6d4a958cb3d30aed8efd. This patch came on top of another patch that introduced a regression. Revert it before addressing the culprit. Signed-off-by: Bartosz Golaszewski <[email protected]> Tested-by: Guenter Roeck <[email protected]>
2020-02-10gpio: wcd934x: Fix logic of wcd_gpio_getAxel Lin1-2/+2
The check with register value and mask should be & rather than &&. While at it, also use "unsigned int" for value variable because regmap_read() takes unsigned int *val argument. Signed-off-by: Axel Lin <[email protected]> Reviewed-by: Srinivas Kandagatla <[email protected]> Signed-off-by: Bartosz Golaszewski <[email protected]>
2020-02-10gpio: wcd934x: Don't change gpio direction in wcd_gpio_setAxel Lin1-1/+4
The .set callback should just set output value. Signed-off-by: Axel Lin <[email protected]> Reviewed-by: Srinivas Kandagatla <[email protected]> Signed-off-by: Bartosz Golaszewski <[email protected]>
2020-02-10gpio: pxa: Avoid a warning when gpio0 and gpio1 IRQS are not thereLubomir Rintel1-2/+2
Not all platforms use those. Let's use platform_get_irq_byname_optional() instead platform_get_irq_byname() so that we avoid a useless warning: [ 1.359455] pxa-gpio d4019000.gpio: IRQ gpio0 not found [ 1.359583] pxa-gpio d4019000.gpio: IRQ gpio1 not found Signed-off-by: Lubomir Rintel <[email protected]> Signed-off-by: Bartosz Golaszewski <[email protected]>
Powered by cgit, Gruvboxed by Blaster4385.