ACPI table on Intel Galileo Gen 2 has wrong pin number for IRQ resource
of one of the I²C GPIO expanders. Since we know what that number is and
luckily have GPIO bases fixed for SoC's controllers, we may use a simple
DMI quirk to match the platform and retrieve GpioInt() pin on it for
the expander in question.

Mika suggested the way to avoid a quirk in the GPIO ACPI library and
here is the second, almost rewritten version of it.

Fixes: f32517bf ("gpio: pca953x: support ACPI devices found on Galileo Gen2")
Depends-on: 25e3ef89 ("gpio: acpi: Split out acpi_gpio_get_irq_resource() helper")
Suggested-by: NMika Westerberg <mika.westerberg@linux.intel.com>
Reviewed-by: NMika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: NBartosz Golaszewski <bgolaszewski@baylibre.com>

Since the commit aa58a21a ("gpio: pca953x: disable regmap locking")
the locking of regmap is disabled and that immediately introduces
a synchronization issue. It's easy to see when we try to monitor
more than one interrupt from the same chip.

It seems that the problem exists from the day one and even commit
6e20fb18 ("drivers/gpio/pca953x.c: add a mutex to fix race condition")
missed this.

Below are the traces and shell reproducers before and after proposed change.
Note duplicates in the IRQ events. /proc/interrupts also shows a deviation,
i.e. sum of children interrupts higher than parent's one.

When locking is disabled for regmap and no protection in IRQ handler
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 ...
 gpioset-194          regmap_hw_write_start: i2c-INT3491:02 reg=2 count=1
 irq/31-i2c-INT3-139  regmap_hw_read_start: i2c-INT3491:02 reg=4c count=2
 gpioset-194          regmap_hw_write_done: i2c-INT3491:02 reg=2 count=1
 gpioset-194          regmap_reg_read_cache: i2c-INT3491:02 reg=6 val=f5
 gpioset-194          regmap_reg_write: i2c-INT3491:02 reg=6 val=f5
 gpioset-194          regmap_hw_write_start: i2c-INT3491:02 reg=6 count=1
 irq/31-i2c-INT3-139  regmap_hw_read_done: i2c-INT3491:02 reg=4c count=2
 ...

 % gpiomon gpiochip3 0 &
 % gpioset gpiochip3 1=0
 % gpioset gpiochip3 1=1
 event:  RISING EDGE offset: 0 timestamp: [     302.782583765]
 % gpiomon gpiochip3 2 &
 % gpioset gpiochip3 1=0
 event:  RISING EDGE offset: 2 timestamp: [     312.033148829]
 event: FALLING EDGE offset: 0 timestamp: [     312.022757525]
 % gpioset gpiochip3 1=1
 event:  RISING EDGE offset: 2 timestamp: [     316.201148473]
 event:  RISING EDGE offset: 0 timestamp: [     316.191759599]

When locking is disabled for regmap and protection in IRQ handler
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 ...
 gpioset-202          regmap_hw_write_start: i2c-INT3491:02 reg=2 count=1
 gpioset-202          regmap_hw_write_done: i2c-INT3491:02 reg=2 count=1
 gpioset-202          regmap_reg_read_cache: i2c-INT3491:02 reg=6 val=fd
 gpioset-202          regmap_reg_write: i2c-INT3491:02 reg=6 val=fd
 gpioset-202          regmap_hw_write_start: i2c-INT3491:02 reg=6 count=1
 gpioset-202          regmap_hw_write_done: i2c-INT3491:02 reg=6 count=1
 irq/31-i2c-INT3-139  regmap_hw_read_start: i2c-INT3491:02 reg=4c count=2
 irq/31-i2c-INT3-139  regmap_hw_read_done: i2c-INT3491:02 reg=4c count=2
 ...

 % gpiomon gpiochip3 0 &
 % gpioset gpiochip3 1=0
 event: FALLING EDGE offset: 0 timestamp: [     531.330078107]
 % gpioset gpiochip3 1=1
 event:  RISING EDGE offset: 0 timestamp: [     532.912239128]
 % gpiomon gpiochip3 2 &
 % gpioset gpiochip3 1=0
 event: FALLING EDGE offset: 0 timestamp: [     539.633669484]
 % gpioset gpiochip3 1=1
 event:  RISING EDGE offset: 0 timestamp: [     542.256978461]

