When trying to export an nonexisting gpio ID, the kernel prints out a
big warning w/ stacktrace, sounding like a huge problem. In fact it's
a pretty normal situation, like file or device not found.

So, just print a more relaxed warning instead.

changes v2: drop defining pr_fmt()
Signed-off-by: NEnrico Weigelt <info@metux.net>
Link: https://lore.kernel.org/r/20201202133754.32045-1-info@metux.netSigned-off-by: NLinus Walleij <linus.walleij@linaro.org>

In some cases we would like to have debounce setter which doesn't fail
when a feature is not supported by a controller.

Cc: Mika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>
Acked-by: NLinus Walleij <linus.walleij@linaro.org>
Reviewed-by: NHans de Goede <hdegoede@redhat.com>

This function is useful for internal use in the GPIO library.
There will be new user coming, prepare a helper for the new comer
and the existing ones.
Signed-off-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>
Acked-by: NLinus Walleij <linus.walleij@linaro.org>
Reviewed-by: NHans de Goede <hdegoede@redhat.com>
Reviewed-by: NMika Westerberg <mika.westerberg@linux.intel.com>

Move bias related code from gpio_set_config() to gpio_set_bias().
Signed-off-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>
Acked-by: NLinus Walleij <linus.walleij@linaro.org>
Reviewed-by: NHans de Goede <hdegoede@redhat.com>
Reviewed-by: NMika Westerberg <mika.westerberg@linux.intel.com>

In the future we will need to have a separate function
that takes an arbitrary argument value.

Extract gpio_set_config_with_argument() for that purpose.
Signed-off-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>
Acked-by: NLinus Walleij <linus.walleij@linaro.org>
Reviewed-by: NHans de Goede <hdegoede@redhat.com>
Reviewed-by: NMika Westerberg <mika.westerberg@linux.intel.com>

Instead of open coded macro use, call pinconf_to_config_packed().
Signed-off-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>
Acked-by: NLinus Walleij <linus.walleij@linaro.org>
Reviewed-by: NHans de Goede <hdegoede@redhat.com>
Reviewed-by: NMika Westerberg <mika.westerberg@linux.intel.com>

It's no difference in the functionality, but after the change the code
is less error prone to various checkers.
Signed-off-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>
Acked-by: NLinus Walleij <linus.walleij@linaro.org>
Reviewed-by: NHans de Goede <hdegoede@redhat.com>
Reviewed-by: NMika Westerberg <mika.westerberg@linux.intel.com>

Replace unsigned by unsigned int in GPIO library code.
Note, legacy API left untouched.
Signed-off-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>
Acked-by: NLinus Walleij <linus.walleij@linaro.org>
Reviewed-by: NHans de Goede <hdegoede@redhat.com>
Reviewed-by: NMika Westerberg <mika.westerberg@linux.intel.com>

In gpiochip_setup_dev() the call to gpiolib_cdev_register() indirectly
calls device_add().  This is still required for the sysfs even when
CONFIG_GPIO_CDEV is not selected in the build.

Replace the stubbed functions in gpiolib-cdev.h with macros in gpiolib.c
that perform the required device_add() and device_del() when
CONFIG_GPIO_CDEV is not selected.

Fixes: d143493c (gpiolib: make cdev a build option)
Reported-by: NNicolas Schichan <nschichan@freebox.fr>
Signed-off-by: NKent Gibson <warthog618@gmail.com>
Tested-by: NNicolas Schichan <nschichan@freebox.fr>
Signed-off-by: NBartosz Golaszewski <bgolaszewski@baylibre.com>

Now that all gpiolib irqchip users have been over to use
the irqchip template, we can finally retire the old code
path and leave just one way in to the irqchip: set up the
template when registering the gpio_chip. For a while
we had two code paths for this which was a bit confusing.

This brings this work to a conclusion, there is now one
way of doing this.
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
Reviewed-by: NAndy Shevchenko <andy.shevchenko@gmail.com>
Cc: Thierry Reding <thierry.reding@gmail.com>
Link: https://lore.kernel.org/r/20201019134046.65101-1-linus.walleij@linaro.org

First of all, bias has a special type as being a part of enum pin_config_param.
Second, 0 is also defined bias which is equivalent to BUS_HOLD.

Taking into account above, change type of bias variable and refactor
gpio_set_bias() in a way that it doesn't use BUS_HOLD as a place holder.
Signed-off-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>
Link: https://lore.kernel.org/r/20201009184359.16427-1-andriy.shevchenko@linux.intel.comSigned-off-by: NLinus Walleij <linus.walleij@linaro.org>

Add support for setting debounce on a line via the GPIO uAPI.
Where debounce is not supported by hardware, a software debounce is
provided.

The implementation of the software debouncer waits for the line to be
stable for the debounce period before determining if a level change,
and a corresponding edge event, has occurred.  This provides maximum
protection against glitches, but also introduces a debounce_period
latency to edge events.

The software debouncer is integrated with the edge detection as it
utilises the line interrupt, and integration is simpler than getting
the two to interwork.  Where software debounce AND edge detection is
required, the debouncer provides both.
Signed-off-by: NKent Gibson <warthog618@gmail.com>
Signed-off-by: NBartosz Golaszewski <bgolaszewski@baylibre.com>

Add support for edge detection to lines requested using
GPIO_V2_GET_LINE_IOCTL.

The edge_detector implementation is based on the v1 lineevent
implementation.  Unlike the v1 implementation, an overflow of the event
buffer results in discarding older events, rather than the most
recent, so the final event in a burst will correspond to the current
state of the line.
Signed-off-by: NKent Gibson <warthog618@gmail.com>
Signed-off-by: NBartosz Golaszewski <bgolaszewski@baylibre.com>

