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>

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>

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>

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>

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>

Here are the following optimizations have been done:
 - break the loop after first found requested line
  - due to above, drop redundant boolean variable
 - replace open coded variant of gpiochip_is_requested()
  - due to above, drop redundant pointer to struct gpio_desc
 - use 'unsigned int' instead of 'unsigned' for loop counter

Note, pointer to struct gpio_chip followed by pointer to struct gpio_device
is still valid, back link is not.
Signed-off-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>
Link: https://lore.kernel.org/r/20200225114725.839-1-andriy.shevchenko@linux.intel.comSigned-off-by: NLinus Walleij <linus.walleij@linaro.org>

As GPIO hogs are configured at GPIO controller initialization time,
adding/removing GPIO hogs in DT overlays does not work.

Add support for GPIO hogs described in DT overlays by registering an OF
reconfiguration notifier, to handle the addition and removal of GPIO hog
subnodes to/from a GPIO controller device node.

Note that when a GPIO hog device node is being removed, its "gpios"
properties is no longer available, so we have to keep track of which
node a hog belongs to, which is done by adding a pointer to the hog's
device node to struct gpio_desc.
Signed-off-by: NGeert Uytterhoeven <geert+renesas@glider.be>
Link: https://lore.kernel.org/r/20200220130149.26283-3-geert+renesas@glider.beReviewed-by: NFrank Rowand <frank.rowand@sony.com>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

The existing use of ktime_get_real_ns() in the timestamps from
the GPIO events is dubious.

We have had several discussions about this timestamp, and it is
unclear whether userspace has ever taken into account that a
timestamp from ktime_get_real_ns() can actually move backwards
in time relative the previous timetamp, and userspace is more
likely to expect a monotonic counter.

Background:
https://lore.kernel.org/linux-gpio/CAK8P3a1Skvm48sje8FNDPLYqyz9Lf8q0qX1QETWtyZTxuX4k1g@mail.gmail.com/
https://marc.info/?l=linux-gpio&m=151661955709074&w=2

The change is ABI incompatible, but incompatible in a way that
is IMO more likely to fix future bugs rather than break current
userspace. To the best of my knowledge all userspace expects
a monotonic timestamp and users are just lucky that they very
seldom move backwards in time.

Cc: Arnd Bergmann <arnd@arndb.de>
Acked-by: NBartosz Golaszewski <bgolaszewski@baylibre.com>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

Whenever retrieving a descriptor from a gpiochip: use the provided
helper which checks for errors.
Signed-off-by: NBartosz Golaszewski <bgolaszewski@baylibre.com>
Link: https://lore.kernel.org/r/20200219094702.6463-1-brgl@bgdev.plSigned-off-by: NLinus Walleij <linus.walleij@linaro.org>

Currently there is no way for user-space to be informed about changes
in status of GPIO lines e.g. when someone else requests the line or its
config changes. We can only periodically re-read the line-info. This
is fine for simple one-off user-space tools, but any daemon that provides
a centralized access to GPIO chips would benefit hugely from an event
driven line info synchronization.

This patch adds a new ioctl() that allows user-space processes to reuse
the file descriptor associated with the character device for watching
any changes in line properties. Every such event contains the updated
line information.

Currently the events are generated on three types of status changes: when
a line is requested, when it's released and when its config is changed.
The first two are self-explanatory. For the third one: this will only
happen when another user-space process calls the new SET_CONFIG ioctl()
as any changes that can happen from within the kernel (i.e.
set_transitory() or set_debounce()) are of no interest to user-space.
Signed-off-by: NBartosz Golaszewski <bgolaszewski@baylibre.com>
Reviewed-by: NLinus Walleij <linus.walleij@linaro.org>

We'll soon be filling out the gpioline_info structure in multiple
places. Add a separate function that given a gpio_desc sets all relevant
fields.
Signed-off-by: NBartosz Golaszewski <bgolaszewski@baylibre.com>
Reviewed-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>

Currently if the line-event kfifo is full, we just silently drop any new
events. Add a ratelimited debug message so that we at least have some
trace in the kernel log of event overflow.
Signed-off-by: NBartosz Golaszewski <bgolaszewski@baylibre.com>

