user/sven/linux.git/include/linux/gpio/consumer.h, branch v5.3.14

gpio: don't WARN() on NULL descs if gpiolib is disabled

2019-07-28T10:44:14Z

If gpiolib is disabled, we use the inline stubs from gpio/consumer.h instead of regular definitions of GPIO API. The stubs for 'optional' variants of gpiod_get routines return NULL in this case as if the relevant GPIO wasn't found. This is correct so far. Calling other (non-gpio_get) stubs from this header triggers a warning because the GPIO descriptor couldn't have been requested. The warning however is unconditional (WARN_ON(1)) and is emitted even if the passed descriptor pointer is NULL. We don't want to force the users of 'optional' gpio_get to check the returned pointer before calling e.g. gpiod_set_value() so let's only WARN on non-NULL descriptors. Cc: stable@vger.kernel.org Reported-by: Claus H. Stovgaard Signed-off-by: Bartosz Golaszewski

Merge tag 'gpio-v4.21-1' of git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-gpio

2018-12-29T04:00:21Z

Pull GPIO updates from Linus Walleij: "This is the bulk of GPIO changes for the v4.21 kernel series. Core changes: - Some core changes are already in outside of this pull request as they came through the regulator tree, most notably devm_gpiod_unhinge() that removes devres refcount management from a GPIO descriptor. This is needed in subsystems such as regulators where the regulator core need to take over the reference counting and lifecycle management for a GPIO descriptor. - We dropped devm_gpiochip_remove() and devm_gpio_chip_match() as nothing needs it. We can bring it back if need be. - Add a global TODO so people see where we are going. This helps setting the direction now that we are two GPIO maintainers. - Handle the MMC CD/WP properties in the device tree core. (The bulk of patches activating this code is already merged through the MMC/SD tree.) - Augment gpiochip_request_own_desc() to pass a flag so we as gpiochips can request lines as active low or open drain etc even from ourselves. New drivers: - New driver for Cadence GPIO blocks. - New driver for Atmel SAMA5D2 PIOBU GPIO lines. Driver improvements: - A major refactoring of the PCA953x driver - this driver has been around for ages, and is now modernized to reduce code duplication that has stacked up and is using regmap to read write and cache registers. - Intel drivers are now maintained in a separate tree and start with a round of cleanups and unifications" * tag 'gpio-v4.21-1' of git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-gpio: (99 commits) gpio: sama5d2-piobu: Depend on OF_GPIO gpio: Add Cadence GPIO driver dt-bindings: gpio: Add bindings for Cadence GPIO gpiolib-acpi: remove unused variable 'err', cleans up build warning gpio: mxs: read pin level directly instead of using .get gpio: aspeed: remove duplicated statement gpio: add driver for SAMA5D2 PIOBU pins dt-bindings: arm: atmel: describe SECUMOD usage as a GPIO controller gpio/mmc/of: Respect polarity in the device tree dt-bindings: gpio: rcar: Add r8a774c0 (RZ/G2E) support memory: omap-gpmc: Get the header of the enum ARM: omap1: Fix new user of gpiochip_request_own_desc() gpio: pca953x: Add regmap dependency for PCA953x driver gpio: raspberrypi-exp: decrease refcount on firmware dt node gpiolib: Fix return value of gpio_to_desc() stub if !GPIOLIB gpio: pca953x: Restore registers after suspend/resume cycle gpio: pca953x: Zap single use of pca953x_read_single() gpio: pca953x: Zap ad-hoc reg_output cache gpio: pca953x: Zap ad-hoc reg_direction cache gpio: pca953x: Perform basic regmap conversion ...

gpiolib: Fix return value of gpio_to_desc() stub if !GPIOLIB

2018-12-14T15:06:24Z

If CONFIG_GPOILIB is not set, the stub of gpio_to_desc() should return the same type of error as regular version: NULL. All the callers compare the return value of gpio_to_desc() against NULL, so returned ERR_PTR would be treated as non-error case leading to dereferencing of error value. Fixes: 79a9becda894 ("gpiolib: export descriptor-based GPIO interface") Signed-off-by: Krzysztof Kozlowski Signed-off-by: Linus Walleij

gpio: Add devm_gpiod_unhinge()

2018-12-11T01:04:23Z

This adds a function named devm_gpiod_unhinge() that removes the resource management from a GPIO descriptor. I am not sure if this is the best anglosaxon name for the function, no other managed resources have an equivalent currently, but I chose "unhinge" as the closest intuitive thing I could imagine that fits Rusty Russell's API design criterions "the obvious use is the correct one" and "the name tells you how to use it". The idea came out of a remark from Mark Brown that it should be possible to handle over management of a resource from devres to the regulator core, and indeed we can do that. Signed-off-by: Linus Walleij Reviewed-by: Marek Szyprowski Tested-by: Marek Szyprowski Reviewed-by: Charles Keepax Signed-off-by: Mark Brown

gpio: Export gpiod_get_from_of_node()

2018-12-11T01:04:04Z

This function already exist inside gpiolib, we were just reluctant to make it available to the kernel at large as the devm_* seemed to be enough for anyone. However we found out that regulators need to do their own lifecycle/refcounting on GPIO descriptors and explicitly call gpiod_put() when done with a descriptor, so export this function so we can hand the refcounting over to the regulator core for these descriptors after retrieveal. Signed-off-by: Linus Walleij Reviewed-by: Marek Szyprowski Tested-by: Marek Szyprowski Reviewed-by: Charles Keepax Signed-off-by: Mark Brown

