linux-toradex.git/include/linux/gpio, branch v5.10-rc3

gpiolib: unexport devprop_gpiochip_set_names()

2020-09-14T08:54:42+00:00

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: Bartosz Golaszewski 
Reviewed-by: Mika Westerberg 
Reviewed-by: Andy Shevchenko

gpiolib: generalize devprop_gpiochip_set_names() for device properties

2020-09-14T08:54:01+00:00

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: Bartosz Golaszewski 
Reviewed-by: Andy Shevchenko 
Reviewed-by: Mika Westerberg

gpio: don't use same lockdep class for all devm_gpiochip_add_data users

2020-08-03T23:22:02+00:00

Commit 959bc7b22bd2 ("gpio: Automatically add lockdep keys") documents
in its commits message its intention to "create a unique class key for
each driver".

It does so by having gpiochip_add_data add in-place the definition of
two static lockdep classes for LOCKDEP use. That way, every caller of
the macro adds their gpiochip with unique lockdep classes.

There are many indirect callers of gpiochip_add_data, however, via
use of devm_gpiochip_add_data. devm_gpiochip_add_data has external
linkage and all its users will share the same lockdep classes, which
probably is not intended.

Fix this by replicating the gpio_chip_add_data statics-in-macro for
the devm_ version as well.

Fixes: 959bc7b22bd2 ("gpio: Automatically add lockdep keys")
Signed-off-by: Ahmad Fatoum 
Reviewed-by: Andy Shevchenko 
Reviewed-by: Bartosz Golaszewski 
Link: https://lore.kernel.org/r/20200731123835.8003-1-a.fatoum@pengutronix.de
Signed-off-by: Linus Walleij

gpio: regmap: fix type clash

2020-07-26T22:27:54+00:00

GPIO_REGMAP_ADDR_ZERO() cast to unsigned long but the actual config
parameters are unsigned int. We use unsigned int here because that is
the type which is used by the underlying regmap.

Fixes: ebe363197e52 ("gpio: add a reusable generic gpio_chip using regmap")
Reported-by: kernel test robot 
Signed-off-by: Michael Walle 
Link: https://lore.kernel.org/r/20200725232337.27581-1-michael@walle.cc
Signed-off-by: Linus Walleij

gpio: Correct kernel-doc inconsistency

2020-07-23T13:18:09+00:00

Fix kernel-doc comment to match parameter name change "chip" to "gc"
in gpiochip_add_data function.

Signed-off-by: Colton Lewis 
Link: https://lore.kernel.org/r/20200723095658.234668-1-colton.w.lewis@protonmail.com
Signed-off-by: Linus Walleij

Merge tag 'gpio-updates-for-v5.9-part1' of git://git.kernel.org/pub/scm/linux/kernel/git/brgl/linux into devel

2020-06-30T21:53:11+00:00

gpio updates for v5.9

- use kobj_to_dev() in sysfs interface
- kerneldoc and documentation fixes
- relax the interrupt flags in gpio-mpc8xxx
- support new model in gpio-pca953x
- remove a redundant check from gpio-max732x
- support a new platform in gpio-zynq (+ some minor fixes)
- don't depend on GPIOLIB when already inside the "if GPIOLIB" in Kconfig
- support PM ops for suspend in gpio-omap
- minor tweaks in gpiolib

gpiolib: Introduce for_each_requested_gpio_in_range() macro

2020-06-20T21:13:26+00:00

Introduce for_each_requested_gpio_in_range() macro which helps
to iterate over requested GPIO in a range. There are already
potential users of it, which are going to be converted
by the following patches.

For most of them for_each_requested_gpio() shortcut has been added.

Signed-off-by: Andy Shevchenko 
Link: https://lore.kernel.org/r/20200615150545.87964-2-andriy.shevchenko@linux.intel.com
Signed-off-by: Linus Walleij

gpio: driver.h: fix kernel-doc markup

2020-06-15T08:05:30+00:00

There is one parameter with a wrong name at kernel-doc macro:

./include/linux/gpio/driver.h:499: warning: Function parameter or member 'gc' not described in 'gpiochip_add_data'
./include/linux/gpio/driver.h:499: warning: Excess function parameter 'chip' description in 'gpiochip_add_data'

Fix it.

Signed-off-by: Mauro Carvalho Chehab 
Signed-off-by: Bartosz Golaszewski

gpio: add a reusable generic gpio_chip using regmap

2020-06-03T08:48:37+00:00

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: Michael Walle 
Reviewed-by: Andy Shevchenko 
Link: https://lore.kernel.org/r/20200528145845.31436-3-michael@walle.cc
Signed-off-by: Linus Walleij

gpiolib: Introduce gpiochip_irqchip_add_domain()

2020-06-03T08:48:37+00:00

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: Michael Walle 
Reviewed-by: Andy Shevchenko 
Link: https://lore.kernel.org/r/20200528145845.31436-2-michael@walle.cc
Signed-off-by: Linus Walleij