Fixes: 6e20fb18 ("drivers/gpio/pca953x.c: add a mutex to fix race condition")
Depends-on: 35d13d94 ("gpio: pca953x: convert to use bitmap API")
Depends-on: 49427232 ("gpio: pca953x: Perform basic regmap conversion")
Cc: Marek Vasut <marek.vasut@gmail.com>
Cc: Roland Stigge <stigge@antcom.de>
Signed-off-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: NBartosz Golaszewski <bgolaszewski@baylibre.com>

Since commit 84af7a61 ("checkpatch: kconfig: prefer 'help' over
'---help---'"), the number of '---help---' has been gradually
decreasing, but there are still more than 2400 instances.

This commit finishes the conversion. While I touched the lines,
I also fixed the indentation.

There are a variety of indentation styles found.

  a) 4 spaces + '---help---'
  b) 7 spaces + '---help---'
  c) 8 spaces + '---help---'
  d) 1 space + 1 tab + '---help---'
  e) 1 tab + '---help---'    (correct indentation)
  f) 1 tab + 1 space + '---help---'
  g) 1 tab + 2 spaces + '---help---'

In order to convert all of them to 1 tab + 'help', I ran the
following commend:

  $ find . -name 'Kconfig*' | xargs sed -i 's/^[[:space:]]*---help---/\thelp/'
Signed-off-by: NMasahiro Yamada <masahiroy@kernel.org>

ACPI_PTR() becomes a no-op when !CONFIG_ACPI. This is not needed since
we always have ID table enabled. Moreover, in the mentioned case compiler
will complain about defined but not used variable.
Signed-off-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>
Link: https://lore.kernel.org/r/20200520211916.25727-3-andriy.shevchenko@linux.intel.comSigned-off-by: NLinus Walleij <linus.walleij@linaro.org>

There are quite a lot simple GPIO controller which are using regmap to
access the hardware. This driver tries to be a base to unify existing
code into one place. This won't cover everything but it should be a good
starting point.

It does not implement its own irq_chip because there is already a
generic one for regmap based devices. Instead, the irq_chip will be
instantiated in the parent driver and its irq domain will be associate
to this driver.

For now it consists of the usual registers, like set (and an optional
clear) data register, an input register and direction registers.
Out-of-the-box, it supports consecutive register mappings and mappings
where the registers have gaps between them with a linear mapping between
GPIO offset and bit position. For weirder mappings the user can register
its own .xlate().
Signed-off-by: NMichael Walle <michael@walle.cc>
Reviewed-by: NAndy Shevchenko <andy.shevchenko@gmail.com>
Link: https://lore.kernel.org/r/20200528145845.31436-3-michael@walle.ccSigned-off-by: NLinus Walleij <linus.walleij@linaro.org>

The function connects an IRQ domain to a gpiochip and reuses
gpiochip_to_irq() which is provided by gpiolib.

gpiochip_irqchip_* and regmap_irq partially provide the same
functionality. This function will help to connect just the
minimal functionality of the gpiochip_irqchip which is needed to
work together with regmap-irq.
Signed-off-by: NMichael Walle <michael@walle.cc>
Reviewed-by: NAndy Shevchenko <andy.shevchenko@gmail.com>
Link: https://lore.kernel.org/r/20200528145845.31436-2-michael@walle.ccSigned-off-by: NLinus Walleij <linus.walleij@linaro.org>

We provided the right semantics on open drain lines being
by definition output but incidentally the irq set up function
would only allow IRQs on lines that were "not output".

Fix the semantics to allow output open drain lines to be used
for IRQs.
Reported-by: NHans Verkuil <hverkuil@xs4all.nl>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
Signed-off-by: NHans Verkuil <hverkuil@xs4all.nl>
Tested-by: NHans Verkuil <hverkuil@xs4all.nl>
Cc: Russell King <linux@armlinux.org.uk>
Cc: stable@vger.kernel.org # v5.3+
Link: https://lore.kernel.org/r/20200527140758.162280-1-linus.walleij@linaro.orgSigned-off-by: NLinus Walleij <linus.walleij@linaro.org>