gpiolib: Fix possible use after free on label

2018-11-05T07:54:42Z

gpiod_request_commit() copies the pointer to the label passed as an argument only to be used later. But there's a chance the caller could immediately free the passed string(e.g., local variable). This could trigger a use after free when we use gpio label(e.g., gpiochip_unlock_as_irq(), gpiochip_is_requested()). To be on the safe side: duplicate the string with kstrdup_const() so that if an unaware user passes an address to a stack-allocated buffer, we won't get the arbitrary label. Also fix gpiod_set_consumer_name(). Signed-off-by: Muchun Song Signed-off-by: Linus Walleij

Merge tag 'gpio-v4.20-1' of git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-gpio

2018-10-23T07:45:05Z

Pull GPIO updates from Linus Walleij: "This is the bulk of GPIO changes for the v4.20 series: Core changes: - A patch series from Hans Verkuil to make it possible to enable/disable IRQs on a GPIO line at runtime and drive GPIO lines as output without having to put/get them from scratch. The irqchip callbacks have been improved so that they can use only the fastpatch callbacks to enable/disable irqs like any normal irqchip, especially the gpiod_lock_as_irq() has been improved to be callable in fastpath context. A bunch of rework had to be done to achieve this but it is a big win since I never liked to restrict this to slowpath. The only call requireing slowpath was try_module_get() and this is kept at the .request_resources() slowpath callback. In the GPIO CEC driver this is a big win sine a single line is used for both outgoing and incoming traffic, and this needs to use IRQs for incoming traffic while actively driving the line for outgoing traffic. - Janusz Krzysztofik improved the GPIO array API to pass a "cookie" (struct gpio_array) and a bitmap for setting or getting multiple GPIO lines at once. This improvement orginated in a specific need to speed up an OMAP1 driver and has led to a much better API and real performance gains when the state of the array can be used to bypass a lot of checks and code when we want things to go really fast. The previous code would minimize the number of calls down to the driver callbacks assuming the CPU speed was orders of magnitude faster than the I/O latency, but this assumption was wrong on several platforms: what we needed to do was to profile and improve the speed on the hot path of the array functions and this change is now completed. - Clean out the painful and hard to grasp BNF experiments from the device tree bindings. Future approaches are looking into using JSON schema for this purpose. (Rob Herring is floating a patch series.) New drivers: - The RCAR driver now supports r8a774a1 (RZ/G2M). - Synopsys GPIO via CREGs driver. Major improvements: - Modernization of the EP93xx driver to use irqdomain and other contemporary concepts. - The ingenic driver has been merged into the Ingenic pin control driver and removed from the GPIO subsystem. - Debounce support in the ftgpio010 driver" * tag 'gpio-v4.20-1' of git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-gpio: (116 commits) gpio: Clarify kerneldoc on gpiochip_set_chained_irqchip() gpio: Remove unused 'irqchip' argument to gpiochip_set_cascaded_irqchip() gpio: Drop parent irq assignment during cascade setup mmc: pwrseq_simple: Fix incorrect handling of GPIO bitmap gpio: fix SNPS_CREG kconfig dependency warning gpiolib: Initialize gdev field before is used gpio: fix kernel-doc after devres.c file rename gpio: fix doc string for devm_gpiochip_add_data() to not talk about irq_chip gpio: syscon: Fix possible NULL ptr usage gpiolib: Show correct direction from the beginning pinctrl: msm: Use init_valid_mask exported function gpiolib: Add init_valid_mask exported function GPIO: add single-register GPIO via CREG driver dt-bindings: Document the Synopsys GPIO via CREG bindings gpio: mockup: use device properties instead of platform_data gpio: Slightly more helpful debugfs gpio: omap: Remove set but not used variable 'dev' gpio: omap: drop omap_gpio_list Accept partial 'gpio-line-names' property. gpio: omap: get rid of the conditional PM runtime calls ...

regulator/gpio: Allow nonexclusive GPIO access

2018-10-12T16:55:02Z

This allows nonexclusive (simultaneous) access to a single GPIO line for the fixed regulator enable line. This happens when several regulators use the same GPIO for enabling and disabling a regulator, and all need a handle on their GPIO descriptor. This solution with a special flag is not entirely elegant and should ideally be replaced by something more careful as this makes it possible for several consumers to enable/disable the same GPIO line to the left and right without any consistency. The current use inside the regulator core should however be fine as it takes special care to handle this. For the state of the GPIO backend, this is still the lesser evil compared to going back to global GPIO numbers. Cc: Marek Szyprowski Cc: Jon Hunter Fixes: efdfeb079cc3 ("regulator: fixed: Convert to use GPIO descriptor only") Reported-by: Marek Szyprowski Tested-by: Jon Hunter Tested-by: Marek Szyprowski Signed-off-by: Linus Walleij Signed-off-by: Mark Brown

gpio: Restore indentation of continued lines

2018-10-01T10:22:41Z

Fixes: 3027743f83f867d8 ("gpio: Remove VLA from gpiolib") Signed-off-by: Geert Uytterhoeven Signed-off-by: Linus Walleij

gpio: Propagate errors from gpiod_set_array_value_complex()

2018-10-01T10:22:15Z

Internal helper function gpiod_set_array_value_complex() was changed to return an error value, but not all gpiolib callers were updated to propagate the new error up. Fixes: 3027743f83f867d8 ("gpio: Remove VLA from gpiolib") Signed-off-by: Geert Uytterhoeven Signed-off-by: Linus Walleij