It's possible for a GPIO chip to not have a parent device (whose
properties we inspect for 'gpio-line-names'). In this case we should
simply return from devprop_gpiochip_set_names(). Add an appropriate
check for this use-case.

Fixes: 7cba1a4d ("gpiolib: generalize devprop_gpiochip_set_names() for device properties")
Reported-by: NAnders Roxell <anders.roxell@linaro.org>
Signed-off-by: NBartosz Golaszewski <bgolaszewski@baylibre.com>
Reviewed-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>
Tested-by: NAnders Roxell <anders.roxell@linaro.org>
Reviewed-by: NMika Westerberg <mika.westerberg@linux.intel.com>

Now that devprop_gpiochip_set_names() is only used in a single place
inside drivers/gpio/gpiolib.c, there's no need anymore for it to be
exported or to even live in its own source file. Pull this function into
the core source file for gpiolib.
Signed-off-by: NBartosz Golaszewski <bgolaszewski@baylibre.com>
Reviewed-by: NMika Westerberg <mika.westerberg@linux.intel.com>
Reviewed-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>

devprop_gpiochip_set_names() is overly complicated with taking the
fwnode argument (which requires using dev_fwnode() & of_fwnode_handle()
in ACPI and OF GPIO code respectively). Let's just switch to using the
generic device properties.

This allows us to pull the code setting line names directly into
gpiochip_add_data_with_key() instead of handling it separately for
ACPI and OF.
Signed-off-by: NBartosz Golaszewski <bgolaszewski@baylibre.com>
Reviewed-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>
Reviewed-by: NMika Westerberg <mika.westerberg@linux.intel.com>

We don't need to specify any ranges when allocating IDs so we can switch
to ida_alloc() and ida_free() instead of the ida_simple_ counterparts.

ida_simple_get(ida, 0, 0, gfp) is equivalent to
ida_alloc_range(ida, 0, UINT_MAX, gfp) which is equivalent to
ida_alloc(ida, gfp). Note: IDR will never actually allocate an ID
larger than INT_MAX.
Signed-off-by: NBartosz Golaszewski <bgolaszewski@baylibre.com>
Reviewed-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>

Use DEFINE_SEQ_ATTRIBUTE macro to simplify the code.
Signed-off-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: NBartosz Golaszewski <bgolaszewski@baylibre.com>

Replace usage of atomic_notifier_call_chain with
blocking_notifier_call_chain as the notifier function,
lineinfo_changed_notify, calls gpio_desc_to_lineinfo,
which calls pinctrl_gpio_can_use_line, which can sleep.

The chain isn't being called from an atomic context so the
the blocking notifier is a suitable substitute.
Signed-off-by: NKent Gibson <warthog618@gmail.com>
Signed-off-by: NBartosz Golaszewski <bgolaszewski@baylibre.com>

Move gpiolib-sysfs function declarations into their own header.

These functions are in gpiolib-sysfs.c, and are only required by gpiolib.c,
and so should be in a module header, not gpiolib.h.

This brings gpiolib-sysfs into line with gpiolib-cdev, and is another step
towards removing the sysfs inferface.
Signed-off-by: NKent Gibson <warthog618@gmail.com>
Signed-off-by: NBartosz Golaszewski <bgolaszewski@baylibre.com>

bitmap_full() is a shortcut to find_first_zero_bit().
Thus, no need to call it twice.
Signed-off-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: NBartosz Golaszewski <bgolaszewski@baylibre.com>

Split the cdev specific functionality out of gpiolib.c and into
gpiolib-cdev.c. This improves the readability and maintainability of both
the cdev and core gpiolib code.
Suggested-by: NBartosz Golaszewski <bgolaszewski@baylibre.com>
Signed-off-by: NKent Gibson <warthog618@gmail.com>
Link: https://lore.kernel.org/r/20200616093615.5167-1-warthog618@gmail.comSigned-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>

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>

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 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>

Simplify the printing of kernel messages and make the messages more
accurate by using the most appropriate {dev,chip,gpiod}_*() helpers.

Sample impact:

    -gpiochip_setup_dev: registered GPIOs 496 to 511 on device: gpiochip0 (e6050000.gpio)
    +gpio gpiochip0: registered GPIOs 496 to 511 on e6050000.gpio

    -no flags found for gpios
    +gpio-953 (?): no flags found for gpios

    -GPIO line 355 (PCIE/SATA switch) hogged as output/low
    +gpio-355 (PCIE/SATA switch): hogged as output/low
Signed-off-by: NGeert Uytterhoeven <geert+renesas@glider.be>
Link: https://lore.kernel.org/r/20200424141432.11400-1-geert+renesas@glider.beSigned-off-by: NLinus Walleij <linus.walleij@linaro.org>

We must not call pinctrl_gpio_can_use_line() with the gpio_lock taken
as it takes a mutex internally. Let's move the call before taking the
spinlock and store the return value.

This isn't perfect - there's a moment between calling
pinctrl_gpio_can_use_line() and taking the spinlock where the situation
can change but it isn't a regression either: previously this part wasn't
protected at all and it only affects the information user-space is
seeing.
Reported-by: NGeert Uytterhoeven <geert@linux-m68k.org>
Fixes: d2ac2579 ("gpiolib: provide a dedicated function for setting lineinfo")
Signed-off-by: NBartosz Golaszewski <bgolaszewski@baylibre.com>
Acked-by: NLinus Walleij <linus.walleij@linaro.org>

This makes the new ioctl() a bit more robust - we now check if a line
is already being watched and return -EBUSY if the user-space tries to
start watching it again. Same for unwatch - return -EBUSY if user-space
tries to unwatch a line that's not being watched.

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

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>