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

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

2019-05-11T14:54:43+00:00

Pull gpio updates from Linus Walleij: "This is the bulk of the GPIO changes for the v5.2 kernel cycle. A bit later than usual because I was ironing out my own mistakes. I'm holding some stuff back for the next kernel as a result, and this should be a healthy and well tested batch. Core changes: - The gpiolib MMIO driver has been enhanced to handle two direction registers, i.e. one register to set lines as input and one register to set lines as output. It turns out some silicon engineer thinks the ability to configure a line as input and output at the same time makes sense, this can be debated but includes a lot of analog electronics reasoning, and the registers are there and need to be handled consistently. Unsurprisingly, we enforce the lines to be either inputs or outputs in such schemes. - Send in the proper argument value to .set_config() dispatched to the pin control subsystem. Nobody used it before, now someone does, so fix it to work as expected. - The ACPI gpiolib portions can now handle pin bias setting (pull up or pull down). This has been in the ACPI spec for years and we finally have it properly integrated with Linux GPIOs. It was based on an observation from Andy Schevchenko that Thomas Petazzoni's changes to the core for biasing the PCA950x GPIO expander actually happen to fit hand-in-glove with what the ACPI core needed. Such nice synergies happen sometimes. New drivers: - A new driver for the Mellanox BlueField GPIO controller. This is using 64bit MMIO registers and can configure lines as inputs and outputs at the same time and after improving the MMIO library we handle it just fine. Interesting. - A new IXP4xx proper gpiochip driver with hierarchical interrupts should be coming in from the ARM SoC tree as well. Driver enhancements: - The PCA053x driver handles the CAT9554 GPIO expander. - The PCA053x driver handles the NXP PCAL6416 GPIO expander. - Wake-up support on PCA053x GPIO lines. - OMAP now does a nice asynchronous IRQ handling on wake-ups by letting everything wake up on edges, and this makes runtime PM work as expected too. Misc: - Several cleanups such as devres fixes. - Get rid of some languager comstructs that cause problems when compiling with LLVMs clang. - Documentation review and update" * tag 'gpio-v5.2-1' of git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-gpio: (85 commits) gpio: Update documentation docs: gpio: convert docs to ReST and rename to *.rst gpio: sch: Remove write-only core_base gpio: pxa: Make two symbols static gpiolib: acpi: Respect pin bias setting gpiolib: acpi: Add acpi_gpio_update_gpiod_lookup_flags() helper gpiolib: acpi: Set pin value, based on bias, more accurately gpiolib: acpi: Change type of dflags gpiolib: Introduce GPIO_LOOKUP_FLAGS_DEFAULT gpiolib: Make use of enum gpio_lookup_flags consistent gpiolib: Indent entry values of enum gpio_lookup_flags gpio: pca953x: add support for pca6416 dt-bindings: gpio: pca953x: document the nxp,pca6416 gpio: pca953x: add pcal6416 to the of_device_id table gpio: gpio-omap: Remove conditional pm_runtime handling for GPIO interrupts gpio: gpio-omap: configure edge detection for level IRQs for idle wakeup tracing: stop making gpio tracing configurable gpio: pca953x: Configure wake-up path when wake-up is enabled gpio: of: Optimize quirk checks gpio: mmio: Drop bgpio_dir_inverted ...

gpio: mmio: Drop bgpio_dir_inverted

2019-04-08T09:17:43+00:00

The direction inversion semantics are now handled by simply using the registers for in/out available, no need to keep track of inversion semantics exmplicitly anymore. Reviewed-by: Bartosz Golaszewski Reviewed-by: Jan Kotas Signed-off-by: Linus Walleij

gpio: mmio: Support two direction registers

2019-04-04T17:04:13+00:00

It turns out that one specific hardware has two direction registers: one to set a GPIO line as input and another one to set a GPIO line as output. So in theory a line can be configured as input and output at the same time. Make the MMIO GPIO helper deal with this: store both registers in the state container, use both in the generic code if present. Synchronize the input register to the output register when we register a GPIO chip, with the output settings taking precedence. Keep the helper variable to detect inverted direction semantics (only direction in register) but augment the code to be more straight-forward for the generic case when setting the registers. Fix some flunky with unreadable direction registers at the same time as we're touching this code. Cc: David Woods Cc: Shravan Kumar Ramani Signed-off-by: Linus Walleij

gpiolib: export devprop_gpiochip_set_names()

2019-03-24T03:48:02+00:00

This function is needed in mcp23s08. That driver is a special snowflake because it supports several hardware chips as a single "GPIO chip" under Linux. Signed-off-by: Jan Kundrát Cc: Linus Walleij Cc: Phil Reid Acked-by: Mika Westerberg Signed-off-by: Linus Walleij

gpio: add irq domain activate/deactivate functions

2019-01-24T14:33:04+00:00

This adds the two new functions gpiochip_irq_domain_activate and gpiochip_irq_domain_deactivate that can be used as the activate and deactivate functions in the struct irq_domain_ops. This is for situations where only gpiochip_{lock,unlock}_as_irq needs to be called. SPMI and SSBI GPIO are two users that will initially use these functions. Signed-off-by: Brian Masney Suggested-by: Stephen Boyd Reviewed-by: Stephen Boyd Signed-off-by: Linus Walleij

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