summaryrefslogtreecommitdiffstats
path: root/drivers/gpio/gpio-104-idio-16.c (follow)
Commit message (Collapse)AuthorAgeFilesLines
* gpio: 104-idio-16: Use irqchip templateLinus Walleij2020-07-231-11/+22
| | | | | | | | | | | | | | | This makes the driver use the irqchip template to assign properties to the gpio_irq_chip instead of using the explicit call to gpiochip_irqchip_add(). The irqchip is instead added while adding the gpiochip. Also move the IRQ initialization to the special .init_hw() callback. Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Acked-by: William Breathitt Gray <vilhelm.gray@gmail.com> Cc: William Breathitt Gray <vilhelm.gray@gmail.com> Link: https://lore.kernel.org/r/20200722105517.186137-1-linus.walleij@linaro.org
* gpio: Use new GPIO_LINE_DIRECTIONMatti Vaittinen2019-11-071-2/+2
| | | | | | | | | | | | | | | | | | | | | It's hard for occasional GPIO code reader/writer to know if values 0/1 equal to IN or OUT. Use defined GPIO_LINE_DIRECTION_IN and GPIO_LINE_DIRECTION_OUT to help them out. NOTE - for gpio-amd-fch and gpio-bd9571mwv: This commit also changes the return value for direction get to equal 1 for direction INPUT. Prior this commit these drivers might have returned some other positive value but 1 for INPUT. Signed-off-by: Matti Vaittinen <matti.vaittinen@fi.rohmeurope.com> Acked-by: Scott Branden <scott.branden@broadcom.com> Reviewed-by: Grygorii Strashko <grygorii.strashko@ti.com> Reviewed-by: Michal Simek <michal.simek@xilinx.com> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be> Acked-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Acked-by: William Breathitt Gray <vilhelm.gray@gmail.com> Acked-by: Kuppuswamy Sathyanarayanan <sathyanarayanan.kuppuswamy@linux.intel.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
* treewide: Replace GPLv2 boilerplate/reference with SPDX - rule 174Thomas Gleixner2019-05-301-9/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | Based on 1 normalized pattern(s): this program is free software you can redistribute it and or modify it under the terms of the gnu general public license version 2 as published by the free software foundation this program is distributed in the hope that it will be useful but without any warranty without even the implied warranty of merchantability or fitness for a particular purpose see the gnu general public license for more details extracted by the scancode license scanner the SPDX license identifier GPL-2.0-only has been chosen to replace the boilerplate/reference in 655 file(s). Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Reviewed-by: Allison Randal <allison@lohutok.net> Reviewed-by: Kate Stewart <kstewart@linuxfoundation.org> Reviewed-by: Richard Fontana <rfontana@redhat.com> Cc: linux-spdx@vger.kernel.org Link: https://lkml.kernel.org/r/20190527070034.575739538@linutronix.de Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* gpio: 104-idio-16: Implement get_multiple callbackWilliam Breathitt Gray2018-03-261-0/+15
| | | | | | | | | | | | | The ACCES I/O 104-IDIO-16 series of devices provides 16 optically-isolated digital inputs accessed via two 8-bit ports. Since eight input lines are acquired on a single port input read, the 104-IDIO-16 GPIO driver may improve multiple input reads by utilizing a get_multiple callback. This patch implements the idio_16_gpio_get_multiple function which serves as the respective get_multiple callback. Signed-off-by: William Breathitt Gray <vilhelm.gray@gmail.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
* gpio: Move irqdomain into struct gpio_irq_chipThierry Reding2017-11-081-1/+1
| | | | | | | | | In order to consolidate the multiple ways to associate an IRQ chip with a GPIO chip, move more fields into the new struct gpio_irq_chip. Signed-off-by: Thierry Reding <treding@nvidia.com> Acked-by: Grygorii Strashko <grygorii.strashko@ti.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
* Merge tag 'hwparam-20170420' of ↵Linus Torvalds2017-05-111-2/+2
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/dhowells/linux-fs Pull hw lockdown support from David Howells: "Annotation of module parameters that configure hardware resources including ioports, iomem addresses, irq lines and dma channels. This allows a future patch to prohibit the use of such module parameters to prevent that hardware from being abused to gain access to the running kernel image as part of locking the kernel down under UEFI secure boot conditions. Annotations are made by changing: module_param(n, t, p) module_param_named(n, v, t, p) module_param_array(n, t, m, p) to: module_param_hw(n, t, hwtype, p) module_param_hw_named(n, v, t, hwtype, p) module_param_hw_array(n, t, hwtype, m, p) where the module parameter refers to a hardware setting hwtype specifies the type of the resource being configured. This can be one of: ioport Module parameter configures an I/O port iomem Module parameter configures an I/O mem address ioport_or_iomem Module parameter could be either (runtime set) irq Module parameter configures an I/O port dma Module parameter configures a DMA channel dma_addr Module parameter configures a DMA buffer address other Module parameter configures some other value Note that the hwtype is compile checked, but not currently stored (the lockdown code probably won't require it). It is, however, there for future use. A bonus is that the hwtype can also be used for grepping. The intention is for the kernel to ignore or reject attempts to set annotated module parameters if lockdown is enabled. This applies to options passed on the boot command line, passed to insmod/modprobe or direct twiddling in /sys/module/ parameter files. The module initialisation then needs to handle the parameter not being set, by (1) giving an error, (2) probing for a value or (3) using a reasonable default. What I can't do is just reject a module out of hand because it may take a hardware setting in the module parameters. Some important modules, some ipmi stuff for instance, both probe for hardware and allow hardware to be manually specified; if the driver is aborts with any error, you don't get any ipmi hardware. Further, trying to do this entirely in the module initialisation code doesn't protect against sysfs twiddling. [!] Note that in and of itself, this series of patches should have no effect on the the size of the kernel or code execution - that is left to a patch in the next series to effect. It does mark annotated kernel parameters with a KERNEL_PARAM_FL_HWPARAM flag in an already existing field" * tag 'hwparam-20170420' of git://git.kernel.org/pub/scm/linux/kernel/git/dhowells/linux-fs: (38 commits) Annotate hardware config module parameters in sound/pci/ Annotate hardware config module parameters in sound/oss/ Annotate hardware config module parameters in sound/isa/ Annotate hardware config module parameters in sound/drivers/ Annotate hardware config module parameters in fs/pstore/ Annotate hardware config module parameters in drivers/watchdog/ Annotate hardware config module parameters in drivers/video/ Annotate hardware config module parameters in drivers/tty/ Annotate hardware config module parameters in drivers/staging/vme/ Annotate hardware config module parameters in drivers/staging/speakup/ Annotate hardware config module parameters in drivers/staging/media/ Annotate hardware config module parameters in drivers/scsi/ Annotate hardware config module parameters in drivers/pcmcia/ Annotate hardware config module parameters in drivers/pci/hotplug/ Annotate hardware config module parameters in drivers/parport/ Annotate hardware config module parameters in drivers/net/wireless/ Annotate hardware config module parameters in drivers/net/wan/ Annotate hardware config module parameters in drivers/net/irda/ Annotate hardware config module parameters in drivers/net/hamradio/ Annotate hardware config module parameters in drivers/net/ethernet/ ...
| * Annotate hardware config module parameters in drivers/gpio/David Howells2017-04-201-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When the kernel is running in secure boot mode, we lock down the kernel to prevent userspace from modifying the running kernel image. Whilst this includes prohibiting access to things like /dev/mem, it must also prevent access by means of configuring driver modules in such a way as to cause a device to access or modify the kernel image. To this end, annotate module_param* statements that refer to hardware configuration and indicate for future reference what type of parameter they specify. The parameter parser in the core sees this information and can skip such parameters with an error message if the kernel is locked down. The module initialisation then runs as normal, but just sees whatever the default values for those parameters is. Note that we do still need to do the module initialisation because some drivers have viable defaults set in case parameters aren't specified and some drivers support automatic configuration (e.g. PNP or PCI) in addition to manually coded parameters. This patch annotates drivers in drivers/gpio/. Suggested-by: Alan Cox <gnomes@lxorguk.ukuu.org.uk> Signed-off-by: David Howells <dhowells@redhat.com> Acked-by: William Breathitt Gray <vilhelm.gray@gmail.com> Acked-by: Linus Walleij <linus.walleij@linaro.org> cc: Alexandre Courbot <gnurou@gmail.com> cc: linux-gpio@vger.kernel.org
* | gpio: 104-idio-16: make use of raw_spinlock variantsJulia Cartwright2017-03-281-12/+12
|/ | | | | | | | | | | | | | | The 104-idio-16 gpio driver currently implements an irq_chip for handling interrupts; due to how irq_chip handling is done, it's necessary for the irq_chip methods to be invoked from hardirq context, even on a a real-time kernel. Because the spinlock_t type becomes a "sleeping" spinlock w/ RT kernels, it is not suitable to be used with irq_chips. A quick audit of the operations under the lock reveal that they do only minimal, bounded work, and are therefore safe to do under a raw spinlock. Signed-off-by: Julia Cartwright <julia@ni.com> Acked-by: William Breathitt Gray <vilhelm.gray@gmail.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
* gpio: 104-idio-16: Add support for GPIO namesWilliam Breathitt Gray2017-02-011-1/+10
| | | | | | | | | | This patch sets the gpio_chip names option with an array of GPIO line names that match the manual documentation for the ACCES 104-IDIO-16. This should make it easier for users to identify which GPIO line corresponds to a respective GPIO pin on the device. Signed-off-by: William Breathitt Gray <vilhelm.gray@gmail.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
* gpio: 104-idio-16: Remove unnecessary driver_data setWilliam Breathitt Gray2017-02-011-2/+0
| | | | | | | | | Setting driver_data was necessary to access private data in the idio_16_remove function. Now that the idio_16_remove function is gone, driver_data is no longer used. This patch removes the relevant code. Signed-off-by: William Breathitt Gray <vilhelm.gray@gmail.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
* gpio: 104-idio-16: Utilize devm_ functions in driver probe callbackWilliam Breathitt Gray2017-01-261-22/+5
| | | | | | | | | | | | | The devm_ resource manager functions allow memory to be automatically released when a device is unbound. This patch takes advantage of the resource manager functions and replaces the gpiochip_add_data call and request_irq call with the devm_gpiochip_add_data call and devm_request_irq call respectively. In addition, the idio_16_remove function has been removed as no longer necessary due to the use of the relevant devm_ resource manager functions. Signed-off-by: William Breathitt Gray <vilhelm.gray@gmail.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
* gpio: 104-idio-16: Add set_multiple callback function supportWilliam Breathitt Gray2017-01-261-0/+20
| | | | | | | | | | The ACCES 104-IDIO-16 series provides registers where 8 lines of GPIO may be set at a time. This patch add support for the set_multiple callback function, thus allowing multiple GPIO output lines to be set more efficiently in groups. Signed-off-by: William Breathitt Gray <vilhelm.gray@gmail.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
* gpio: 104-idio-16: Utilize the ISA bus driverWilliam Breathitt Gray2016-05-021-57/+28
| | | | | | | | | | | | | | | | The ACCES 104-IDIO-16 series communicates via the ISA bus. As such, it is more appropriate to use the ISA bus driver over the platform driver to control the ACCES 104-IDIO-16 GPIO driver. This patch also adds support for multiple devices via the base and irq module array parameters. Each element of the base array corresponds to a discrete device; each element of the irq array corresponds to the respective device addressed in the respective base array element. Acked-by: Linus Walleij <linus.walleij@linaro.org> Cc: Alexandre Courbot <gnurou@gmail.com> Signed-off-by: William Breathitt Gray <vilhelm.gray@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* gpio: 104-idio-16: Use devm_request_regionWilliam Breathitt Gray2016-02-161-17/+8
| | | | | | | | | | | By the time request_region is called in the ACCES 104-IDIO-16 GPIO driver, a corresponding device structure has already been allocated. The devm_request_region function should be used to help simplify the cleanup code and reduce the possible points of failure. Signed-off-by: William Breathitt Gray <vilhelm.gray@gmail.com> Reviewed-by: Alexandre Courbot <acourbot@nvidia.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
* gpio: misc: Pass correct license string to MODULE_LICENSEWilliam Breathitt Gray2016-02-161-1/+1
| | | | | | | | | The GPIO driver copyright boilerplate lacks the "or later" verbiage regarding GPL compliant distribution. The MODULE_LICENSE string should reflect the actual copyright license terms used. Signed-off-by: William Breathitt Gray <vilhelm.gray@gmail.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
* gpio: 104-idio-16: use gpiochip data pointerLinus Walleij2016-01-051-10/+5
| | | | | | | | | This makes the driver use the data pointer added to the gpio_chip to store a pointer to the state container instead of relying on container_of(). Acked-by: William Breathitt Gray <vilhelm.gray@gmail.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
* gpio: 104-idio-16: Clear pending interrupt in IRQ handlerWilliam Breathitt Gray2015-12-101-10/+7
| | | | | | | | | | | | | | | | The ACCES 104-IDIO-16 uses a single interrupt to indicate a possible change-of-state in any of the digital input lines. As such, only a single write to the device's "Clear Interrupt" register is necessary to acknowledge the IRQ for all respective GPIO. This patch moves the "Clear Interrupt" register write operation from the irq_ack callback to the IRQ handler function, wherefore each interrupt may be cleared respectively by executing a single outb call at the end of the idio_16_irq_handler function, rather than multiple redundant outb calls as a result of the generic_handle_irq call for each masked GPIO. Signed-off-by: William Breathitt Gray <vilhelm.gray@gmail.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
* gpio: 104-idio-16: Disable IRQ on device probeWilliam Breathitt Gray2015-11-301-0/+3
| | | | | | | | | | IRQ should be disabled on device probe so that the device IRQ is in a known starting state. If IRQ is not disabled, interrupts may be reported as handled by the IRQ handler, despite no irq_unmask calls made by the user. Signed-off-by: William Breathitt Gray <vilhelm.gray@gmail.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
* gpio: 104-idio-16: Use lowercase symbol names for const variablesWilliam Breathitt Gray2015-11-191-19/+18
| | | | | | | | | | To prevent confusion, and to match the existing coding style used in other GPIO drivers, symbol names within the 104-idio-16 GPIO driver should be lowercase. Signed-off-by: William Breathitt Gray <vilhelm.gray@gmail.com> Reviewed-by: Alexandre Courbot <acourbot@nvidia.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
* gpio: Add IRQ support to ACCES 104-IDIO-16 driverWilliam Breathitt Gray2015-11-191-1/+111
| | | | | | | | | | | | | The ACCES 104-IDIO-16 series offers Change-of-State detection interrupt functionality; if Change-of-State detection is enabled, an interrupt is fired off if any input line changes state (i.e. goes from low to high, or from high to low). This patch adds support to handle these interrupts and allows the user to mask which GPIO lines are affected. The interrupt line number for the device may be set via the idio_16_irq module parameter. Signed-off-by: William Breathitt Gray <vilhelm.gray@gmail.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
* gpio: change member .dev to .parentLinus Walleij2015-11-191-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The name .dev in a struct is normally reserved for a struct device that is let us say a superclass to the thing described by the struct. struct gpio_chip stands out by confusingly using a struct device *dev to point to the parent device (such as a platform_device) that represents the hardware. As we want to give gpio_chip:s real devices, this is not working. We need to rename this member to parent. This was done by two coccinelle scripts, I guess it is possible to combine them into one, but I don't know such stuff. They look like this: @@ struct gpio_chip *var; @@ -var->dev +var->parent and: @@ struct gpio_chip var; @@ -var.dev +var.parent and: @@ struct bgpio_chip *var; @@ -var->gc.dev +var->gc.parent Plus a few instances of bgpio that I couldn't figure out how to teach Coccinelle to rewrite. This patch hits all over the place, but I *strongly* prefer this solution to any piecemal approaches that just exercise patch mechanics all over the place. It mainly hits drivers/gpio and drivers/pinctrl which is my own backyard anyway. Cc: Haavard Skinnemoen <hskinnemoen@gmail.com> Cc: Rafał Miłecki <zajec5@gmail.com> Cc: Richard Purdie <rpurdie@rpsys.net> Cc: Mauro Carvalho Chehab <mchehab@osg.samsung.com> Cc: Alek Du <alek.du@intel.com> Cc: Jaroslav Kysela <perex@perex.cz> Cc: Takashi Iwai <tiwai@suse.com> Acked-by: Dmitry Torokhov <dmitry.torokhov@gmail.com> Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Acked-by: Lee Jones <lee.jones@linaro.org> Acked-by: Jiri Kosina <jkosina@suse.cz> Acked-by: Hans-Christian Egtvedt <egtvedt@samfundet.no> Acked-by: Jacek Anaszewski <j.anaszewski@samsung.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
* gpio: Add GPIO support for the ACCES 104-IDIO-16William Breathitt Gray2015-10-271-0/+216
The ACCES 104-IDIO-16 family of PC/104 utility boards feature 16 optically isolated inputs and 16 optically isolated FET solid state outputs. This driver provides GPIO support for these 32 channels of digital I/O. Change-of-State detection interrupts are not supported. GPIO 0-15 correspond to digital outputs 0-15, while GPIO 16-31 correspond to digital inputs 0-15. The base port address for the device may be set via the idio_16_base module parameter. Signed-off-by: William Breathitt Gray <vilhelm.gray@gmail.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>