The helper function for adding a GPIO chip compiles in a lockdep
key for debugging, the same key is needed for nested chips as
well.

The macro construction is unreadable, replace this with two
static inlines instead.

The _gpiochip_irqchip_add prefixed function is not helpful,
rename it with gpiochip_irqchip_add_key() that tell us what the
function is actually doing.

Fixes: d245b3f9 ("gpio: simplify adding threaded interrupts")
Cc: Roger Quadros <rogerq@ti.com>
Reported-by: NClemens Gruber <clemens.gruber@pqgruber.com>
Reported-by: NRoger Quadros <rogerq@ti.com>
Reported-by: NGrygorii Strashko <grygorii.strashko@ti.com>
Tested-by: NClemens Gruber <clemens.gruber@pqgruber.com>
Tested-by: NGrygorii Strashko <grygorii.strashko@ti.com>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

When removing a gpiochip that uses GPIO hogging (e.g. by unloading the
chip's DT overlay), a warning is printed:

    gpio gpiochip8: REMOVING GPIOCHIP WITH GPIOS STILL REQUESTED

This happens because gpiochip_free_hogs() is called after the gdev->chip
pointer is reset to NULL. Hence __gpiod_free() cannot determine the
chip in use, and cannot clear flags nor call the optional chip-specific
.free() callback.

Move the call to gpiochip_free_hogs() up to fix this.

Cc: stable@vger.kernel.org
Fixes: ff2b1359 ("gpio: make the gpiochip a real device")
Signed-off-by: NGeert Uytterhoeven <geert@linux-m68k.org>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

Building with an old toolchain, I ran into this warning:

WARNING: vmlinux.o(.text+0x63eef0): Section mismatch in reference
  from the function mxs_gpio_probe() to the function
  .init.text:mxs_gpio_init_gc()

Clearly the annotation is wrong, since the function is called from the
non-init probe, so let's remove it.
Signed-off-by: NArnd Bergmann <arnd@arndb.de>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

Implement gpio_get_direction() callback for Intel Merrifield GPIO.
Signed-off-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: NLinus 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: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: NLinus 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: NLars-Peter Clausen <lars@metafoo.de>
Signed-off-by: NLinus 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: NCharles Keepax <ckeepax@opensource.wolfsonmicro.com>
Signed-off-by: NLinus 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: NCharles Keepax <ckeepax@opensource.wolfsonmicro.com>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

Platform data is a remnant of board files and all boards using
the PL061 have been migrated to use device tree or ACPI instead.
The custom mechanism to set line by default as inputs/outputs has
been superceded by the GPIO-internal hogging mechanism.
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

No boardfile defines any PL061 platform data anymore: the
Integrator IM/PD-1 includes the file but is not making use
of the struct. Let's delete the include and all references,
then move the platform data into the driver for later
consolidation into the driver state container.

The only resource defined by the IM/PD-1 is the IRQ which
is passed through the AMBA PrimeCell bus abstraction
struct amba_device.

Cc: arm@vger.kernel.org
Cc: linux-arm-kernel@lists.infradead.org
Cc: Russell King <linux@armlinux.org.uk>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

Rename the local variable "chip" referring to the struct pl061
state container to "pl061": we already have gpio_chip and irq_chip
in the driver, we are needlessly adding yet another "chip" to
the confusion.
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

The PL061 state container is named "pl061_gpio", let's rename it
to simply pl061. Less is more.
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

The driver is poking around in the struct gpio_chip internals,
which is a no-no. Use a variable in the local state container.
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

The ADNP, CrystalCove and WhiskeyCove are all nested GPIO
irqchips, but were avoiding to connect the parent IRQ to
the gpiochip. This works, but is kind of sloppy as the
child IRQs are not marked as having the parent IRQ as
parent.

Cc: Mika Westerberg <mika.westerberg@linux.intel.com>
Cc: Ajay Thomas <ajay.thomas.david.rajamanickam@intel.com>
Cc: Bin Gao <bin.gao@linux.intel.com>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

This tries to simplify the use of CONFIG_GPIOLIB_IRQCHIP when
using threaded interrupts: add a new call
gpiochip_irqchip_add_nested() to indicate that we're dealing
with a nested rather than a chained irqchip, then create a
separate gpiochip_set_nested_irqchip() to mirror
the gpiochip_set_chained_irqchip() call to connect the
parent and child interrupts.

In the nested case gpiochip_set_nested_irqchip() does nothing
more than call irq_set_parent() on each valid child interrupt,
which has little semantic effect in the kernel, but this is
probably still formally correct.

Update all drivers using nested interrupts to use
gpiochip_irqchip_add_nested() so we can now see clearly
which these users are.

The DLN2 driver can drop its specific hack with
.irq_not_threaded as we now recognize whether a chip is
threaded or not from its use of gpiochip_irqchip_add_nested()
signature rather than from inspecting .can_sleep.

We rename the .irq_parent to .irq_chained_parent since this
parent IRQ is only really kept around for the chained
interrupt handlers.

Cc: Lars Poeschel <poeschel@lemonage.de>
Cc: Octavian Purdila <octavian.purdila@intel.com>
Cc: Daniel Baluta <daniel.baluta@intel.com>
Cc: Bin Gao <bin.gao@linux.intel.com>
Cc: Mika Westerberg <mika.westerberg@linux.intel.com>
Cc: Ajay Thomas <ajay.thomas.david.rajamanickam@intel.com>
Cc: Semen Protsenko <semen.protsenko@globallogic.com>
Cc: Alexander Stein <alexander.stein@systec-electronic.com>
Cc: Phil Reid <preid@electromag.com.au>
Cc: Bartosz Golaszewski <bgolaszewski@baylibre.com>
Cc: Patrice Chotard <patrice.chotard@st.com>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

Use builtin_platform_driver() helper to simplify the code.
Signed-off-by: NGeliang Tang <geliangtang@gmail.com>
Signed-off-by: NLinus 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: NQuentin Schulz <quentin.schulz@free-electrons.com>
Signed-off-by: NLinus 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: NLinus Walleij <linus.walleij@linaro.org>

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

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

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

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

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

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

This option was added in 6a89a314 to
allow use of the devm_gpio_* functions without CONFIG_GPIOLIB.

However, only a few months later in
b69ac524, CONFIG_GPIOLIB was added
as a dependency, defeating the original purpose of this option.
Instead of that patch, the original commit could have just been
reverted (and in fact was partially so in
403c1d0b). Further, since this
option has a dependency on HAS_IOMEM, even though it does not
require it, it causes build failures when !HAS_IOMEM (e.g. in a
uml build).

Fix that by completely removing the option, in essence completing
the reversion of the original commit.
Signed-off-by: NKeno Fischer <keno@juliacomputing.com>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

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

The bit in the TC3589x direction register is 0 for input
and 1 for output, but the gpiolib expects the reverse.
Fix up the logic.

Cc: stable@vger.kernel.org
Fixes: 14063d71 ("gpio: tc3589x: add .get_direction() and small cleanup")
Signed-off-by: NLinus 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: NLinus 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: NLinus Walleij <linus.walleij@linaro.org>

When locking a GPIO line as IRQ, we go to lengths to
double-check that the line is really set as input before
marking it as used for IRQ. This is not good on GPIO chips
that can sleep, because this function is called in IRQ-safe
context. Just skip this if it can't be checked quickly.

Currently this happens on sleeping expanders such as STMPE
or TC3589x:

BUG: scheduling while atomic: swapper/1/0x00000002
Modules linked in:
CPU: 0 PID: 1 Comm: swapper Not tainted 4.9.0-rc1+ #38
Hardware name: Nomadik STn8815
[<c000f2e0>] (unwind_backtrace) from [<c000d244>] (show_stack+0x10/0x14)
[<c000d244>] (show_stack) from [<c0037b78>] (__schedule_bug+0x54/0x80)
[<c0037b78>] (__schedule_bug) from [<c042df14>] (__schedule+0x3a0/0x460)
[<c042df14>] (__schedule) from [<c042e028>] (schedule+0x54/0xb8)
(...)

This patch fixes that problem and relies on the direction
read from the chip when it was added.

Cc: stable@vger.kernel.org
Fixes: 9c10280d ("gpio: flush direction status in gpiochip_lock_as_irq()")
Cc: Patrice Chotard <patrice.chotard@st.com>
Signed-off-by: NLinus 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: NRussell King <linux@arm.linux.org.uk>
Signed-off-by: NLinus 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: NRussell King <linux@arm.linux.org.uk>
Signed-off-by: NLinus 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: NArnd Bergmann <arnd@arndb.de>
Acked-by: NMika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: NLinus 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: NAxel Haslam <ahaslam@baylibre.com>
Reviewed-by: NSekhar Nori <nsekhar@ti.com>
Acked-by: NKevin Hilman <khilman@baylibre.com>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

Need to ensure that reg_output is not updated while setting multiple
bits. This makes the mutex locking behaviour for the set_multiple call
consistent with that of the set_value call.

Cc: stable@vger.kernel.org
Fixes: b4818afe ("gpio: pca953x: Add set_multiple to allow multiple")
Signed-off-by: NPhil Reid <preid@electromag.com.au>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

gpiod_set_array_value_complex does not clear the bits field.
Therefore when the drivers set_multiple funciton is called bits outside
the mask are undefined and can be either set or not. So bank_val needs
to be masked with bank_mask before or with the reg_val cache.

Cc: stable@vger.kernel.org
Fixes: b4818afe ("gpio: pca953x: Add set_multiple to allow multiple")
Signed-off-by: NPhil Reid <preid@electromag.com.au>
Signed-off-by: NLinus 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: NPaul Gortmaker <paul.gortmaker@windriver.com>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

This fixes the irq allocation in this driver to not print:
 irq: Cannot allocate irq_descs @ IRQ34, assuming pre-allocated
 irq: Cannot allocate irq_descs @ IRQ66, assuming pre-allocated

Which happens because the driver already called irq_alloc_descs()
and so the change to use irq_domain_add_simple resulted in calling
irq_alloc_descs() twice.

Modernize the irq allocation in this driver to use the
irq_domain_add_linear flow directly and eliminate the use of
irq_domain_add_simple/legacy

Fixes: ce931f57 ("gpio/mvebu: convert to use irq_domain_add_simple()")
Signed-off-by: NJason Gunthorpe <jgunthorpe@obsidianresearch.com>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

Sylvain Lemieux reports the LPC32xx GPIO driver is broken since
commit 762c2e46 ("gpio: of: remove of_gpiochip_and_xlate() and
struct gg_data").  Probably, gpio-etraxfs.c and gpio-davinci.c are
broken too.

Those drivers register multiple gpio_chip that are associated to a
single OF node, and their own .of_xlate() checks if the passed
gpio_chip is valid.

Now, the problem is of_find_gpiochip_by_node() returns the first
gpio_chip found to match the given node.  So, .of_xlate() fails,
except for the first GPIO bank.

Reverting the commit could be a solution, but I do not want to go
back to the mess of struct gg_data.  Another solution here is to
take the match by a node pointer and the success of .of_xlate().
It is a bit clumsy to call .of_xlate twice; for gpio_chip matching
and for really getting the gpio_desc index.  Perhaps, our long-term
goal might be to convert the drivers to single chip registration,
but this commit will solve the problem until then.

Fixes: 762c2e46 ("gpio: of: remove of_gpiochip_and_xlate() and struct gg_data")
Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>
Reported-by: NSylvain Lemieux <slemieux.tyco@gmail.com>
Tested-by: NDavid Lechner <david@lechnology.com>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

When allocating a new line handle or event a file is allocated that it is
associated to. The file is attached to a file descriptor of the current
process and the file descriptor is returned to userspace using
copy_to_user(). If this copy operation fails the line handle or event
allocation is aborted, all acquired resources are freed and an error is
returned.

But the file struct is not freed and left attached to the userspace
application and even though the file descriptor number was not copied it is
trivial to guess. If a userspace application performs a IOCTL on such a
left over file descriptor it will trigger a use-after-free and if the file
descriptor is closed (latest when the application exits) a double-free is
triggered.

anon_inode_getfd() performs 3 tasks, allocate a file struct, allocate a
file descriptor for the current process and install the file struct in the
file descriptor. As soon as the file struct is installed in the file
descriptor it is accessible by userspace (even if the IOCTL itself hasn't
completed yet), this means uninstalling the fd on the error path is not an
option, since userspace might already got a reference to the file.

Instead anon_inode_getfd() needs to be broken into its individual steps.
The allocation of the file struct and file descriptor is done first, then
the copy_to_user() is executed and only if it succeeds the file is
installed.

Since the file struct is reference counted it can not be just freed, but
its reference needs to be dropped, which will also call the release()
callback, which will free the state attached to the file. So in this case
the normal error cleanup path should not be taken.

Cc: stable@vger.kernel.org
Fixes: d932cd49 ("gpio: free handles in fringe cases")
Signed-off-by: NLars-Peter Clausen <lars@metafoo.de>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>