With 'commit 461c1a7d ("gpiolib: override irq_enable/disable")' gpiolib
overrides irqchip's irq_enable and irq_disable callbacks. If irq_disable
callback is implemented then genirq takes unlazy path to disable irq.

Underlying irqchip may not want to implement irq_disable callback to lazy
disable irq when client drivers invokes disable_irq(). By overriding
irq_disable callback, gpiolib ends up always unlazy disabling IRQ.

Allow gpiolib to lazy disable IRQs by overriding irq_disable callback only
if irqchip implemented irq_disable. In cases where irq_disable is not
implemented irq_mask is overridden. Similarly override irq_enable callback
only if irqchip implemented irq_enable otherwise irq_unmask is overridden.

Fixes: 461c1a7d ("gpiolib: override irq_enable/disable")
Signed-off-by: NMaulik Shah <mkshah@codeaurora.org>
Tested-by: NHans Verkuil <hverkuil-cisco@xs4all.nl>
Link: https://lore.kernel.org/r/1590253873-11556-2-git-send-email-mkshah@codeaurora.orgSigned-off-by: NLinus Walleij <linus.walleij@linaro.org>

We already have two conditionals inside the outer one to check
if the command is GPIO_GET_LINEINFO_WATCH_IOCTL. I think it's
time to actually do what I have proposed in the first place, i.e.
to separate GPIO_GET_LINEINFO_WATCH_IOCTL from GPIO_GET_LINEINFO_IOCTL.
It's +13 LOCs, and surprisingly only +13 bytes of binary on x86_32,
but for the price of much better readability.
Signed-off-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>
Acked-by: NBartosz Golaszewski <bgolaszewski@baylibre.com>
Link: https://lore.kernel.org/r/20200525194028.74236-1-andriy.shevchenko@linux.intel.comSigned-off-by: NLinus Walleij <linus.walleij@linaro.org>

pm_runtime_get_sync() increments the runtime PM usage counter even
when it returns an error code. Thus a pairing decrement is needed on
the error handling path to keep the counter balanced.
Signed-off-by: NDinghao Liu <dinghao.liu@zju.edu.cn>
Link: https://lore.kernel.org/r/20200522080839.32612-1-dinghao.liu@zju.edu.cnSigned-off-by: NLinus Walleij <linus.walleij@linaro.org>

Perhaps by some historical reasons the IRQ support has been allowed
only for built-in driver. However, there is nothing prevents us
to build it as module an use as IRQ chip.
Signed-off-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: NBartosz Golaszewski <bgolaszewski@baylibre.com>

Propagate the error code returned by devm_platform_ioremap_resource()
out of probe() instead of overwriting it.

Fixes: 72d8cb71 ("drivers: gpio: bcm-kona: use devm_platform_ioremap_resource()")
Signed-off-by: NTiezhu Yang <yangtiezhu@loongson.cn>
[Bartosz: tweaked the commit message]
Signed-off-by: NBartosz Golaszewski <bgolaszewski@baylibre.com>

Add COMPILE_TEST support to the PXA GPIO driver for better compile
testing coverage.
Signed-off-by: NTiezhu Yang <yangtiezhu@loongson.cn>
Signed-off-by: NBartosz Golaszewski <bgolaszewski@baylibre.com>

When call function devm_platform_ioremap_resource(), we should use IS_ERR()
to check the return value and return PTR_ERR() if failed.

Fixes: 542c25b7 ("drivers: gpio: pxa: use devm_platform_ioremap_resource()")
Signed-off-by: NTiezhu Yang <yangtiezhu@loongson.cn>
Signed-off-by: NBartosz Golaszewski <bgolaszewski@baylibre.com>

mutex_lock() can sleep, don't call mutex_lock() while holding spin_lock.

Fixes: bc0ae0e7 ("gpio: add driver for Mellanox BlueField 2 GPIO controller")
Signed-off-by: NAxel Lin <axel.lin@ingics.com>
Acked-by: asmaa@mellanox.com
Signed-off-by: NBartosz Golaszewski <bgolaszewski@baylibre.com>

