Implement gpio_get_direction() callback for Intel Merrifield GPIO.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>

By default all pins are configured to use a glitch filter. Writing 1 to the
certain bit of the specific register might be useful in case someone needs to
bypass the glitch filter completely for a given GPIO pin.

This patch adds support for that in the Intel Merrifield GPIO driver.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>

The GPIO chardev is used for management tasks (allocating line and event
handles) and does neither support read() nor write() operations. Hence it
does not make much sense to allow seek operations.

Currently the chardev uses noop_llseek() for its seek implementation. This
function does not move the pointer and simply returns the current position
(always 0 for the GPIO chardev). noop_llseek() is primarily meant for
devices that can not support seek, but where there might be a user that
depends on the seek() operation succeeding. For newly added devices that
can not support seek operations it is recommended to use no_llseek(), which
will return an error. For more information see commit 6038f373
("llseek: automatically add .llseek fop").

Unfortunately this was overlooked when the GPIO chardev ABI was introduced.
But it is highly unlikely that since then userspace applications have
appeared that rely on being able to perform non-failing seek operations on
a GPIO chardev file descriptor. So it should be safe to change from
noop_llseel() to no_seek(). Also use nonseekable_open() in the chardev
open() callback to clear the FMODE_SEEK, FMODE_PREAD and FMODE_PWRITE flags
from the file. Neither of these should be set on a file that does not
support seek operations.

Cc: stable@vger.kernel.org
Fixes: 3c702e99 ("gpio: add a userspace chardev ABI for GPIOs")
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>

There is some unnecessary complexity in the error path which now things
are converted to devm is actually very simple. This patch simplifies
things.
Signed-off-by: Charles Keepax <ckeepax@opensource.wolfsonmicro.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>

We use the gpio chip private data in all the callbacks so remove this
redundant line of code.
Signed-off-by: Charles Keepax <ckeepax@opensource.wolfsonmicro.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>

Use builtin_platform_driver() helper to simplify the code.
Signed-off-by: Geliang Tang <geliangtang@gmail.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>

The GPIO input status was read from control register
(AXP20X_GPIO[210]_CTRL) instead of status register (AXP20X_GPIO20_SS).
Signed-off-by: Quentin Schulz <quentin.schulz@free-electrons.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>

commit 43db289d ("gpio: stmpe: Rework registers access")
reworked the STMPE register access so as to use
[STMPE_IDX_*_LSB + i] to access the 8bit register for a
certain bank, assuming the CSB and MSB will follow after
the enumerator. For this to work the index needs to go from
(size-1) to 0 not 0 to (size-1).

However for the GPIO IRQ handler, the status registers we read
register MSB + 3 bytes ahead for the 24 bit GPIOs and index
registers from MSB upwards and run an index i over the
registers UNLESS we are STMPE1600.

This is not working when we get to clearing the interrupt
EDGE status register STMPE_IDX_GPEDR_[LCM]SB: it is indexed
like all other registers [STMPE_IDX_*_LSB + i] but in this
loop we index from 0 to get the right bank index for the
calculations, and we need to just add i to the MSB.

Before this, interrupts on the STMPE2401 were broken, this
patch fixes it so it works again.

Cc: stable@vger.kernel.org
Cc: Patrice Chotard <patrice.chotard@st.com>
Fixes: 43db289d ("gpio: stmpe: Rework registers access")
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>

The GPIO_EM is part of the Renesas SoCs so depend on the arch.
Signed-off-by: Peter Robinson <pbrobinson@gmail.com>
[Changed to depend on ARCH_EMEV2]
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>

Set GPIO_ZX to depend on ARCH_ZX as it's SOC specific.
Signed-off-by: Peter Robinson <pbrobinson@gmail.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>

The devices here are specific to x86 so lets depend on x86.
Signed-off-by: Peter Robinson <pbrobinson@gmail.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>

Use builtin_platform_driver() helper to simplify the code.
Signed-off-by: Geliang Tang <geliangtang@gmail.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>

Use builtin_platform_driver() helper to simplify the code.
Signed-off-by: Geliang Tang <geliangtang@gmail.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>

Adding max20024 compatible string to the device id list
to support both max77620 and max20024 devices.
Signed-off-by: Venkat Reddy Talla <vreddytalla@nvidia.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>

Use builtin_pci_driver() helper to simplify the code.
Signed-off-by: Geliang Tang <geliangtang@gmail.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>

