kernel/linux.git/include/linux/gpio/driver.h, branch v5.0.3

gpio: Pass a flag to gpiochip_request_own_desc()

2018-12-14T13:24:33+00:00

Before things go out of hand, make it possible to pass flags when requesting "own" descriptors from a gpio_chip. This is necessary if the chip wants to request a GPIO with active low semantics, for example. Cc: Janusz Krzysztofik Cc: Thomas Petazzoni Cc: Jason Cooper Cc: Jiri Kosina Cc: Roger Quadros Reviewed-by: Gregory CLEMENT Signed-off-by: Linus Walleij

gpio: drop broken to_gpio_irq_chip() helper

2018-11-16T21:46:02+00:00

Drop the broken to_gpio_irq_chip() container_of() helper, which would break the build for anyone who tries to use it. Specifically, struct gpio_irq_chip only holds a pointer to a struct irq_chip so using container_of() on an irq-chip pointer makes no sense. Fixes: da80ff81a8f5 ("gpio: Move irqchip into struct gpio_irq_chip") Cc: Thierry Reding Cc: Grygorii Strashko Signed-off-by: Johan Hovold Reviewed-by: Bartosz Golaszewski Signed-off-by: Linus Walleij

gpio: drop devm_gpiochip_remove()

2018-11-05T07:54:42+00:00

There is hardly any reason to call devm_gpiochip_remove() because the driver core handles calling gpiochip_remove() automatically. To make it harder to introduce new (and probably unneeded) callers, drop the function. Signed-off-by: Uwe Kleine-König 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:05+00:00

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 ...

gpio: Assign gpio_irq_chip::parents to non-stack pointer

2018-10-10T12:03:27+00:00

gpiochip_set_cascaded_irqchip() is passed 'parent_irq' as an argument and then the address of that argument is assigned to the gpio chips gpio_irq_chip 'parents' pointer shortly thereafter. This can't ever work, because we've just assigned some stack address to a pointer that we plan to dereference later in gpiochip_irq_map(). I ran into this issue with the KASAN report below when gpiochip_irq_map() tried to setup the parent irq with a total junk pointer for the 'parents' array. BUG: KASAN: stack-out-of-bounds in gpiochip_irq_map+0x228/0x248 Read of size 4 at addr ffffffc0dde472e0 by task swapper/0/1 CPU: 7 PID: 1 Comm: swapper/0 Not tainted 4.14.72 #34 Call trace: [] dump_backtrace+0x0/0x718 [] show_stack+0x20/0x2c [] __dump_stack+0x20/0x28 [] dump_stack+0x80/0xbc [] print_address_description+0x70/0x238 [] kasan_report+0x1cc/0x260 [] __asan_report_load4_noabort+0x2c/0x38 [] gpiochip_irq_map+0x228/0x248 [] irq_domain_associate+0x114/0x2ec [] irq_create_mapping+0x120/0x234 [] irq_create_fwspec_mapping+0x4c8/0x88c [] irq_create_of_mapping+0x180/0x210 [] of_irq_get+0x138/0x198 [] spi_drv_probe+0x94/0x178 [] driver_probe_device+0x51c/0x824 [] __device_attach_driver+0x148/0x20c [] bus_for_each_drv+0x120/0x188 [] __device_attach+0x19c/0x2dc [] device_initial_probe+0x20/0x2c [] bus_probe_device+0x80/0x154 [] device_add+0x9b8/0xbdc [] spi_add_device+0x1b8/0x380 [] spi_register_controller+0x111c/0x1378 [] spi_geni_probe+0x4dc/0x6f8 [] platform_drv_probe+0xdc/0x130 [] driver_probe_device+0x51c/0x824 [] __driver_attach+0x100/0x194 [] bus_for_each_dev+0x104/0x16c [] driver_attach+0x48/0x54 [] bus_add_driver+0x274/0x498 [] driver_register+0x1ac/0x230 [] __platform_driver_register+0xcc/0xdc [] spi_geni_driver_init+0x1c/0x24 [] do_one_initcall+0x240/0x3dc [] kernel_init_freeable+0x378/0x468 [] kernel_init+0x14/0x110 [] ret_from_fork+0x10/0x18 The buggy address belongs to the page: page:ffffffbf037791c0 count:0 mapcount:0 mapping: (null) index:0x0 flags: 0x4000000000000000() raw: 4000000000000000 0000000000000000 0000000000000000 00000000ffffffff raw: ffffffbf037791e0 ffffffbf037791e0 0000000000000000 0000000000000000 page dumped because: kasan: bad access detected Memory state around the buggy address: ffffffc0dde47180: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ffffffc0dde47200: f1 f1 f1 f1 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f2 f2 >ffffffc0dde47280: f2 f2 00 00 00 00 00 00 00 00 00 00 f3 f3 f3 f3 ^ ffffffc0dde47300: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ffffffc0dde47380: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 Let's leave around one unsigned int in the gpio_irq_chip struct for the single parent irq case and repoint the 'parents' array at it. This way code is left mostly intact to setup parents and we waste an extra few bytes per structure of which there should be only a handful in a system. Cc: Evan Green Cc: Thierry Reding Cc: Grygorii Strashko Fixes: e0d897289813 ("gpio: Implement tighter IRQ chip integration") Signed-off-by: Stephen Boyd Signed-off-by: Linus Walleij