has_irq member of struct dwapb_port_property is used only in one place,
so, make it local test instead and remove from the structure.
This local test is using memchr_inv() which is quite efficient in comparison
to the original loop and possible little overhead can be neglected.
Signed-off-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>
Tested-by: NSerge Semin <fancer.lancer@gmail.com>
Acked-by: NLee Jones <lee.jones@linaro.org>
Acked-by: NSerge Semin <fancer.lancer@gmail.com>
Link: https://lore.kernel.org/r/20200519131233.59032-4-andriy.shevchenko@linux.intel.comSigned-off-by: NLinus Walleij <linus.walleij@linaro.org>

IRQ 0 is not valid in Linux interrupt number space.
Refactor the code with this kept in mind.
Signed-off-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>
Tested-by: NSerge Semin <fancer.lancer@gmail.com>
Acked-by: NSerge Semin <fancer.lancer@gmail.com>
Link: https://lore.kernel.org/r/20200519131233.59032-3-andriy.shevchenko@linux.intel.comSigned-off-by: NLinus Walleij <linus.walleij@linaro.org>

platform_get_irq() will generate an error message if the requested IRQ
is not present. Use platform_get_irq_optional() to avoid the error message
being generated.
Signed-off-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>
Tested-by: NSerge Semin <fancer.lancer@gmail.com>
Reviewed-by: NSerge Semin <fancer.lancer@gmail.com>
Acked-by: NSerge Semin <fancer.lancer@gmail.com>
Link: https://lore.kernel.org/r/20200519131233.59032-2-andriy.shevchenko@linux.intel.comSigned-off-by: NLinus Walleij <linus.walleij@linaro.org>

Add missed acpi_gpiochip_free_interrupts() call when unregistering ports.

While at it, drop extra check to call acpi_gpiochip_request_interrupts().
There is no need to have an additional check to call
acpi_gpiochip_request_interrupts(). Even without any interrupts available
the registered ACPI Event handlers can be useful for debugging purposes.

Fixes: e6cb3486 ("gpio: dwapb: add gpio-signaled acpi event support")
Signed-off-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>
Tested-by: NSerge Semin <fancer.lancer@gmail.com>
Acked-by: NSerge Semin <fancer.lancer@gmail.com>
Link: https://lore.kernel.org/r/20200519131233.59032-1-andriy.shevchenko@linux.intel.comSigned-off-by: NLinus Walleij <linus.walleij@linaro.org>

gpiochip_add_data being called before might cause premature calls of
the gpiochip operations before the port_config values are initialized,
which would possibily write zeros to port configuration registers,
an operation not allowed. For example, if there are gpio-hog nodes
in a device-tree, the sequence of function calls are performed

gpiochip_add_data
of_gpiochip_add
of_gpiochip_scan_gpios
of_gpiochip_add_hog
gpiod_hog
gpiochip_request_own_desc
gpiod_configure_flags
gpiod_direction_output/gpiod_direction_input

which would call later the gpiochip operation direction_output or
direction_input prior the port_config[] initialization.

Moreover, gpiochip_get_data is replaced by the container_of macro
inside the gpiochip operations, which would allow the calling of
max7301_direction_input prior to gpiochip_add_data
Signed-off-by: NRodrigo Alencar <455.rodrigo.alencar@gmail.com>
[Bartosz: tweaked the commit message]
Signed-off-by: NBartosz Golaszewski <bgolaszewski@baylibre.com>

The interrupt simulator API exposes a lot of custom data structures and
functions and doesn't reuse the interfaces already exposed by the irq
subsystem. This patch tries to address it.

We hide all the simulator-related data structures from users and instead
rely on the well-known irq domain. When creating the interrupt simulator
the user receives a pointer to a newly created irq_domain and can use it
to create mappings for simulated interrupts.

It is also possible to pass a handle to fwnode when creating the simulator
domain and retrieve it using irq_find_matching_fwnode().

The irq_sim_fire() function is dropped as well. Instead we implement the
irq_get/set_irqchip_state interface.

