The 104-idi-48 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: NJulia Cartwright <julia@ni.com>
Acked-by: NWilliam Breathitt Gray <vilhelm.gray@gmail.com>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

The pci-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: NJulia Cartwright <julia@ni.com>
Acked-by: NWilliam Breathitt Gray <vilhelm.gray@gmail.com>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

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: NJulia Cartwright <julia@ni.com>
Acked-by: NWilliam Breathitt Gray <vilhelm.gray@gmail.com>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

Add support for mapping gpio-reg gpios to interrupts.  This may be a
non-linear mapping - some gpios in the register may not even have
corresponding interrupts associated with them, so we need to pass an
array.
Signed-off-by: NRussell King <rmk+kernel@armlinux.org.uk>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

Add a simple, generic, single register fixed-direction GPIO driver.
This is able to support a single register with a mixture of inputs
and outputs.

This is different from gpio-mmio and gpio-74xx-mmio:
* gpio-mmio doesn't allow a fixed direction, it assumes there is always
  a direction register.
* gpio-74xx-mmio only supports all-in or all-out setups
* gpio-74xx-mmio is DT only, this needs to support legacy too
* they don't double-read when getting the GPIO value, as required by
  some implementations that this driver supports
* we need to always do 32-bit reads, which bgpio doesn't guarantee
* the current output state may not be readable from the hardware
  register - reading may reflect input status but not output status.
Signed-off-by: NRussell King <rmk+kernel@armlinux.org.uk>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

Allow gpiolib to read back the current IO direction configuration by
implementing the .get_direction callback.  This, in part, allows
debugfs to report the complete true hardware state rather than the
software state.
Signed-off-by: NRussell King <rmk+kernel@armlinux.org.uk>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

Use IO accessors to access the SA1100 registers rather than accessing
them directly.
Signed-off-by: NRussell King <rmk+kernel@armlinux.org.uk>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

Use sa11x0_gpio_set_wake() to set the PWER register, as provided by
Dmitry some time back.
Signed-off-by: NRussell King <rmk+kernel@armlinux.org.uk>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

The mentioned flags are dedicated solely for consumer API.
Replace them by explicit values.
Signed-off-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>
[Made a !bang clamp to (0,1) instead of infix ? operator]
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

Switch to use managed variant of acpi_dev_add_driver_gpios() to simplify
error path and fix potentially wrong assignment if ->probe() fails.

While here, add a debug message in case assignment fails to allow user
see the cause of a potential issue.
Signed-off-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>
Acked-by: NFelipe Balbi <felipe.balbi@linux.intel.com>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

GPIO ACPI library is going to be stricter about resources, thus, expand
comment regarding "reset" GPIO resource in this driver to clarify its
usage in ACPI case.
Signed-off-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

For sake of better maintenance sort the headers by alphabetical order.
Signed-off-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

Introduce ->get_direction() callback for the driver.
Signed-off-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>
[Removed use of GPIOF_DIR* flags]
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

Use the BIT macro instead of explicitly shifting bits for some added
clarity.
Signed-off-by: NRalph Sennhauser <ralph.sennhauser@gmail.com>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

The GPIO-based NAND controller on National Instruments 169445 hardware
exposes a set of simple lines for the control signals.
Signed-off-by: NNathan Sullivan <nathan.sullivan@ni.com>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

This just deletes the Moxa ART driver and replaces it with the
more versatile Faraday FTGPIO010 driver.

Make this default on for ARCH_GEMINI and ARCH_MOXART so we do
not get Kconfig glitches.
Tested-by: NJonas Jensen <jonas.jensen@gmail.com>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

The Gemini driver is actually a driver for the Faraday Technology
FTGPIO010 IP block. We rename the driver and the Kconfig symbol and
put in a a new compatible string for the Moxa ART SoC that is also
using this IP block.
Tested-by: NJonas Jensen <jonas.jensen@gmail.com>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

The DT bindings assumed that this IP block was coming from
Cortina Systems, which turns out not to be true. It is a
standard IP block from Faraday Technology and also used in the
Moxa moxart SoC.

We augment the bindings to cover all existing parts and rename
it after the IP block. This involves deleting the old Moxa
bindings that now are contained in this binding.