gpiolib: Add init_valid_mask exported function

2018-10-10T08:31:40+00:00

Add a function that allows initializing the valid_mask from gpiochip_add_data. This prevents race conditions during gpiochip initialization. If the function is not exported, then the old behaviour is respected, this is, set all gpios as valid. Signed-off-by: Ricardo Ribalda Delgado Tested-by: Jeffrey Hugo Signed-off-by: Linus Walleij

gpio: Add comments on single direction chips

2018-09-25T07:54:14+00:00

A patch from Ricardo got me thinking about some gpio chip semantics so let's drop in some comments to make things more clear around that. Cc: Ricardo Ribalda Delgado Cc: Bartosz Golaszewski Signed-off-by: Linus Walleij

gpiolib: override irq_enable/disable

2018-09-10T06:56:38+00:00

When using the gpiolib irqchip helpers install irq_enable/disable hooks for the irqchip to ensure that gpiolib knows when the irq is enabled or disabled, allowing drivers to disable the irq and then use it as an output pin, and later switch the direction to input and re-enable the irq. Signed-off-by: Hans Verkuil Signed-off-by: Linus Walleij

gpiolib: add flag to indicate if the irq is disabled

2018-09-10T06:56:11+00:00

GPIO drivers call gpiochip_(un)lock_as_irq whenever they want to use a gpio as an interrupt. This is done when the irq is requested and it marks the gpio as in use by an interrupt. This is problematic for cases where a gpio pin is used as an interrupt pin, then, after the irq is disabled, is used as a regular gpio pin. Currently it is not possible to do this other than by first freeing the interrupt so gpiochip_unlock_as_irq is called, since an attempt to switch the gpio direction for output will fail since gpiolib believes that the gpio is in use for an interrupt and it does not know that it the irq is actually disabled. There are currently two drivers that would like to be able to do this: the tda998x_drv.c driver where a regular gpio pin needs to be temporarily reconfigured as an interrupt pin during CEC calibration, and the cec-gpio driver where you want to configure the gpio pin as an interrupt while waiting for traffic over the CEC bus, or as a regular pin when receiving or transmitting a CEC message. The solution is to add a new flag that is set when the irq is enabled, and have gpiod_direction_output check for that flag. We also add functions that drivers that do not use GPIOLIB_IRQCHIP can call when they enable/disable the irq. Signed-off-by: Hans Verkuil Signed-off-by: Linus Walleij

gpiolib: export gpiochip_irq_reqres/relres()

2018-09-10T06:54:57+00:00

GPIO drivers that do not use GPIOLIB_IRQCHIP can hook these into the irq_request_resource and irq_release_resource callbacks of the irq_chip so they correctly 'get' the module and lock the gpio line for IRQ use. This will simplify driver code. Signed-off-by: Hans Verkuil Signed-off-by: Linus Walleij