We modify the two modules that use the simulator at the same time as
adding these changes in order to reduce the intermediate bloat that would
result when trying to migrate the drivers in separate patches.
Signed-off-by: NBartosz Golaszewski <bgolaszewski@baylibre.com>
Signed-off-by: NMarc Zyngier <maz@kernel.org>
Reviewed-by: NLinus Walleij <linus.walleij@linaro.org>
Acked-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> #for IIO
Link: https://lore.kernel.org/r/20200514083901.23445-3-brgl@bgdev.pl

GPIO controllers are exported to userspace using /dev/gpiochip*
character devices.  Access control to these devices is provided by
standard UNIX file system permissions, on an all-or-nothing basis:
either a GPIO controller is accessible for a user, or it is not.
Currently no mechanism exists to control access to individual GPIOs.

Hence add a GPIO driver to aggregate existing GPIOs, and expose them as
a new gpiochip.

This supports the following use cases:
  - Aggregating GPIOs using Sysfs
    This is useful for implementing access control, and assigning a set
    of GPIOs to a specific user or virtual machine.
  - Generic GPIO Driver
    This is useful for industrial control, where it can provide
    userspace access to a simple GPIO-operated device described in DT,
    cfr. e.g. spidev for SPI-operated devices.
Signed-off-by: NGeert Uytterhoeven <geert+renesas@glider.be>
Tested-by: NEugeniu Rosca <erosca@de.adit-jv.com>
Reviewed-by: NEugeniu Rosca <erosca@de.adit-jv.com>
Link: https://lore.kernel.org/r/20200511145257.22970-5-geert+renesas@glider.beSigned-off-by: NLinus Walleij <linus.walleij@linaro.org>

Currently a GPIO lookup table can only refer to a specific GPIO by a
tuple, consisting of a GPIO controller label and a GPIO offset inside
the controller.

However, a GPIO may also carry a line name, defined by DT or ACPI.
If present, the line name is the most use-centric way to refer to a
GPIO.  Hence add support for looking up GPIOs by line name.
Note that there is no guarantee that GPIO line names are globally
unique, so this will use the first match found.

Implement this by reusing the existing gpiod_lookup infrastructure.
Rename gpiod_lookup.chip_label to gpiod_lookup.key, to make it clear
that this field can have two meanings, and update the kerneldoc and
GPIO_LOOKUP*() macros.
Signed-off-by: NGeert Uytterhoeven <geert+renesas@glider.be>
Tested-by: NEugeniu Rosca <erosca@de.adit-jv.com>
Reviewed-by: NUlrich Hecht <uli+renesas@fpond.eu>
Reviewed-by: NEugeniu Rosca <erosca@de.adit-jv.com>
Link: https://lore.kernel.org/r/20200511145257.22970-4-geert+renesas@glider.beSigned-off-by: NLinus Walleij <linus.walleij@linaro.org>

There is no need to have an additional check to call
acpi_gpiochip_request_interrupts(). Even without any interrupts available
the registered ACPI Event handlers can be useful for debugging purposes.
Signed-off-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>
Link: https://lore.kernel.org/r/20200512182721.55127-3-andriy.shevchenko@linux.intel.comSigned-off-by: NLinus Walleij <linus.walleij@linaro.org>

Allow driver to be built with COMPILE_TEST for better test coverage.
Signed-off-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>
Link: https://lore.kernel.org/r/20200512182721.55127-2-andriy.shevchenko@linux.intel.comSigned-off-by: NLinus Walleij <linus.walleij@linaro.org>

There is nothing in the driver requires OF_GPIO. Moreover, driver
supports ACPI and OF_GPIO may be a quite overhead on such configurations.

Drop dependency for good and replace of_gpio.h to of.h since we have
one function to be defined from there.
Signed-off-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>
Link: https://lore.kernel.org/r/20200512182721.55127-1-andriy.shevchenko@linux.intel.comSigned-off-by: NLinus Walleij <linus.walleij@linaro.org>

acpi_gpiochip_request_interrupts() will check for ACPI handle of
the GPIO chip parent device and bail out if there is none defined.
Thus, has_acpi_companion() is effectively repeating above and
is not needed in the individual driver.