When a GPIO line is marked as used for an interrupt, it is
helpful to set the label to "interrupt" so we know what is
going on when inspecting the lines.

If a GPIO is already properly named by gpiod_get*() we don't
need to do this. It only happens when a line is used from
the irqchip side of a GPIO driver without communicating
with the GPIO side, such as when gpiochip is used as interrupt
provider in the device tree.

If the line is still marked as used by "interrupt" when we
unmark it as used by an interrupt, also remove this label
from the descriptor.

Also shape up the code around unmarking IRQ lines.
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>

I saw weird values != [0,1] being passed down to drivers
in their .set_direction_output() callbacks. Go over the
gpiolib and make sure to hammer it to [0,1] before hitting
the driver to avoid undesired side effects.
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>

When the hardware is in output mode, reading the value from the
hardware is not giving the correct value back. Instead read the
value from the cache so we get the right value.
Suggested-by: Russell King <linux@arm.linux.org.uk>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>

This makes is possible to read out the current direction of a
GPIO line on the HTC CPLD GPIO expander.
Suggested-by: Russell King <linux@arm.linux.org.uk>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>

The newly added acpi_gpiochip_scan_gpios function produces a few harmless
warnings:

drivers/gpio/gpiolib-acpi.c: In function ‘acpi_gpiochip_add’:
drivers/gpio/gpiolib-acpi.c:925:7: error: ‘dflags’ may be used uninitialized in this function [-Werror=maybe-uninitialized]
drivers/gpio/gpiolib-acpi.c:925:9: error: ‘lflags’ may be used uninitialized in this function [-Werror=maybe-uninitialized]

The problem is that he compiler cannot know that a negative return value
from fwnode_property_read_u32_array() or acpi_gpiochip_pin_to_gpio_offset()
implies that the IS_ERR(gpio_desc) is true, as the value could in theory
be below -MAX_ERRNO.

The function already initializes its output values to zero, and moving
that intialization a little higher up ensures that we can never have
uninitialized data in the caller.

Fixes: c80f1ba7 ("ACPI / gpio: Add hogging support")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Acked-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>

The gpiod framework uses the chip label to match a specific chip.
The davinci gpio driver, creates several chips using always the same
label, which is not compatible with gpiod.

To allow platform data to declare gpio lookup tables, and for drivers
to use the gpiod framework, allocate unique label per registered chip.
Signed-off-by: Axel Haslam <ahaslam@baylibre.com>
Reviewed-by: Sekhar Nori <nsekhar@ti.com>
Acked-by: Kevin Hilman <khilman@baylibre.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>

The Kconfig currently controlling compilation of this code is:

drivers/gpio/Kconfig:config HTC_EGPIO
drivers/gpio/Kconfig:   bool "HTC EGPIO support"

...meaning that it currently is not being built as a module by anyone.

Lets remove the modular code that is essentially orphaned, so that
when reading the driver there is no doubt it is builtin-only.

We explicitly disallow a driver unbind, since that doesn't have a
sensible use case anyway, and it allows us to drop the ".remove"
code for non-modular drivers.

Since module_init was not in use by this code, the init ordering
remains unchanged with this commit.

We also delete the MODULE_LICENSE tag etc. since all that information
is already contained at the top of the file in the comments.

Cc: Linus Walleij <linus.walleij@linaro.org>
Cc: Alexandre Courbot <gnurou@gmail.com>
Cc: Kevin O'Connor <kevin@koconnor.net>
Cc: linux-gpio@vger.kernel.org
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>

When terminating for_each_available_child_of_node() iteration
with break or return, of_node_put() should be used to prevent
stale device node references from being left behind.

This is detected by Coccinelle semantic patch.
Signed-off-by: Wei Yongjun <weiyongjun1@huawei.com>
Reviewed-by: Vladimir Zapolskiy <vladimir_zapolskiy@mentor.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>

Fixes the following sparse warning:

drivers/gpio/gpiolib-acpi.c:863:18: warning:
 symbol 'acpi_gpiochip_parse_own_gpio' was not declared. Should it be static?
Signed-off-by: Wei Yongjun <weiyongjun1@huawei.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>

fwnode_handle_put() should be used when terminating
device_for_each_child_node() iteration with break or
return to prevent stale device node references from
being left behind.

This is detected by Coccinelle semantic patch.
Signed-off-by: Wei Yongjun <weiyongjun1@huawei.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>

Confirm the chip->parent is valid before dereferencing because
the parent parameter is optional.
Signed-off-by: Thor Thayer <tthayer@opensource.altera.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>

