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>

Some DT authors (including myself) have messed up the length of
gpio-line-names and made it longer than it should be. Add a warning here
so that developers can figure out that they've messed up their DT and
should fix it.

Cc: Alexandru M Stan <amstan@chromium.org>
Signed-off-by: NStephen Boyd <swboyd@chromium.org>
Signed-off-by: NBartosz Golaszewski <bgolaszewski@baylibre.com>

This driver uses its own locking but regmap silently uses a mutex for
all operations too. Add the option to disable locking to the regmap
config struct.
Signed-off-by: NBartosz Golaszewski <bgolaszewski@baylibre.com>
Reviewed-by: NGeert Uytterhoeven <geert+renesas@glider.be>
Tested-by: NGeert Uytterhoeven <geert+renesas@glider.be>
Acked-by: NLinus Walleij <linus.walleij@linaro.org>

Implement a get_multiple function for gpio-pca953x. If a driver
leaves get_multiple unimplemented then gpio_chip_get_multiple()
in gpiolib.c takes care of it by calling chip->get() as needed.
For i2c chips this is very inefficient. For example if you do an
8-bit read then instead of a single i2c transaction there are
8 transactions reading the same byte!
Signed-off-by: NPaul Thomas <pthomas8589@gmail.com>
Acked-by: NLinus Walleij <linus.walleij@linaro.org>
Signed-off-by: NBartosz Golaszewski <bgolaszewski@baylibre.com>

When using GPIO expanders attached to I2C ports, their set_config function
needs to be passed a config setting which contains options to enable pull
up or pull down bias feature.  In order to set this config properly,
the gpio parser needs to handle GPIO_PULL_UP and GPIO_PULL_DOWN.

This patch enables the flags corresponding to GPIO_PULL_UP and
GPIO_PULL_DOWN.
Signed-off-by: NAdam Ford <aford173@gmail.com>
Signed-off-by: NBartosz Golaszewski <bgolaszewski@baylibre.com>

Enable building the PL061 GPIO driver as a module.

This does change the initcall level when built-in. This shouldn't be a
problem as any user should support deferred probe by now. A scan of DT
based platforms at least didn't reveal any users that would be a
problem.

Cc: Linus Walleij <linus.walleij@linaro.org>
Cc: Bartosz Golaszewski <bgolaszewski@baylibre.com>
Cc: linux-gpio@vger.kernel.org
Signed-off-by: NRob Herring <robh@kernel.org>
Signed-off-by: NBartosz Golaszewski <bgolaszewski@baylibre.com>

It appears at least two drivers has a lot of duplication code in
GPIO subsystem. To avoid adding more and get rid of existing duplication
extend TODO.
Signed-off-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: NBartosz Golaszewski <bgolaszewski@baylibre.com>