Assigning ->to_irq() unconditionally doesn't change anything, except
an error code, but this we fix as well by propagating it from
platform_get_irq().
Signed-off-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>
Link: https://lore.kernel.org/r/20200512182623.54990-2-andriy.shevchenko@linux.intel.comSigned-off-by: NLinus Walleij <linus.walleij@linaro.org>

Simplify the code which fetches the input clock by using
devm_clk_get_optional(). If no input clock is present
devm_clk_get_optional() will return NULL instead of an error
which matches the behavior of the old code.
Signed-off-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>
Link: https://lore.kernel.org/r/20200512182623.54990-1-andriy.shevchenko@linux.intel.comSigned-off-by: NLinus Walleij <linus.walleij@linaro.org>

gpiochip_set_desc_names() no longer rejects GPIO line name collisions.
Hence GPIO line names are not guaranteed to be globally unique.
In case of multiple GPIO lines with the same name, gpio_name_to_desc()
will return the first match found.

Update the comments for gpio_name_to_desc() and
gpiochip_set_desc_names() to match reality.

Fixes: f881bab0 ("gpio: keep the GPIO line names internal")
Signed-off-by: NGeert Uytterhoeven <geert+renesas@glider.be>
Link: https://lore.kernel.org/r/20200511101828.30046-1-geert+renesas@glider.beSigned-off-by: NLinus Walleij <linus.walleij@linaro.org>

Currently we emit the REQUESTED line state event after the line is
requested but before the flags are configured. This is obviously wrong
as we want to pass the updated lineinfo to user-space together with the
event.

Since the flags can be configured in different ways depending on how the
line is being requested - we need to call the notifier chain in different
places separately.

Fixes: 51c1064e ("gpiolib: add new ioctl() for monitoring changes in line info")
Signed-off-by: NBartosz Golaszewski <bgolaszewski@baylibre.com>