Cc: devicetree@vger.kernel.org
Cc: Jonas Jensen <jonas.jensen@gmail.com>
Acked-by: NRob Herring <robh@kernel.org>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

A modern compiler should know better when to inline, so drop the inline
keywords.
Signed-off-by: NRalph Sennhauser <ralph.sennhauser@gmail.com>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

Fix whitespace errors missed by checkpatch.
Signed-off-by: NRalph Sennhauser <ralph.sennhauser@gmail.com>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

Fix whitespace errors reported by checkpatch.
Signed-off-by: NRalph Sennhauser <ralph.sennhauser@gmail.com>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

Use unsigned int instead of plain unsigned as reported by checkpatch.
Signed-off-by: NRalph Sennhauser <ralph.sennhauser@gmail.com>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

While this isn't an issue according to checkpatch two styles are used.
Add a blank line to the block comments missing a blank line at the start
so multiline block comments look the same across the file.
Signed-off-by: NRalph Sennhauser <ralph.sennhauser@gmail.com>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

Fix issues in block comments reported by checkpatch.
Signed-off-by: NRalph Sennhauser <ralph.sennhauser@gmail.com>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

When acpi_dev_gpio_irq_get gets called with an index of say 2, it should
not care if acpi_get_gpiod for index 0 or 1 returns -EPROBE_DEFER.

This allows drivers which request a gpioint with index > 0 to function
if there is no gpiochip driver (loaded) for gpioints with a lower index.
Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>
Acked-by: NMika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

Since gpiod_count() does not return 0 anymore, we don't need to shadow
its error code and would safely propagate to the user.

While here, replace second parameter by NULL in order to prevent side
effects on _DSD enabled firmware.

Cc: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>
Acked-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

Since gpiod_count() does not return 0 anymore, we don't need to shadow
its error code and would safely propagate to the user.

While here, replace second parameter by NULL in order to prevent side
effects on _DSD enabled firmware.

Cc: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

It's unusual to have error checking like (ret <= 0) in cases when
counting GPIO resources. In case when it's mandatory we propagate the
error (-ENOENT), otherwise we don't use the result.

This makes consistent behaviour across all possible variants called in
gpiod_count().
Signed-off-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

It's unusual to have error checking like (ret <= 0) in cases when
counting GPIO resources. In case when it's mandatory we propagate the
error (-ENOENT), otherwise we don't use the result.

This makes consistent behaviour across all possible variants called in
gpiod_count().
Signed-off-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>
Acked-by: NMika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

ARCH_VULCAN arm64 platform (for Broadcom Vulcan ARM64 processors) has
been discontinued. Cavium's ThunderX2 CN99XX (ARCH_THUNDER2) will be
the next revision of this platform.

Update compile dependencies and ACPI ID to reflect this change.
Signed-off-by: NJayachandran C <jnair@caviumnetworks.com>
[Drop depreciation of ARCH_VULCAN]
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

The zx 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: NJulia Cartwright <julia@ni.com>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

The ws16c48 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: NJulia Cartwright <julia@ni.com>
Acked-by: NWilliam Breathitt Gray <vilhelm.gray@gmail.com>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

The pl061 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: NJulia Cartwright <julia@ni.com>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

The etraxfs 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: NJulia Cartwright <julia@ni.com>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

The ath79 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: NJulia Cartwright <julia@ni.com>
Acked-by: NAban Bedel <albeu@free.fr>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

The bcm-kona 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: NJulia Cartwright <julia@ni.com>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

The 104-dio-48e 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: NJulia Cartwright <julia@ni.com>
Acked-by: NWilliam Breathitt Gray <vilhelm.gray@gmail.com>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

The altera 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: NJulia Cartwright <julia@ni.com>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

PC/104 drivers should be hidden on machines which do not support PC/104
devices. This patch adds the PC104 Kconfig option as a dependency for
the relevant PC/104 device driver Kconfig options.

Cc: Linus Walleij <linus.walleij@linaro.org>
Cc: Alexandre Courbot <gnurou@gmail.com>
Signed-off-by: NWilliam Breathitt Gray <vilhelm.gray@gmail.com>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

Use device resource managed variants of irq_alloc_descs() and
request_irq() and remove the code manually freeing irq resources.
Signed-off-by: NBartosz Golaszewski <bgolaszewski@baylibre.com>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>