The read_lock mutex is supposed to prevent collisions between reading
and writing to the line event kfifo but it's actually only taken when
the events are being read from it.

Drop the mutex entirely and reuse the spinlock made available to us in
the waitqueue struct. Take the lock whenever the fifo is modified or
inspected. Drop the call to kfifo_to_user() and instead first extract
the new element from kfifo when the lock is taken and only then pass
it on to the user after the spinlock is released.
Signed-off-by: NBartosz Golaszewski <bgolaszewski@baylibre.com>
Reviewed-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>

Remove unnecessary argument when setting PIN_CONFIG_BIAS_DISABLE. No
argument is expected by pinctrl, so removing it should be harmless.

Fixes: 2148ad77 ("gpiolib: add support for disabling line bias")
Signed-off-by: NKent Gibson <warthog618@gmail.com>
Signed-off-by: NBartosz Golaszewski <bgolaszewski@baylibre.com>

Commit d90f3685 ("gpiolib: have a single place of calling
set_config()") introduced a regression where we don't pass the right
variable as argument to the set_config() callback of gpio driver from
gpio_set_config(). After reverting two additional patches that came
on top of it - this addresses the issue by changing the type of the last
argument of gpio_do_set_config() to unsigned long and making sure the
packed config variable is actually used in gpio_set_config().

Fixes: d90f3685 ("gpiolib: have a single place of calling set_config()")
Signed-off-by: NBartosz Golaszewski <bgolaszewski@baylibre.com>
Tested-by: NGuenter Roeck <linux@roeck-us.net>

This reverts commit e5e42ad2.

This patch came on top of another patch that introduced a regression.
Revert it before addressing the culprit.
Signed-off-by: NBartosz Golaszewski <bgolaszewski@baylibre.com>
Tested-by: NGuenter Roeck <linux@roeck-us.net>

This reverts commit d18fddff.

This patch came on top of another patch that introduced a regression.
Revert it before addressing the culprit.
Signed-off-by: NBartosz Golaszewski <bgolaszewski@baylibre.com>
Tested-by: NGuenter Roeck <linux@roeck-us.net>

'PTR_ERR(p) == -E*' is a stronger condition than IS_ERR(p).
Hence, IS_ERR(p) is unneeded.

The semantic patch that generates this commit is as follows:

// <smpl>
@@
expression ptr;
constant error_code;
@@
-IS_ERR(ptr) && (PTR_ERR(ptr) == - error_code)
+PTR_ERR(ptr) == - error_code
// </smpl>

Link: http://lkml.kernel.org/r/20200106045833.1725-1-masahiroy@kernel.orgSigned-off-by: NMasahiro Yamada <masahiroy@kernel.org>
Cc: Julia Lawall <julia.lawall@lip6.fr>
Acked-by: Stephen Boyd <sboyd@kernel.org> [drivers/clk/clk.c]
Acked-by: Bartosz Golaszewski <bgolaszewski@baylibre.com> [GPIO]
Acked-by: Wolfram Sang <wsa@the-dreams.de> [drivers/i2c]
Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> [acpi/scan.c]
Acked-by: NRob Herring <robh@kernel.org>
Cc: Eric Biggers <ebiggers@kernel.org>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

If a driver consuming the GPIO chip is being probed at the same time as
the GPIO driver is registering the chip, it is possible for the
consuming driver to see the ->descs array in an uninitialised state.
For example, the gpio-keys-polled driver can fail like this:

    kernel: gpiod_request: invalid GPIO (no device)
    kernel: gpio-keys-polled PRP0001:07: failed to get gpio: -22
    kernel: gpio-keys-polled: probe of PRP0001:07 failed with error -22

This patch makes gpiochip_add() hold the lock protecting gpio_devices
until it has finished setting desc->gdev on the newly inserted list
entry.
Signed-off-by: NDan Callaghan <dan.callaghan@opengear.com>
Link: https://lore.kernel.org/r/20200121001216.15964-1-dan.callaghan@opengear.comSigned-off-by: NLinus Walleij <linus.walleij@linaro.org>

gpiochip_set_chained_irqchip() would assign a chained handler
to a GPIO chip. We now populate struct gpio_irq_chip for all
chained GPIO irqchips so drop this function.

Cc: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
Link: https://lore.kernel.org/r/20200113220800.77817-1-linus.walleij@linaro.orgSigned-off-by: NLinus Walleij <linus.walleij@linaro.org>

In the current codes, the following 3 lines would be output to
the console for each irq line.
  gpio gpiochip0: (gpio_thunderx): allocate IRQ 10, hwirq 0
  gpio gpiochip0: (gpio_thunderx): found parent hwirq 245784
  gpio gpiochip0: (gpio_thunderx): alloc_irqs_parent for 10 parent hwirq 245784

In general, there are about tens of irq lines for each gpio chip,
and then it would emit so many insignificant log in the boot process.
These infos are more suitable for the dbg purpose. So change these
to the dbg level. With this change, about 200 lines are suppressed
on my Marvell cn96xx board.
Signed-off-by: NKevin Hao <haokexin@gmail.com>
Link: https://lore.kernel.org/r/20200120095625.25164-1-haokexin@gmail.comSigned-off-by: NLinus Walleij <linus.walleij@linaro.org>

gpio_set_config() simply call gpio_do_set_config(),
so remove the duplicated function.
Signed-off-by: NYueHaibing <yuehaibing@huawei.com>
Link: https://lore.kernel.org/r/20200116142927.58908-1-yuehaibing@huawei.comSigned-off-by: NLinus Walleij <linus.walleij@linaro.org>

drivers/gpio/gpiolib.c: In function gpio_set_config:
drivers/gpio/gpiolib.c:3053:16: warning:
 variable config set but not used [-Wunused-but-set-variable]

commit d90f3685 ("gpiolib: have a single place
of calling set_config()") left behind this unused variable.
Reported-by: NHulk Robot <hulkci@huawei.com>
Signed-off-by: NYueHaibing <yuehaibing@huawei.com>
Link: https://lore.kernel.org/r/20200108121117.45060-1-yuehaibing@huawei.comReviewed-by: NBartosz Golaszewski <bgolaszewski@baylibre.com>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

I see the following lockdep splat in the qcom pinctrl driver when
attempting to suspend the device.

 ============================================
 WARNING: possible recursive locking detected
 5.4.2 #2 Tainted: G S
 --------------------------------------------
 cat/6536 is trying to acquire lock:
 ffffff814787ccc0 (&irq_desc_lock_class){-.-.}, at: __irq_get_desc_lock+0x64/0x94

 but task is already holding lock:
 ffffff81436740c0 (&irq_desc_lock_class){-.-.}, at: __irq_get_desc_lock+0x64/0x94

 other info that might help us debug this:
  Possible unsafe locking scenario:

        CPU0
        ----
   lock(&irq_desc_lock_class);
   lock(&irq_desc_lock_class);

  *** DEADLOCK ***

  May be due to missing lock nesting notation

 7 locks held by cat/6536:
  #0: ffffff8140e0c420 (sb_writers#7){.+.+}, at: vfs_write+0xc8/0x19c
  #1: ffffff8121eec480 (&of->mutex){+.+.}, at: kernfs_fop_write+0x128/0x1f4
  #2: ffffff8147cad668 (kn->count#263){.+.+}, at: kernfs_fop_write+0x130/0x1f4
  #3: ffffffd011446000 (system_transition_mutex){+.+.}, at: pm_suspend+0x108/0x354
  #4: ffffff814302b970 (&dev->mutex){....}, at: __device_suspend+0x16c/0x420
  #5: ffffff81436740c0 (&irq_desc_lock_class){-.-.}, at: __irq_get_desc_lock+0x64/0x94
  #6: ffffff81479b8c10 (&pctrl->lock){....}, at: msm_gpio_irq_set_wake+0x48/0x7c

 stack backtrace:
 CPU: 4 PID: 6536 Comm: cat Tainted: G S                5.4.2 #2
 Call trace:
  dump_backtrace+0x0/0x174
  show_stack+0x20/0x2c
  dump_stack+0xdc/0x144
  __lock_acquire+0x52c/0x2268
  lock_acquire+0x1dc/0x220
  _raw_spin_lock_irqsave+0x64/0x80
  __irq_get_desc_lock+0x64/0x94
  irq_set_irq_wake+0x40/0x144
  msm_gpio_irq_set_wake+0x5c/0x7c
  set_irq_wake_real+0x40/0x5c
  irq_set_irq_wake+0x70/0x144
  cros_ec_rtc_suspend+0x38/0x4c
  platform_pm_suspend+0x34/0x60
  dpm_run_callback+0x64/0xcc
  __device_suspend+0x314/0x420
  dpm_suspend+0xf8/0x298
  dpm_suspend_start+0x84/0xb4
  suspend_devices_and_enter+0xbc/0x628
  pm_suspend+0x214/0x354
  state_store+0xb0/0x108
  kobj_attr_store+0x14/0x24
  sysfs_kf_write+0x4c/0x64
  kernfs_fop_write+0x158/0x1f4
  __vfs_write+0x54/0x18c
  vfs_write+0xdc/0x19c
  ksys_write+0x7c/0xe4
  __arm64_sys_write+0x20/0x2c
  el0_svc_common+0xa8/0x160
  el0_svc_compat_handler+0x2c/0x38
  el0_svc_compat+0x8/0x10

This is because the msm_gpio_irq_set_wake() function calls
irq_set_irq_wake() as a backup in case the irq comes in during the path
to idle. Given that we're calling irqchip functions from within an
irqchip we need to set the lockdep class to be different for this child
controller vs. the default one that the parent irqchip gets.

This used to be done before this driver was converted to hierarchical
irq domains in commit e35a6ae0 ("pinctrl/msm: Setup GPIO chip in
hierarchy") via the gpiochip_irq_map() function. With hierarchical irq
domains this function has been replaced by
gpiochip_hierarchy_irq_domain_alloc(). Therefore, set the lockdep class
like was done previously in the irq domain path so we can avoid this
lockdep warning.

Fixes: fdd61a01 ("gpio: Add support for hierarchical IRQ domains")
Cc: Thierry Reding <treding@nvidia.com>
Cc: Brian Masney <masneyb@onstation.org>
Cc: Lina Iyer <ilina@codeaurora.org>
Cc: Marc Zyngier <maz@kernel.org>
Cc: Maulik Shah <mkshah@codeaurora.org>
Signed-off-by: NStephen Boyd <swboyd@chromium.org>
Link: https://lore.kernel.org/r/20200114231103.85641-1-swboyd@chromium.orgSigned-off-by: NLinus Walleij <linus.walleij@linaro.org>

If the gpio's parent irqdomain is a msi irqdomain, we should ignore
the EEXIST error returned by the msi irqdomain because all the msi
interrupts have already been allocated.
Signed-off-by: NKevin Hao <haokexin@gmail.com>
Link: https://lore.kernel.org/r/20200114082821.14015-4-haokexin@gmail.comSigned-off-by: NLinus Walleij <linus.walleij@linaro.org>

Some gpio's parent irqdomain may not use the struct irq_fwspec as
argument, such as msi irqdomain. So rename the callback
populate_parent_fwspec() to populate_parent_alloc_arg() and make it
allocate and populate the specific struct which is needed by the
parent irqdomain.
Signed-off-by: NKevin Hao <haokexin@gmail.com>
Link: https://lore.kernel.org/r/20200114082821.14015-3-haokexin@gmail.comSigned-off-by: NLinus Walleij <linus.walleij@linaro.org>

Unduplicate the offset check by simply calling gpiochip_get_desc() and
checking its return value.
Signed-off-by: NBartosz Golaszewski <bgolaszewski@baylibre.com>
Reviewed-by: NAndy Shevchenko <andy.shevchenko@gmail.com>
Reviewed-by: NLinus Walleij <linus.walleij@linaro.org>

Unduplicate the ngpio check by simply calling gpiochip_get_desc() and
checking its return value.
Signed-off-by: NBartosz Golaszewski <bgolaszewski@baylibre.com>
Reviewed-by: NAndy Shevchenko <andy.shevchenko@gmail.com>
Reviewed-by: NLinus Walleij <linus.walleij@linaro.org>

Unduplicate the ngpio check by simply calling gpiochip_get_desc() and
checking its return value.
Signed-off-by: NBartosz Golaszewski <bgolaszewski@baylibre.com>
Reviewed-by: NAndy Shevchenko <andy.shevchenko@gmail.com>
Reviewed-by: NLinus Walleij <linus.walleij@linaro.org>

gpiochip_get_desc() takes a u16 hwnum, but it turns out most users don't
respect that and usually pass an unsigned int. Since implicit casting to
a smaller type is dangerous - let's change the type of hwnum to unsigned
int in gpiochip_get_desc() and in gpiochip_request_own_desc() where the
size of hwnum is not respected either and who's a user of the former.

This is safe as we then check the hwnum against the number of lines
before proceeding in gpiochip_get_desc().
Signed-off-by: NBartosz Golaszewski <bgolaszewski@baylibre.com>
Reviewed-by: NAndy Shevchenko <andy.shevchenko@gmail.com>
Reviewed-by: NLinus Walleij <linus.walleij@linaro.org>

Instead of calling the gpiochip's set_config() callback directly and
checking its existence every time - just add a new routine that performs
this check internally. Call it in gpio_set_config() and
gpiod_set_transitory(). Also call it in gpiod_set_debounce() and drop
the check for chip->set() as it's irrelevant to this config option.
Signed-off-by: NBartosz Golaszewski <bgolaszewski@baylibre.com>
Reviewed-by: NAndy Shevchenko <andy.shevchenko@gmail.com>
Reviewed-by: NLinus Walleij <linus.walleij@linaro.org>

Checkpatch complains about using 'unsigned' instead of 'unsigned int'.
Signed-off-by: NBartosz Golaszewski <bgolaszewski@baylibre.com>
Reviewed-by: NAndy Shevchenko <andy.shevchenko@gmail.com>
Reviewed-by: NLinus Walleij <linus.walleij@linaro.org>

There's a confusing indention in gpiochip_add_data_with_key(), which
could be misinterpreted on a quick walkthrough. Fixing this in order
to improve code readability a bit.
Signed-off-by: NEnrico Weigelt, metux IT consult <info@metux.net>
Signed-off-by: NBartosz Golaszewski <bgolaszewski@baylibre.com>

Add possibility to toggle active-low flag of a gpio descriptor. This is
useful for compatibility code, where defaults are inverted vs DT gpio
flags or the active-low flag is taken from elsewhere.
Acked-by: NLinus Walleij <linus.walleij@linaro.org>
Signed-off-by: NMichał Mirosław <mirq-linux@rere.qmqm.pl>
Link: https://lore.kernel.org/r/7ce0338e01ad17fa5a227176813941b41a7c35c1.1576031637.git.mirq-linux@rere.qmqm.plSigned-off-by: NUlf Hansson <ulf.hansson@linaro.org>

We have for some time the assign_bit() API to replace open coded

	if (foo)
		set_bit(n, bar);
	else
		clear_bit(n, bar);

Use this API in GPIO library code.

No functional change intended.
Signed-off-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>
Link: https://lore.kernel.org/r/20191204194229.64251-2-andriy.shevchenko@linux.intel.comSigned-off-by: NLinus Walleij <linus.walleij@linaro.org>

The string literal "gpiochip" is used in several places.
Add a definition for it, and use it everywhere, to make sure everything
stays in sync.
Signed-off-by: NGeert Uytterhoeven <geert+renesas@glider.be>
Link: https://lore.kernel.org/r/20191127084253.16356-2-geert+renesas@glider.beReviewed-by: NUlrich Hecht <uli+renesas@fpond.eu>
Reviewed-by: NEugeniu Rosca <erosca@de.adit-jv.com>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

gpiolib has a corner case with open drain outputs that are emulated.
When such outputs are outputting a logic 1, emulation will set the
hardware to input mode, which will cause gpiod_get_direction() to
report that it is in input mode. This is different from the behaviour
with a true open-drain output.

Unify the semantics here.

Cc: <stable@vger.kernel.org>
Suggested-by: NLinus Walleij <linus.walleij@linaro.org>
Signed-off-by: NRussell King <rmk+kernel@armlinux.org.uk>
Signed-off-by: NBartosz Golaszewski <bgolaszewski@baylibre.com>