The commit 7ecced09 ("gpio: exar: add a check for the return value
of ida_simple_get fails") added a goto jump to the common error
handler for ida_simple_get() error, but this is wrong in two ways:
it doesn't set the proper return code and, more badly, it invokes
ida_simple_remove() with a negative index that shall lead to a kernel
panic via BUG_ON().

This patch addresses those two issues.

Fixes: 7ecced09 ("gpio: exar: add a check for the return value of ida_simple_get fails")
Cc: <stable@vger.kernel.org>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>
Signed-off-by: NBartosz Golaszewski <bgolaszewski@baylibre.com>

Add GPIO support for Fintek F81865 chip.

Datasheet: http://www.hardwaresecrets.com/datasheets/F81865_V028P.pdfSigned-off-by: NPetteri Jokinen <petteri@kiho.fi>
Signed-off-by: NBartosz Golaszewski <bgolaszewski@baylibre.com>

Export MODULE_DEVICE_TABLE since the driver can be built as a module.
Signed-off-by: NMian Yousaf Kaukab <ykaukab@suse.de>
Signed-off-by: NBartosz Golaszewski <bgolaszewski@baylibre.com>

After the previous patch the two last parameters of
pca953x_recalc_addr() are unused and so can be dropped.
Tested-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>
Reviewed-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: NUwe Kleine-König <u.kleine-koenig@pengutronix.de>
Signed-off-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: NBartosz Golaszewski <bgolaszewski@baylibre.com>

Some of the chips supported by the pca953x driver need the most
significant bit in the address word set to automatically increment the
address pointer on subsequent reads and writes (example: PCA9505). With
this bit unset the same register is read multiple times on a multi-byte
read sequence. Other chips must not have this bit set and autoincrement
always (example: PCA9555).

Up to now this AI bit was interpreted to be part of the address, which
resulted in inconsistent regmap caching when a register was written with
AI set and then read without it. This happened for the PCA9505 in
pca953x_gpio_set_multiple() where pca953x_read_regs() bulk read from the
cache for registers 0x8-0xc and then wrote to registers 0x88-0x8c. (Side
note: reading 5 values from offset 0x8 yiels OP0 5 times because AI must
be set to get OP0-OP4, which is another bug that is resolved here as a
by-product.) The same problem happens when calls to gpio_set_value() and
gpio_set_array_value() were mixed.

With this patch the AI bit is always set for chips that support it. This
works as there are no code locations that make use of the behaviour with
AI unset (for the chips that support it).

Note that the call to pca953x_setup_gpio() had to be done a bit earlier
to make the NBANK macro work.

The history of this bug is a bit complicated. Commit b32cecb4
("gpio: pca953x: Extract the register address mangling to single
function") changed which chips and functions are affected. Commit
3b00691c ("gpio: pca953x: hack to fix 24 bit gpio expanders") used
some duct tape to make the driver at least appear to work. Commit
49427232 ("gpio: pca953x: Perform basic regmap conversion")
introduced the caching. Commit b4818afe ("gpio: pca953x: Add
set_multiple to allow multiple bits to be set in one write.") introduced
the .set_multiple() callback which didn't work for chips that need the
AI bit which was fixed later for some chips in 8958262a ("gpio:
pca953x: Repair multi-byte IO address increment on PCA9575"). So I'm
sorry, I don't know which commit I should pick for a Fixes: line.
Tested-by: NMarcel Gudert <m.gudert@eckelmann.de>
Signed-off-by: NUwe Kleine-König <u.kleine-koenig@pengutronix.de>
Tested-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>
Reviewed-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: NBartosz Golaszewski <bgolaszewski@baylibre.com>

The commit 96d7c7b3 ("gpio: gpio-pca953x, Add get_multiple function")
basically did everything wrong from style and code reuse perspective, i.e.
- it didn't utilize existing PCA953x internal helpers
- it didn't utilize bitmap API
- it misses the point that ilog2(), besides that BANK_SFT is useless,
  can be used in macros
- it has indentation issues.

Rewrite the function completely.

Cc: Paul Thomas <pthomas8589@gmail.com>
Signed-off-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: NBartosz Golaszewski <bgolaszewski@baylibre.com>

Fix a spelling typo in gpio-mm-lantiq.c by codespell
s/dont/don't/

Cc: Andy Shevchenko <andy.shevchenko@gmail.com>
Signed-off-by: NDejin Zheng <zhengdejin5@gmail.com>
Link: https://lore.kernel.org/r/20200424154103.10311-3-zhengdejin5@gmail.comSigned-off-by: NLinus Walleij <linus.walleij@linaro.org>

The driver currently leaves GPIO IRQs unmasked even when the GPIO IRQ
client has released the GPIO IRQ. This allows the HW to raise IRQs, and
SW to process them, after shutdown. Fix this by masking the IRQ when it's
shut down. This is usually taken care of by the irqchip core, but since
this driver has a custom irq_shutdown implementation, it must do this
explicitly itself.
Signed-off-by: NStephen Warren <swarren@nvidia.com>
Link: https://lore.kernel.org/r/20200427232605.11608-1-swarren@wwwdotorg.orgSigned-off-by: NLinus Walleij <linus.walleij@linaro.org>

In case of error, the function devm_ioremap() returns NULL pointer not
ERR_PTR(). The IS_ERR() test in the return value check should be
replaced with NULL test.
Signed-off-by: NWei Yongjun <weiyongjun1@huawei.com>
Link: https://lore.kernel.org/r/20200427110829.154785-1-weiyongjun1@huawei.comSigned-off-by: NLinus Walleij <linus.walleij@linaro.org>

The symbol 'gpio_of_notifier' doesn't exist without both CONFIG_OF_GPIO
and CONFIG_OF_DYNAMIC enabled, but is referenced when only
CONFIG_OF_DYNAMIC is enabled.

This broke building with 'make ARCH=um allyesconfig':
---------------
/usr/bin/ld: drivers/gpio/gpiolib.o: in function `gpiolib_dev_init':
./drivers/gpio/gpiolib.c:5293: undefined reference to `gpio_of_notifier'
collect2: error: ld returned 1 exit status
---------------

Fixes: 63636d95 ("gpio: of: Add DT overlay support for GPIO hogs")
Signed-off-by: NDavid Gow <davidgow@google.com>
Reviewed-by: NGeert Uytterhoeven <geert+renesas@glider.be>
Link: https://lore.kernel.org/r/20200425044655.166257-1-davidgow@google.comSigned-off-by: NLinus Walleij <linus.walleij@linaro.org>