xgene-sb is setup to be a hierarchical IRQ chip with the GIC as the
parent chip. xgene_gpio_sb_to_irq() currently sets the default IRQ type
to IRQ_TYPE_NONE, which the GIC loudly complains about with a WARN_ON().
Let's set the initial default to a sane value (IRQ_TYPE_EDGE_RISING)
that was determined by decoding the ACPI tables on affected hardware:

    Device (_SB.GPSB)
    {
        Name (_HID, "APMC0D15")  // _HID: Hardware ID
        Name (_CID, "APMC0D15")  // _CID: Compatible ID
        Name (_UID, "GPIOSB")  // _UID: Unique ID
        ...
        Name (_CRS, ResourceTemplate ()  // _CRS: Current Resource Settings
        {
            ...
            Interrupt (ResourceConsumer, Edge, ActiveHigh, Exclusive, ,, )
            {
                0x00000048,
            }
            ...
        }
    }

This can be overridden later as needed with irq_set_irq_type().
Signed-off-by: NBrian Masney <bmasney@redhat.com>
Signed-off-by: NBartosz Golaszewski <bgolaszewski@baylibre.com>

This reverts commit 0f5cb8cc.

This commit will cause below warnings, since our EIC controller can support
differnt banks on different Spreadtrum SoCs, and each bank has its own base
address, we will get invalid resource warning if the bank number is less than
SPRD_EIC_MAX_BANK on some Spreadtrum SoCs.

So we should not use devm_platform_ioremap_resource() here to remove the
warnings.

[    1.118508] sprd-eic 40210000.gpio: invalid resource
[    1.118535] sprd-eic 40210000.gpio: invalid resource
[    1.119034] sprd-eic 40210080.gpio: invalid resource
[    1.119055] sprd-eic 40210080.gpio: invalid resource
[    1.119462] sprd-eic 402100a0.gpio: invalid resource
[    1.119482] sprd-eic 402100a0.gpio: invalid resource
[    1.119893] sprd-eic 402100c0.gpio: invalid resource
[    1.119913] sprd-eic 402100c0.gpio: invalid resource
Signed-off-by: NBaolin Wang <baolin.wang7@gmail.com>
Link: https://lore.kernel.org/r/8d3579f4b49bb675dc805035960f24852898be28.1585734060.git.baolin.wang7@gmail.comSigned-off-by: NLinus Walleij <linus.walleij@linaro.org>

The gpiochip_generic_request() and gpiochip_generic_free() functions can
now deal properly with chips that don't have any pin-ranges defined, so
they can be assigned unconditionally.
Suggested-by: NLinus Walleij <linus.walleij@linaro.org>
Signed-off-by: NThierry Reding <treding@nvidia.com>
Link: https://lore.kernel.org/r/20200401200527.2982450-1-thierry.reding@gmail.comSigned-off-by: NLinus Walleij <linus.walleij@linaro.org>

There is struct gpio *gc, *chip and *gpiochip, and yes
I am responsible for some of the inconsistencies. I want
this to be just gc everywhere for minimizing cognitive
resistance when reading the code: more compact function
signatures and less clutter.

Purely syntactic changes intended. No semantic effects.
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
Link: https://lore.kernel.org/r/20200329140405.52276-1-linus.walleij@linaro.orgSigned-off-by: NLinus Walleij <linus.walleij@linaro.org>

Do not use the struct gpio_device's .pin_ranges field if the PINCTRL
Kconfig symbol is not selected to avoid build failures.

Fixes: 2ab73c6d ("gpio: Support GPIO controllers without pin-ranges")
Reported-by: NStephen Rothwell <sfr@canb.auug.org.au>
Reported-by: Nkbuild test robot <lkp@intel.com>
Signed-off-by: NThierry Reding <treding@nvidia.com>
Link: https://lore.kernel.org/r/20200330090257.2332864-1-thierry.reding@gmail.comReviewed-by: NGeert Uytterhoeven <geert@linux-m68k.org>
Tested-by: NGeert Uytterhoeven <geert@linux-m68k.org>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

gpio_set_bias() no longer uses the passed gpio_chip pointer parameter.
Remove it.
Signed-off-by: NGeert Uytterhoeven <geert+renesas@glider.be>
Link: https://lore.kernel.org/r/20200325100439.14000-3-geert+renesas@glider.beSigned-off-by: NLinus Walleij <linus.walleij@linaro.org>

All callers of gpio_set_config() have to convert a gpio_desc to a
gpio_chip and offset.  Avoid these duplicated conversion steps by
letting gpio_set_config() take a gpio_desc pointer directly.
Signed-off-by: NGeert Uytterhoeven <geert+renesas@glider.be>
Link: https://lore.kernel.org/r/20200325100439.14000-2-geert+renesas@glider.beSigned-off-by: NLinus Walleij <linus.walleij@linaro.org>

The GPIO Aggregator will need a method to forward a .set_config() call
to its parent gpiochip.  This requires obtaining the gpio_chip and
offset for a given gpio_desc.  While gpiod_to_chip() is public,
gpio_chip_hwgpio() is not, so there is currently no method to obtain the
needed GPIO offset parameter.

Hence introduce a public gpiod_set_config() helper, which invokes the
.set_config() callback through a gpio_desc pointer, like is done for
most other gpio_chip callbacks.

Rewrite the existing gpiod_set_debounce() helper as a wrapper around
gpiod_set_config(), to avoid duplication.
Signed-off-by: NGeert Uytterhoeven <geert+renesas@glider.be>
Link: https://lore.kernel.org/r/20200324135653.6676-5-geert+renesas@glider.beSigned-off-by: NLinus Walleij <linus.walleij@linaro.org>

Use a different markup for the ERR_PTR, as %FOO doesn't work
if there are parenthesis. So, use, instead:

	``ERR_PTR(-EINVAL)``

This fixes the following warning:

	./drivers/gpio/gpiolib.c:139: WARNING: Inline literal start-string without end-string.
Signed-off-by: NMauro Carvalho Chehab <mchehab+huawei@kernel.org>
Link: https://lore.kernel.org/r/51197e3568f073e22c280f0584bfa20b44436708.1584456635.git.mchehab+huawei@kernel.orgReviewed-by: NBartosz Golaszewski <bgolaszewski@baylibre.com>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

The GG.0 and GG.1 GPIOs serve as CLKREQ and RST pins, respectively, for
PCIe controller 5 on Tegra194. When this controller is configured in
endpoint mode, these pins need to be used as GPIOs by the PCIe endpoint
driver. Typically the mode programming of these pins (GPIO vs. SFIO) is
performed by early boot firmware to ensure that the configuration is
consistent.

However, the GG.0 and GG.1 pins are part of a special power partition
that is not enabled during early boot, and hence the early boot firmware
cannot program these pins to be GPIOs (they are SFIO by default). Adding
them as pin ranges for the pin controller allows the pin controller to
be involved when these pins are requested as GPIOs and allows the proper
programming to take place.
Signed-off-by: NThierry Reding <treding@nvidia.com>
Link: https://lore.kernel.org/r/20200319122737.3063291-4-thierry.reding@gmail.comTested-by: NVidya Sagar <vidyas@nvidia.com>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

Add support for Tegra SoC generations to specify a list of pin ranges
that map GPIOs to ranges of pins in the pin controller.
Signed-off-by: NThierry Reding <treding@nvidia.com>
Link: https://lore.kernel.org/r/20200319122737.3063291-3-thierry.reding@gmail.comTested-by: NVidya Sagar <vidyas@nvidia.com>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

Wake gpiochip_generic_request() call into the pinctrl helpers only if a
GPIO controller had any pin-ranges assigned to it. This allows a driver
to unconditionally use this helper if it supports multiple devices of
which only a subset have pin-ranges assigned to them.
Signed-off-by: NThierry Reding <treding@nvidia.com>
Link: https://lore.kernel.org/r/20200319122737.3063291-2-thierry.reding@gmail.comTested-by: NVidya Sagar <vidyas@nvidia.com>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

The default handling of the gpio-line-names property by the
gpiolib-of implementation does not work with the multiple
gpiochip banks per device structure used by the gpio-brcmstb
driver.

This commit adds driver level support for the device tree
property so that GPIO lines can be assigned friendly names.
Signed-off-by: NDoug Berger <opendmb@gmail.com>
Link: https://lore.kernel.org/r/1583780521-45702-1-git-send-email-opendmb@gmail.comAcked-by: NGregory Fong <gregory.0xf0@gmail.com>
Acked-by: NFlorian Fainelli <f.fainelli@gmail.com>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

Since name == NULL can't ever match, move the check out of
IRQ-disabled region.
Signed-off-by: NMichał Mirosław <mirq-linux@rere.qmqm.pl>
Signed-off-by: NBartosz Golaszewski <bgolaszewski@baylibre.com>

DSET/DCLR registers only works on output pins. Add corresponding
BGPIOF_NO_SET_ON_INPUT flag to bgpio_init call to fix direction_out
behavior.
Signed-off-by: NChuanhong Guo <gch981213@gmail.com>
Tested-by: NRené van Dorst <opensource@vdorst.com>
Reviewed-by: NSergio Paracuellos <sergio.paracuellos@gmail.com>
Signed-off-by: NBartosz Golaszewski <bgolaszewski@baylibre.com>

Some gpio controllers ignores pin value writing when that pin is
configured as input mode. As a result, bgpio_dir_out should set
pin to output before configuring pin values or gpio pin values
can't be set up properly.
Introduce two variants of bgpio_dir_out: bgpio_dir_out_val_first
and bgpio_dir_out_dir_first, and assign direction_output according
to a new flag: BGPIOF_NO_SET_ON_INPUT.
Signed-off-by: NChuanhong Guo <gch981213@gmail.com>
Tested-by: NRené van Dorst <opensource@vdorst.com>
Reviewed-by: NSergio Paracuellos <sergio.paracuellos@gmail.com>
Signed-off-by: NBartosz Golaszewski <bgolaszewski@baylibre.com>

platform_get_irq() will generate an error message if the requested irq
is not present

  mvebu-gpio f1010140.gpio: IRQ index 3 not found

use platform_get_irq_optional() to avoid the error message being
generated.
Signed-off-by: NChris Packham <chris.packham@alliedtelesis.co.nz>
Acked-by: NUwe Kleine-König <u.kleine-koenig@pengutronix.de>
Signed-off-by: NBartosz Golaszewski <bgolaszewski@baylibre.com>

Add COMPILE_TEST support to GPIO_MXS driver for better compile
testing coverage.
Signed-off-by: NAnson Huang <Anson.Huang@nxp.com>
Reported-by: Nkbuild test robot <lkp@intel.com>
Signed-off-by: NBartosz Golaszewski <bgolaszewski@baylibre.com>

Add COMPILE_TEST support to GPIO_MXC driver for better compile
testing coverage.
Signed-off-by: NAnson Huang <Anson.Huang@nxp.com>
Signed-off-by: NBartosz Golaszewski <bgolaszewski@baylibre.com>

Existing (irq < 0) condition is always false because adev->irq has unsigned
type and contains 0 in case of failed irq_of_parse_and_map(). Up to now all
the mapping errors were silently ignored.

Seems that repairing this check would be backwards-incompatible and might
break the probe() for the implementations without IRQ support. Therefore
warn the user instead.
Signed-off-by: NAlexander Sverdlin <alexander.sverdlin@nokia.com>
Signed-off-by: NBartosz Golaszewski <bgolaszewski@baylibre.com>

There are at least 3 models of the HP x2 10 models:

Bay Trail SoC + AXP288 PMIC
Cherry Trail SoC + AXP288 PMIC
Cherry Trail SoC + TI PMIC

Like on the other HP x2 10 models we need to ignore wakeup for ACPI GPIO
events on the external embedded-controller pin to avoid spurious wakeups
on the HP x2 10 CHT + AXP288 model too.

This commit adds an extra DMI based quirk for the HP x2 10 CHT + AXP288
model, ignoring wakeups for ACPI GPIO events on the EC interrupt pin
on this model. This fixes spurious wakeups from suspend on this model.

Fixes: aa23ca3d ("gpiolib: acpi: Add honor_wakeup module-option + quirk mechanism")
Reported-and-tested-by: NMarc Lehmann <schmorp@schmorp.de>
Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Link: https://lore.kernel.org/r/20200302111225.6641-4-hdegoede@redhat.comAcked-by: NMika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

These two devres functions devm_gpiochip_[add|remove]()
were in the wrong file. They should be in gpiolib-devres.c
not gpiolib.c.

Link: https://lore.kernel.org/r/20200313081522.35143-1-linus.walleij@linaro.orgReviewed-by: NBartosz Golaszewski <bgolaszewski@baylibre.com>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

Commit aa23ca3d ("gpiolib: acpi: Add honor_wakeup module-option +
quirk mechanism") was added to deal with spurious wakeups on one specific
model of the HP x2 10 series. In the mean time I have learned that there
are at least 3 different HP x2 10 models:

Bay Trail SoC + AXP288 PMIC
Cherry Trail SoC + AXP288 PMIC
Cherry Trail SoC + TI PMIC

And the original quirk is only correct for (and only matches the)
Cherry Trail SoC + TI PMIC model.

The Bay Trail SoC + AXP288 PMIC model has different DMI strings, has
the external EC interrupt on a different GPIO pin and only needs to ignore
wakeups on the EC interrupt, the INT0002 device works fine on this model.

This commit adds an extra DMI based quirk for the HP x2 10 BYT + AXP288
model, ignoring wakeups for ACPI GPIO events on the EC interrupt pin
on this model. This fixes spurious wakeups from suspend on this model.

Fixes: aa23ca3d ("gpiolib: acpi: Add honor_wakeup module-option + quirk mechanism")
Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Link: https://lore.kernel.org/r/20200302111225.6641-3-hdegoede@redhat.comAcked-by: NMika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

Commit aa23ca3d ("gpiolib: acpi: Add honor_wakeup module-option +
quirk mechanism") was added to deal with spurious wakeups on one specific
model of the HP x2 10 series.

The approach taken there was to add a bool controlling wakeup support for
all ACPI GPIO events. This was sufficient for the specific HP x2 10 model
the commit was trying to fix, but in the mean time other models have
turned up which need a similar workaround to avoid spurious wakeups from
suspend, but only for one of the pins on which the ACPI tables request
ACPI GPIO events.

Since the honor_wakeup option was added to be able to ignore wake events,
the name was perhaps not the best, this commit renames it to ignore_wake
and changes it to a string with the following format:
gpiolib_acpi.ignore_wake=controller@pin[,controller@pin[,...]]

This allows working around spurious wakeup issues on a per pin basis.

This commit also reworks the existing quirk for the HP x2 10 so that
it functions as before.

Note:
-This removes the honor_wakeup parameter. This has only been upstream for
 a short time and to the best of my knowledge there are no users using
 this module parameter.

-The controller@pin[,controller@pin[,...]] syntax is based on an existing
 kernel module parameter using the same controller@pin format. That version
 uses ';' as separator, but in practice that is problematic because grub2
 cannot handle this without taking special care to escape the ';', so here
 we are using a ',' as separator instead which does not have this issue.

Fixes: aa23ca3d ("gpiolib: acpi: Add honor_wakeup module-option + quirk mechanism")
Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Link: https://lore.kernel.org/r/20200302111225.6641-2-hdegoede@redhat.comAcked-by: NMika Westerberg <mika.westerberg@linux.intel.com>
Reviewed-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

Commit aa23ca3d ("gpiolib: acpi: Add honor_wakeup module-option +
quirk mechanism") added a quirk for some models of the HP x2 10 series.

There are 2 issues with the comment describing the quirk:
1) The comment claims the DMI quirk applies to all Cherry Trail based HP x2
   10 models. In the mean time I have learned that there are at least 3
   models of the HP x2 10 models:

   Bay Trail SoC + AXP288 PMIC
   Cherry Trail SoC + AXP288 PMIC
   Cherry Trail SoC + TI PMIC

   And this quirk's DMI matches only match the Cherry Trail SoC + TI PMIC
   SoC, which is good because we want a slightly different quirk for the
   others. This commit updates the comment to make it clear that the quirk
   is only for the Cherry Trail SoC + TI PMIC models.

2) The comment says that it is ok to disable wakeup on all ACPI GPIO event
   handlers, because there is only the one for the embedded-controller
   events. This is not true, there also is a handler for the special
   INT0002 device which is related to USB wakeups. We need to also disable
   wakeups on that one because the device turns of the USB-keyboard built
   into the dock when closing the lid. The XHCI controller takes a while
   to notice this, so it only notices it when already suspended, causing
   a spurious wakeup because of this. So disabling wakeup on all handlers
   is the right thing to do, but not because there only is the one handler
   for the EC events. This commit updates the comment to correctly reflect
   this.

Fixes: aa23ca3d ("gpiolib: acpi: Add honor_wakeup module-option + quirk mechanism")
Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Link: https://lore.kernel.org/r/20200302111225.6641-1-hdegoede@redhat.comAcked-by: NMika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

The implementation if .irq_disable() which kicks in between
the gpiolib and the driver is not properly mimicking the
expected semantics of the irqchip core: the irqchip will
call .irq_disable() if that exists, else it will call
mask_irq() which first checks if .irq_mask() is defined
before calling it.

Since we are calling it unconditionally, we get this bug
from drivers/pinctrl/qcom/pinctrl-ssbi-gpio.c, as it only
defines .irq_mask_ack and not .irq_mask:

  Unable to handle kernel NULL pointer dereference at virtual address 00000000
  pgd = (ptrval)
  (...)
  PC is at 0x0
  LR is at gpiochip_irq_disable+0x20/0x30

Fix this by only calling .irq_mask() if it exists.

Cc: Brian Masney <masneyb@onstation.org>
Cc: Hans Verkuil <hans.verkuil@cisco.com>
Cc: stable@vger.kernel.org
Reviewed-by: NBartosz Golaszewski <bgolaszewski@baylibre.com>
Fixes: 461c1a7d ("gpiolib: override irq_enable/disable")
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
Link: https://lore.kernel.org/r/20200306132326.1329640-1-linus.walleij@linaro.org

This reverts commit a522f1d0.

With cpu_pm handling fixed for omaps, and with gpio-omap now returning
notify error on pending interrupts, we can drop the old workaround for
seeing if there may be pending edge interrupts.

Depends-on: ARM: OMAP2+: Handle errors for cpu_pm
Depends-on: gpio: omap: Block idle on pending gpio interrupts
Cc: Aaro Koskinen <aaro.koskinen@iki.fi>
Cc: Grygorii Strashko <grygorii.strashko@ti.com>
Cc: Keerthy <j-keerthy@ti.com>
Cc: Ladislav Michl <ladis@linux-mips.org>
Cc: Peter Ujfalusi <peter.ujfalusi@ti.com>
Cc: Russell King <rmk+kernel@armlinux.org.uk>
Cc: Tero Kristo <t-kristo@ti.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
Link: https://lore.kernel.org/r/20200304225433.37336-4-tony@atomide.comSigned-off-by: NLinus Walleij <linus.walleij@linaro.org>

With the SoC cpuidle handling fixed for cpu_pm, we can now start to
return NOTIFY_BAD if there there are pending gpio interrupts.

This way the deeper SoC idle states can get blocked, and gpio latency
is improved in some cases. Note that this will not help with the
latency if the SoC has already entered a deeper idle state.

Note that this patch depends on cpu_pm properly handling the errors
returned by notifiers. For omap variants, this is fixed with patch
"ARM: OMAP2+: Handle errors for cpu_pm".

Cc: Dave Gerlach <d-gerlach@ti.com>
Cc: Grygorii Strashko <grygorii.strashko@ti.com>
Cc: Keerthy <j-keerthy@ti.com>
Cc: Ladislav Michl <ladis@linux-mips.org>
Cc: Russell King <rmk+kernel@armlinux.org.uk>
Cc: Tero Kristo <t-kristo@ti.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>
Link: https://lore.kernel.org/r/20200304225433.37336-3-tony@atomide.comSigned-off-by: NLinus Walleij <linus.walleij@linaro.org>

This patch adds support for the GPIO controller used by
Mellanox BlueField 2 SOCs.
Signed-off-by: NAsmaa Mnebhi <Asmaa@mellanox.com>
Link: https://lore.kernel.org/r/1680de9eb6d2b8855228dde9a2dd065f0dcbe1fb.1583182325.git.Asmaa@mellanox.comSigned-off-by: NLinus Walleij <linus.walleij@linaro.org>

The optimization to check for requested lines actually optimized for the
uncomon error case, where one of the GPIO lines is still in use.
Hence the error message must be printed when the loop is terminated
early, not when it went through all available GPIO lines.

Fixes: 869233f8 ("gpiolib: Optimize gpiochip_remove() when check for requested line")
Signed-off-by: NGeert Uytterhoeven <geert+renesas@glider.be>
Link: https://lore.kernel.org/r/20200302082448.11795-1-geert+renesas@glider.beAcked-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

When operating on the bits of watched_lines bitmap, we're using
desc_to_gpio() which returns the GPIO number from the global numberspace.
This leads to all sorts of memory corruptions and invalid behavior. We
should switch to using gpio_chip_hwgpio() instead.

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

Fix the field having a bit cleared by the unwatch ioctl().

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

Rename 'event' to 'ge' to be consistent with other use.
Signed-off-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: NBartosz Golaszewski <bgolaszewski@baylibre.com>