It's not necessary to unregister gpio_chip which registered
with devm_gpiochip_add_data().
Also get rid of useless altr_a10sr_gpio_remove().
Signed-off-by: Wei Yongjun <weiyongjun1@huawei.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>

According to the reference manual level interrupts can't be acked
using the IRQSTAT registers. The effect is that when a level interrupt
triggers the following ack is a no-op and the same interrupt triggers
again right after it has been unmasked after running the interrupt
handler.

The reference manual says:

Status bits for pins configured as level sensitive interrupts cannot be
cleared unless either the actual pin is in the non-interrupting state, or
the pin has been disabled as an interrupt source by clearing its bit in
HW_PINCTRL_PIN2IRQ.

To work around the duplicated interrupts we can use the PIN2IRQ
rather than the IRQEN registers to mask the interrupts. This
probably does not work for the edge interrupts, so we have to split up
the irq chip into two chip types, one for the level interrupts and
one for the edge interrupts. We now make use of two different enable
registers, so we have to take care to always enable the right one,
especially during switching of the interrupt type. An easy way
to accomplish this is to use the IRQCHIP_SET_TYPE_MASKED which
makes sure that set_irq_type is called with masked interrupts. With this
the flow to change the irq type is like:

- core masks interrupt (using the current chip type)
- mxs_gpio_set_irq_type() changes chip type if necessary
- mxs_gpio_set_irq_type() unconditionally sets the enable bit in the
  now unused enable register
- core eventually unmasks the interrupt (using the new chip type)
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
Reviewed-by: Marek Vasut <marex@denx.de>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>

The mxs gpio controller does not only have a mask register to mask
interrupts, but also enable/disable registers. Use the enable/disable
registers rather than the mask register. This does not have any
advantage for now, but makes the next patch simpler.
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
Reviewed-by: Marek Vasut <marex@denx.de>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>

Now that we have the new helper function that sets nice names for GPIO
lines based on "gpio-line-names" device property, we can take advantage of
this in acpi_gpiochip_add().
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>

In order to use "gpio-line-names" property in systems not having DT as
their boot firmware, rework of_gpiochip_set_names() to use device property
accessors. This reworked function is placed in a separate file making it
clear it deals with universal device properties.
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>

GPIO hogging means that the GPIO controller can "hog" and configure certain
GPIOs without need for a driver or userspace to do that. This is useful in
open-connected boards where BIOS cannot possibly know beforehand which
devices will be connected to the board.

This adds GPIO hogging mechanism to ACPI analogous to Device Tree.
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>

Make it possible to have an empty GPIOs in a GPIO list for device. For
example a SPI master may use both GPIOs and native pins as chip selects and
we need to be able to distinguish between the two.

This makes it mandatory to have exactly 3 arguments for GPIOs and then
converts gpiolib to use of __acpi_node_get_property_reference() instead. In
addition we make acpi_gpio_package_count() to handle holes as well (this
matches the DT version).
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>

Add compatible string for the MAX7318 part. This is a two bank,
16 lines, I2C GPIO expander with interrupt line.
Signed-off-by: Marek Vasut <marex@denx.de>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>

All the boards supported by the gpio-ts4900 driver are i.MX6 boards,
so only offer the driver for building on this platform, unless
build-testing.
Signed-off-by: Jean Delvare <jdelvare@suse.de>
Cc: Lucile Quirion <lucile.quirion@savoirfairelinux.com>
Cc: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>

Signed-off-by: Bamvor Jian Zhang <bamvor.zhangjian@linaro.org>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>

Add basic gpio operations. User could get/set gpio value for specific
line of gpiochip.

Reference "tools/gpio/gpio-hammer.c" or
"tools/testing/selftest/gpio/gpio-mockup-chardev.c" for how to use it.
Signed-off-by: Bamvor Jian Zhang <bamvor.zhangjian@linaro.org>
Reviewed-by: Michael Welling <mwelling@ieee.org>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>

Add the GPIO functionality for the Altera Arria10 MAX5 System Resource
Chip. The A10 MAX5 has 12 bits of GPIO assigned to switches, buttons,
and LEDs as a GPIO extender on the SPI bus.
Signed-off-by: Thor Thayer <tthayer@opensource.altera.com>
Acked-by: Linus Walleij <linus.walleij@linaro.org>i
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>

We switch the default handler to be handle_bad_irq() instead of
handle_simple_irq() (which was not correct anyway).
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>