[ Upstream commit 3550bba25d ]
Since commit 2ab73c6d83 ("gpio: Support GPIO controllers without pin-ranges")
the device tree nodes of GPIO controller need the gpio-ranges property to
handle gpio-hogs. Unfortunately it's impossible to guarantee that every new
kernel is shipped with an updated device tree binary.
In order to provide backward compatibility with those older DTB, we need a
callback within of_gpiochip_add_pin_range() so the relevant platform driver
can handle this case.
Fixes: 2ab73c6d83 ("gpio: Support GPIO controllers without pin-ranges")
Signed-off-by: Stefan Wahren <stefan.wahren@i2se.com>
Reviewed-by: Florian Fainelli <f.fainelli@gmail.com>
Tested-by: Florian Fainelli <f.fainelli@gmail.com>
Acked-by: Bartosz Golaszewski <brgl@bgdev.pl>
Link: https://lore.kernel.org/r/20220409095129.45786-2-stefan.wahren@i2se.com
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit 5467801f1f upstream.
GPIO chip irq members are exposed before they could be completely
initialized and this leads to race conditions.
One such issue was observed for the gc->irq.domain variable which
was accessed through the I2C interface in gpiochip_to_irq() before
it could be initialized by gpiochip_add_irqchip(). This resulted in
Kernel NULL pointer dereference.
Following are the logs for reference :-
kernel: Call Trace:
kernel: gpiod_to_irq+0x53/0x70
kernel: acpi_dev_gpio_irq_get_by+0x113/0x1f0
kernel: i2c_acpi_get_irq+0xc0/0xd0
kernel: i2c_device_probe+0x28a/0x2a0
kernel: really_probe+0xf2/0x460
kernel: RIP: 0010:gpiochip_to_irq+0x47/0xc0
To avoid such scenarios, restrict usage of GPIO chip irq members before
they are completely initialized.
Signed-off-by: Shreeya Patel <shreeya.patel@collabora.com>
Cc: stable@vger.kernel.org
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Bartosz Golaszewski <brgl@bgdev.pl>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 62d5247d23 upstream.
On some systems the ACPI tables has wrong pin number and instead of
having a relative one it provides an absolute one in the global GPIO
number space.
Add ACPI_GPIO_QUIRK_ABSOLUTE_NUMBER quirk to cope with such cases.
Fixes: ba8c90c618 ("gpio: pca953x: Override IRQ for one of the expanders on Galileo Gen 2")
Depends-on: 0ea683931a ("gpio: dwapb: Convert driver to using the GPIO-lib-based IRQ-chip")
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Acked-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
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 <bgolaszewski@baylibre.com>
Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Reviewed-by: Andy 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: Bartosz Golaszewski <bgolaszewski@baylibre.com>
Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Commit 959bc7b22b ("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: 959bc7b22b ("gpio: Automatically add lockdep keys")
Signed-off-by: Ahmad Fatoum <a.fatoum@pengutronix.de>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Reviewed-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
Link: https://lore.kernel.org/r/20200731123835.8003-1-a.fatoum@pengutronix.de
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
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: ebe363197e ("gpio: add a reusable generic gpio_chip using regmap")
Reported-by: kernel test robot <lkp@intel.com>
Signed-off-by: Michael Walle <michael@walle.cc>
Link: https://lore.kernel.org/r/20200725232337.27581-1-michael@walle.cc
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
- 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
-----BEGIN PGP SIGNATURE-----
iQIzBAABCAAdFiEEFp3rbAvDxGAT0sefEacuoBRx13IFAl77GHcACgkQEacuoBRx
13JBIQ/+PEo8o7hVqpXETQ3NYwoPC4Hov0sE3Ig/ecoAEmTG2FPXU/qcACiO4z64
n9bXadS8iTPBHpblmbTx5MwzWk081GwSR+y3P8mxZUjO6FdVt8v/TZnkgMaat0cv
xIM18MbBYzmlwNvpqaIHn7ZlC20mGHeFEBM600QIBkf5+fN0gCZF8cB62jqVZp2e
rg1dzmdd7GWMXVIZ+D+XAdPuRsSDNBeGoQG/Ip4sio4VsU64FoSu279V3WGHFbHu
2yfz4QxXOblhXRxT9swMtuPYAON8aai23YlcEDpt6K/j2TJtVibJRlRBDUQAYmNH
K2XA7phKcEVCN47rG8XR9v2l5Qkf49eVCOS2Y0f6G+GL9KwezD2WZL/4d+Nyx7CZ
YDSIM+ti0FHUb7b6wSFQHJbdKk2sdtqpYaakirNmRAPKPBT+rzyRaNx6XLu2/wMi
CVC+LCdxdlsHpnPVcCTjNeGHmZrloDJiQb0A0kpZnPagHXrQaI5tw7OKDKoPi+DA
bkYxW++Iq96QRjEvExu0V/3gRNWPjXpWd+sfMJ6b/Lb4orbmlnJcjgVDXDQvqj0N
Oga87Mgg5U/pfPYvLvuxwwpMwp1QZv9ex8dG91M62V0Ta+Ja4nOdtpIERHEKKP6d
ehKBXzU7F6tREIG3EU+DMm33RWRnM/DYrg7RnPgIHzxDB6Wj18c=
=TwKk
-----END PGP SIGNATURE-----
Merge tag 'gpio-updates-for-v5.9-part1' of git://git.kernel.org/pub/scm/linux/kernel/git/brgl/linux into devel
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
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 <andriy.shevchenko@linux.intel.com>
Link: https://lore.kernel.org/r/20200615150545.87964-2-andriy.shevchenko@linux.intel.com
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
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 <mchehab+huawei@kernel.org>
Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
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 <michael@walle.cc>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Link: https://lore.kernel.org/r/20200528145845.31436-3-michael@walle.cc
Signed-off-by: Linus 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: Michael Walle <michael@walle.cc>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Link: https://lore.kernel.org/r/20200528145845.31436-2-michael@walle.cc
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
With 'commit 461c1a7d47 ("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: 461c1a7d47 ("gpiolib: override irq_enable/disable")
Signed-off-by: Maulik Shah <mkshah@codeaurora.org>
Tested-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Link: https://lore.kernel.org/r/1590253873-11556-2-git-send-email-mkshah@codeaurora.org
Signed-off-by: Linus 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: Geert Uytterhoeven <geert+renesas@glider.be>
Tested-by: Eugeniu Rosca <erosca@de.adit-jv.com>
Reviewed-by: Ulrich Hecht <uli+renesas@fpond.eu>
Reviewed-by: Eugeniu Rosca <erosca@de.adit-jv.com>
Link: https://lore.kernel.org/r/20200511145257.22970-4-geert+renesas@glider.be
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
When I copied the function prototypes from the GPIO header file into
my own driver, checkpatch yelled at me saying that I shouldn't use use
"unsigned" but instead should say "unsigned int". Let's make the
header file use "unsigned int" so others who copy like I did won't get
yelled at.
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Link: https://lore.kernel.org/r/20200428172322.2.Iacb3c8152c3cf9015a91308678155a578b0cc050@changeid
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
The legacy defines GPIOF_DIR_XXX are only for consumers. Document the
proper ones. Also: don't use "_XXX" since that's harder to find with
"git grep". Just list both of the values.
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Link: https://lore.kernel.org/r/20200428172322.1.I396f351e364f3c09df7c7606e79abefb8682c092@changeid
Signed-off-by: Linus 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: Linus Walleij <linus.walleij@linaro.org>
Link: https://lore.kernel.org/r/20200329140405.52276-1-linus.walleij@linaro.org
Signed-off-by: Linus 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: Geert Uytterhoeven <geert+renesas@glider.be>
Link: https://lore.kernel.org/r/20200324135653.6676-5-geert+renesas@glider.be
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
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: Chuanhong Guo <gch981213@gmail.com>
Tested-by: René van Dorst <opensource@vdorst.com>
Reviewed-by: Sergio Paracuellos <sergio.paracuellos@gmail.com>
Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
Inclusion of kernel.h increases the mess with the header dependencies.
Avoid kernel.h inclusion where it's possible.
Besides that, clean up a bit other inclusions inside GPIO subsystem headers.
It includes:
- removal pin control bits (forward declaration and header) from linux/gpio.h
- removal of.h from asm-generic/gpio.h
- use of explicit headers in gpio/consumer.h
- add FIXME note with regard to gpio.h inclusion in of_gpio,h
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Link: https://lore.kernel.org/r/20200205134336.20197-1-andriy.shevchenko@linux.intel.com
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Core changes:
- Dropped the chained IRQ setup callback into GPIOLIB as we
got rid of the last users of that in this changeset.
New drivers:
- New driver for Ingenic X1830.
- New driver for Freescale i.MX8MP.
Driver enhancements:
- Fix all remaining Intel drivers to pass their IRQ chips
along with the GPIO chips.
- Intel Baytrail allocates its irqchip dynamically.
- Intel Lynxpoint is thoroughly rewritten and modernized.
- Aspeed AST2600 pin muxing and configuration is much
improved.
- Qualcomm SC7180 functions are updated and wakeup interrupt
map is provided.
- A whole slew of Renesas SH-PFC cleanups and improvements.
- Fix up the Intel DT bindings to use the generic YAML
DT bindings schema. (A first user of this.)
-----BEGIN PGP SIGNATURE-----
iQIzBAABCAAdFiEElDRnuGcz/wPCXQWMQRCzN7AZXXMFAl4xQIkACgkQQRCzN7AZ
XXNchQ/8C4+SAMMcDQm4sIWV1duebynrXuebISqWMhAtYDRjCsRpGCqVSt+iSWod
z29pJ/sm0xpG1Bz0bmDZ4oFv7u7+J89a/0Kl4OqI1pbO97Uadu2qGmYxZf2tMtlH
CwWVOUAldU9scogRD6Z+qixYdRRpKufpaVaU7ooubHocmgRtzd/VCT2MX76c3w7j
1+yHjoAKM59jpOD/8oEucEYB+5ngyTiMXo3Nms/6ciq52GdtMLE8nK+t7dM+xNLL
hMQP95iQ2Xb+cM/bv+vdMyKF6vRxKkkeQ/hWcivGWgdI/BSFg0vCq0mWdc8qWp8k
VeIBaTVh5wuaAdkir9dHX/zt6TsRV8ktv88jW773/z4jHr/8PmQUyFMyEA1u1haP
yrC/vm4eL6QWCAZeATra5+5FoH2ljzwaY2rgeU0hNixjaF/aIp3GPci7+YmKHTIr
5zZTXKAeuC/nV7g77w4O9iwn+SHWPytWBrfNZ7unyV5fl4XHckY2vNBa/g8xkYyb
FBk642EwHRGCULb8m40+cB7TMUzk9aluXge1detJDbqlr2i+tSOWp1c3GSavLl1L
4qRAAS2j6de1H/EaoO7EcArVrSMdPgLdpRmwCMc2xvL0HOprl6y+5iL7x86ZtQHu
NHvgnjtw6Z6t9n28f5ZI1iEXUA6EHOHHc/sPPUqScCj4v85B25A=
=PnK5
-----END PGP SIGNATURE-----
Merge tag 'pinctrl-v5.6-1' of git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-pinctrl
Pull pin control updates from Linus Walleij:
"This is the bulk of pin control changes, nothing too exciting about
this.
Some changes hit arch/sh and arch/arm but are well isolated and
acknowledged by the respective arch maintainers.
Core changes:
- Dropped the chained IRQ setup callback into GPIOLIB as we got rid
of the last users of that in this changeset.
New drivers:
- New driver for Ingenic X1830.
- New driver for Freescale i.MX8MP.
Driver enhancements:
- Fix all remaining Intel drivers to pass their IRQ chips along with
the GPIO chips.
- Intel Baytrail allocates its irqchip dynamically.
- Intel Lynxpoint is thoroughly rewritten and modernized.
- Aspeed AST2600 pin muxing and configuration is much improved.
- Qualcomm SC7180 functions are updated and wakeup interrupt map is
provided.
- A whole slew of Renesas SH-PFC cleanups and improvements.
- Fix up the Intel DT bindings to use the generic YAML DT bindings
schema (a first user of this)"
* tag 'pinctrl-v5.6-1' of git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-pinctrl: (99 commits)
pinctrl: madera: Remove extra blank line
pinctrl: qcom: Don't lock around irq_set_irq_wake()
pinctrl: mvebu: armada-37xx: use use platform api
gpio: Drop the chained IRQ handler assign function
pinctrl: freescale: Add i.MX8MP pinctrl driver support
dt-bindings: imx: Add pinctrl binding doc for i.MX8MP
pinctrl: tigerlake: Tiger Lake uses _HID enumeration
pinctrl: sunrisepoint: Add Coffee Lake-S ACPI ID
pinctrl: iproc: Use platform_get_irq_optional() to avoid error message
pinctrl: dt-bindings: Fix some errors in the lgm and pinmux schema
pinctrl: intel: Pass irqchip when adding gpiochip
pinctrl: intel: Add GPIO <-> pin mapping ranges via callback
pinctrl: baytrail: Replace WARN with dev_info_once when setting direct-irq pin to output
pinctrl: baytrail: Do not clear IRQ flags on direct-irq enabled pins
pinctrl: sunrisepoint: Add missing Interrupt Status register offset
pinctrl: sh-pfc: Split R-Car H3 support in two independent drivers
pinctrl: artpec6: fix __iomem on reg in set
pinctrl: ingenic: Use devm_platform_ioremap_resource()
pinctrl: ingenic: Factorize irq_set_type function
pinctrl: ingenic: Remove duplicated ingenic_chip_info structures
...
Core changes:
- Document the usecases for the kernelspace vs userspace
handling of GPIOs.
- Handle MSI (message signalled interrupts) properly in the
core hierarchical irqdomain code.
- Fix a rare race condition while initializing the descriptor
array.
New drivers:
- Xylon LogiCVC GPIO driver.
- WDC934x GPIO controller driver.
Driver improvements:
- Implemented suspend/resume in the Tegra driver.
- MPC8xx edge detection fixup.
- Properly convert ThunderX to use hierarchical irqdomain
with GPIOLIB_IRQCHIP on top of the revert of the previous
buggy switchover. This time it works (hopefully).
Misc:
- Drop a FMC remnant file <linux/ipmi-fru.h>
- A slew of fixes.
-----BEGIN PGP SIGNATURE-----
iQIzBAABCAAdFiEElDRnuGcz/wPCXQWMQRCzN7AZXXMFAl4xO9gACgkQQRCzN7AZ
XXO+lBAAv+viQVCj1IG6ajCWpsAECHY+U3xRl4ETy86Jx2uNJS48xmnYrjbqUH+h
r9HDi1Z5pyc14PtOEi01qVt87z612VmZbYNZ7tVBMXsGhN18wHRtC1y8GDtRSOxj
Zqeyu6zFn2WxGTbwGdjxeliVcuCUOLu+zsE/xnCmUWT0gkeMi62MpSR4/chtbh3g
Qu6lxtUcF2MN5IuGb6oCTnWQF+Bk9Pdib2HcKDqIGjQKbato7GLAEQdHY1K9vb7l
Wwovasg62CDMtXohBL6SZJJPWPhoK0MUNrKdPJPb3W2yJKgoiVyoNz8FRGmX2OUx
3v0elGP83v4jdmA6aHRfTmmcYKmEevxSFAxjCXw6pYEsPwf3VIr6TMkqANogA16S
Ag2eda/6gTiVKlFCVi9uxkLfVvYcdUTYWCjG0xOseVJRnWpXJbNwjCd493Qwhbim
zfziqoCYPZ6rLWcoDFkWZ27edfHCdPBlamnRyfHy5+1Y9s4jdcuMtp5B8tlvGuOp
55j/FSNvpPdmXIS0g8/C90nZ2WiAM9N5C1CyrLwgJvixHcMFhmKkJVnJ0zHHCOdC
Mu1CBdaGlH7o4+M+CIMU63q5YnHrmoZvZ3t5PPlCl5iUETuKGZmWBKzRv5qx3xld
iwSf8vfy+4bJGOF9xSgSvTOpoVEfsJAagKoBiT3WJuK9zi65vmI=
=3Glg
-----END PGP SIGNATURE-----
Merge tag 'gpio-v5.6-1' of git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-gpio
Pull GPIO updates from Linus Walleij:
"This is the bulk of GPIO changes for the v5.6 kernel cycle.
This is a pretty calm cycle so far, nothing special going on really.
Some more changes will come in from the irqchip and pin control trees.
I also deleted an orphan include file for FMC that was dangling since
subsystem was removed.
Core changes:
- Document the usecases for the kernelspace vs userspace handling of
GPIOs.
- Handle MSI (message signalled interrupts) properly in the core
hierarchical irqdomain code.
- Fix a rare race condition while initializing the descriptor array.
New drivers:
- Xylon LogiCVC GPIO driver.
- WDC934x GPIO controller driver.
Driver improvements:
- Implemented suspend/resume in the Tegra driver.
- MPC8xx edge detection fixup.
- Properly convert ThunderX to use hierarchical irqdomain with
GPIOLIB_IRQCHIP on top of the revert of the previous buggy
switchover. This time it works (hopefully).
Misc:
- Drop a FMC remnant file <linux/ipmi-fru.h>
- A slew of fixes"
* tag 'gpio-v5.6-1' of git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-gpio: (48 commits)
MAINTAINERS: Replace Tien Hock Loh as Altera PIO maintainer
gpiolib: hold gpio devices lock until ->descs array is initialised
gpio: aspeed-sgpio: fixed typos
gpio: mvebu: clear irq in edge cause register before unmask edge irq
gpiolib: Lower verbosity when allocating hierarchy irq
gpiolib: Remove duplicated function gpio_do_set_config()
gpio: Fix the no return statement warning
gpio: wcd934x: Add support to wcd934x gpio controller
gpiolib: remove set but not used variable 'config'
gpio: vx855: fixed a typo
gpio: mockup: sort headers alphabetically
gpio: mockup: update the license tag
gpio: Remove the unused flags
gpiolib: Set lockdep class for hierarchical irq domains
gpio: thunderx: Switch to GPIOLIB_IRQCHIP
gpiolib: Add the support for the msi parent domain
gpiolib: Add support for the irqdomain which doesn't use irq_fwspec as arg
gpio: Add use guidance documentation
dt-bindings: gpio: wcd934x: Add bindings for gpio
gpio: altera: change to platform_get_irq_optional to avoid false-positive error
...
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: Linus Walleij <linus.walleij@linaro.org>
Link: https://lore.kernel.org/r/20200113220800.77817-1-linus.walleij@linaro.org
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
In commit 2425876167 ("gpiolib: Add support for the irqdomain which
doesn't use irq_fwspec as arg") we have changed the return type of
gpiochip_populate_parent_fwspec_twocell/fourcell() from void to void *,
but forgot to add a return statement for these two dummy functions.
Add "return NULL" to fix the build warnings.
Reported-by: kbuild test robot <lkp@intel.com>
Signed-off-by: Kevin Hao <haokexin@gmail.com>
Link: https://lore.kernel.org/r/20200116095003.30324-1-haokexin@gmail.com
Signed-off-by: Linus 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: Kevin Hao <haokexin@gmail.com>
Link: https://lore.kernel.org/r/20200114082821.14015-3-haokexin@gmail.com
Signed-off-by: Linus 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: Bartosz Golaszewski <bgolaszewski@baylibre.com>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
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: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Michał Mirosław <mirq-linux@rere.qmqm.pl>
Link: https://lore.kernel.org/r/7ce0338e01ad17fa5a227176813941b41a7c35c1.1576031637.git.mirq-linux@rere.qmqm.pl
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
When IRQ chip is being added by GPIO library, the ACPI based platform expects
GPIO <-> pin mapping ranges to be initialized in order to correctly initialize
ACPI event mechanism on affected platforms. Unfortunately this step is missed.
Introduce ->add_pin_ranges() callback to fill the above mentioned gap.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Tested-by: Hans de Goede <hdegoede@redhat.com>
At least for me it is difficult to remember the meaning of GPIO
direction values. Define GPIO_LINE_DIRECTION_IN and
GPIO_LINE_DIRECTION_OUT so that occasional GPIO contributors would
not need to always check the meaning of hard coded values 1 and 0.
Signed-off-by: Matti Vaittinen <matti.vaittinen@fi.rohmeurope.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
After changing the drivers to use GPIO core to add an IRQ chip
it appears that some of them requires a hardware initialization
before adding the IRQ chip.
Add an optional callback ->init_hw() to allow that drivers
to initialize hardware if needed.
This change is a part of the fix NULL pointer dereference
brought to the several drivers recently.
Cc: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
This introduces fwnode_gpiod_get_index() that iterates through common gpio
suffixes when trying to locate a GPIO within a given firmware node.
We also switch devm_fwnode_gpiod_get_index() to call
fwnode_gpiod_get_index() instead of iterating through GPIO suffixes on
its own.
Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Link: https://lore.kernel.org/r/20190913032240.50333-3-dmitry.torokhov@gmail.com
Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
devm_fwnode_get_index_gpiod_from_child() is too long, besides the fwnode
in question does not have to be a child of device node. Let's rename it
to devm_fwnode_gpiod_get_index() and keep the old name for compatibility
for now.
Also let's add a devm_fwnode_gpiod_get() wrapper as majority of the
callers need a single GPIO.
Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Link: https://lore.kernel.org/r/20190913032240.50333-2-dmitry.torokhov@gmail.com
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
After changing the valid_mask for the struct gpio_chip
to detect the need and presence of a valid mask with the
presence of a .init_valid_mask() callback to fill it in,
we augment the gpio_irq_chip to use the same logic.
Switch all driver using the gpio_irq_chio valid_mask
over to this new method.
This makes sure the valid_mask for the gpio_irq_chip gets
filled in when we add the gpio_chip, which makes it a
little easier to switch over drivers using the old
way of setting up gpio_irq_chip over to the new method
of passing the gpio_irq_chip along with the gpio_chip.
(See drivers/gpio/TODO for details.)
Cc: Joel Stanley <joel@jms.id.au>
Cc: Thierry Reding <treding@nvidia.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Tested-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Andrew Jeffery <andrew@aj.id.au>
Acked-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Reviewed-by: Patrice Chotard <patrice.chotard@st.com>
Link: https://lore.kernel.org/r/20190904140104.32426-1-linus.walleij@linaro.org
The merge of two different patch sets cleaning around in the
main driver include file collided making the function
declarations for gpiochip_[un]lock_as_irq() be defined twice
when gpiolib was unselected. Fix it up.
Cc: YueHaibing <yuehaibing@huawei.com>
Cc: Masahiro Yamada <yamada.masahiro@socionext.com>
Reported-by: kbuild test robot <lkp@intel.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
- use a helper variable for &pdev->dev in gpio-em
- tweak the ifdefs in GPIO headers
- fix function links in HTML docs
- remove an unneeded error message from ixp4xx
- use the optional clk_get in gpio-mxc instead of checking the return value
- a couple improvements in pca953x
- allow to build gpio-lpc32xx on non-lpc32xx targets
-----BEGIN PGP SIGNATURE-----
iQIzBAABCAAdFiEEFp3rbAvDxGAT0sefEacuoBRx13IFAl1uVaMACgkQEacuoBRx
13L0ag//WDVgrtN44Ri+eVuvtBK9Mv4PG8v1LNMzyUCiWta355sdGlWwD0Buc144
bC4zME7+p4fDFM6Yp7yg/RKK5zBzUoVKaFSHxB4BXbBW4vrRjIaTaZAb35lxjhaF
4K5s6DAtPvSsoMPojd6OIOVa0vBXRY/TaRgn3muIyQhINRLSvP55YO18wZWP/EOl
QVoNMxPc0NBLBTEBjtWID6MIc2dXXqJu3AaPpnMc1DRW21zstMBnfSmIq7B+nPcM
SiJzkUbmFhWn19BNhMYGhdYAC7QMsdaHMasipyE6dzWZvSbJOlZcTfTnYpLZSEMl
xz0629suzheUDNCp8okTsg7cp30YzdPNrIi8DuWMPKJI9a2/w3d1uLHp4c1/Efu0
d3ql7p2apBhsWXOzxTOEnQEd4fEWjjVIaItUeNpRboPjoDsW4kv31Nz4GuExxaI2
k9X/YecRn1aIT3vE9njQyUpdFFmM+jslqOrZJuvaz/YDt59ifHFlz3Vbd4UWvju0
U4NuA+OyJR3ZiUvLI4KcR5fThUBQ0J1lmg1S3iCTE9oww6BsudbH2wsEoAzDIJfu
bFd4vjPELg0TjRfrTbUoRyHBUzi7P69HANpEluUM3YQCzHxTcicxicivsP43lhTc
S4yPC743Inn9/kce4YBWRcmTJFnEhX4HQ3oEhQxJZP/ftP91ZSU=
=6y9c
-----END PGP SIGNATURE-----
Merge tag 'gpio-v5.4-updates-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/brgl/linux into devel
gpio: updates for v5.4
- use a helper variable for &pdev->dev in gpio-em
- tweak the ifdefs in GPIO headers
- fix function links in HTML docs
- remove an unneeded error message from ixp4xx
- use the optional clk_get in gpio-mxc instead of checking the return value
- a couple improvements in pca953x
- allow to build gpio-lpc32xx on non-lpc32xx targets
If CONFIG_GPIOLIB is not, gpiochip_lock/unlock_as_irq will
conflict as this:
In file included from sound/soc/codecs/wm5100.c:18:0:
./include/linux/gpio.h:224:19: error: static declaration of gpiochip_lock_as_irq follows non-static declaration
static inline int gpiochip_lock_as_irq(struct gpio_chip *chip,
^~~~~~~~~~~~~~~~~~~~
In file included from sound/soc/codecs/wm5100.c:17:0:
./include/linux/gpio/driver.h:494:5: note: previous declaration of gpiochip_lock_as_irq was here
int gpiochip_lock_as_irq(struct gpio_chip *chip, unsigned int offset);
^~~~~~~~~~~~~~~~~~~~
In file included from sound/soc/codecs/wm5100.c:18:0:
./include/linux/gpio.h:231:20: error: static declaration of gpiochip_unlock_as_irq follows non-static declaration
static inline void gpiochip_unlock_as_irq(struct gpio_chip *chip,
^~~~~~~~~~~~~~~~~~~~~~
In file included from sound/soc/codecs/wm5100.c:17:0:
./include/linux/gpio/driver.h:495:6: note: previous declaration of gpiochip_unlock_as_irq was here
void gpiochip_unlock_as_irq(struct gpio_chip *chip, unsigned int offset);
^~~~~~~~~~~~~~~~~~~~~~
Move them to gpio/driver.h and use CONFIG_GPIOLIB guard this.
Reported-by: Hulk Robot <hulkci@huawei.com>
Fixes: d74be6dfea ("gpio: remove gpiod_lock/unlock_as_irq()")
Signed-off-by: YueHaibing <yuehaibing@huawei.com>
Link: https://lore.kernel.org/r/20190822031817.32888-1-yuehaibing@huawei.com
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
After we switched the two drivers that have .need_valid_mask
set to use the callback for setting up the .valid_mask,
we can just use the presence of the .init_valid_mask()
callback (or the OF reserved ranges, nota bene) to determine
whether to allocate the mask or not and we can drop the
.need_valid_mask field altogether.
Cc: Benjamin Gaignard <benjamin.gaignard@st.com>
Cc: Amelie Delaunay <amelie.delaunay@st.com>
Cc: Stephen Boyd <swboyd@chromium.org>
Cc: Bjorn Andersson <bjorn.andersson@linaro.org>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Link: https://lore.kernel.org/r/20190819093058.10863-1-linus.walleij@linaro.org
It is more helpful for drivers to have the affected fields
directly available when we use the callback to set up the
valid mask. Change this and switch over the only user
(MSM) to use the passed parameters. If we do this we can
also move the mask out of publicly visible struct fields.
Cc: Stephen Boyd <swboyd@chromium.org>
Cc: Bjorn Andersson <bjorn.andersson@linaro.org>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Link: https://lore.kernel.org/r/20190819084904.30027-1-linus.walleij@linaro.or
Reviewed-by: Stephen Boyd <swboyd@chromium.org>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Hierarchical IRQ domains can be used to stack different IRQ
controllers on top of each other.
Bring hierarchical IRQ domains into the GPIOLIB core with the
following basic idea:
Drivers that need their interrupts handled hierarchically
specify a callback to translate the child hardware IRQ and
IRQ type for each GPIO offset to a parent hardware IRQ and
parent hardware IRQ type.
Users have to pass the callback, fwnode, and parent irqdomain
before calling gpiochip_irqchip_add().
We use the new method of just filling in the struct
gpio_irq_chip before adding the gpiochip for all hierarchical
irqchips of this type.
The code path for device tree is pretty straight-forward,
while the code path for old boardfiles or anything else will
be more convoluted requireing upfront allocation of the
interrupts when adding the chip.
One specific use-case where this can be useful is if a power
management controller has top-level controls for wakeup
interrupts. In such cases, the power management controller can
be a parent to other interrupt controllers and program
additional registers when an IRQ has its wake capability
enabled or disabled.
The hierarchical irqchip helper code will only be available
when IRQ_DOMAIN_HIERARCHY is selected to GPIO chips using
this should select or depend on that symbol. When using
hierarchical IRQs, the parent interrupt controller must
also be hierarchical all the way up to the top interrupt
controller wireing directly into the CPU, so on systems
that do not have this we can get rid of all the extra
code for supporting hierarchical irqs.
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Marc Zyngier <marc.zyngier@arm.com>
Cc: Lina Iyer <ilina@codeaurora.org>
Cc: Jon Hunter <jonathanh@nvidia.com>
Cc: Sowjanya Komatineni <skomatineni@nvidia.com>
Cc: Bitan Biswas <bbiswas@nvidia.com>
Cc: linux-tegra@vger.kernel.org
Cc: David Daney <david.daney@cavium.com>
Cc: Masahiro Yamada <yamada.masahiro@socionext.com>
Cc: Brian Masney <masneyb@onstation.org>
Signed-off-by: Thierry Reding <treding@nvidia.com>
Signed-off-by: Brian Masney <masneyb@onstation.org>
Co-developed-by: Brian Masney <masneyb@onstation.org>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Link: https://lore.kernel.org/r/20190808123242.5359-1-linus.walleij@linaro.org
The API, which belongs to GPIO library, is foreign to ACPI headers. Earlier
we moved out I²C out of the latter, and now it's time for
acpi_dev_add_driver_gpios() et al.
For time being the acpi_gpio_get_irq_resource() and acpi_dev_gpio_irq_get()
are left untouched as they need more thought about.
Note, it requires uninline acpi_dev_remove_driver_gpios() to keep purity of
consumer.h.
Cc: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Cc: Liam Girdwood <liam.r.girdwood@linux.intel.com>
Cc: Jie Yang <yang.jie@linux.intel.com>
Cc: Mark Brown <broonie@kernel.org>
Cc: alsa-devel@alsa-project.org (moderated list:INTEL ASoC DRIVERS)
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Link: https://lore.kernel.org/r/20190730104337.21235-3-andriy.shevchenko@linux.intel.com
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Kernel build bot reported a compilation error after the commit
f626d6dfb7 ("gpio: of: Break out OF-only code"):
drivers/gpio/gpiolib-devres.o: In function `devm_gpiod_get_from_of_node':
gpiolib-devres.c:(.text+0x19a): undefined reference to `gpiod_get_from_of_node'
This happens due to move the latter under umbrella of CONFIG_OF_GPIO while
customer.h contains staled data.
Fix it by reshuffling contents of consumer.h to satisfy build dependencies.
Reported-by: kbuild test robot <lkp@intel.com>
Fixes: f626d6dfb7 ("gpio: of: Break out OF-only code"):
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Link: https://lore.kernel.org/r/20190730104337.21235-1-andriy.shevchenko@linux.intel.com
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
The whole struct/function declarations in this header are surrounded
by #ifdef.
As far as I understood, the motivation of this is probably to break
the build earlier if a driver misses to select or depend on correct
CONFIG options in Kconfig.
Since commit 94bed2a9c4 ("Add -Werror-implicit-function-declaration")
no one cannot call functions that have not been declared.
So, I see some benefit in doing this in the cost of uglier headers.
In reality, it would not be so easy to catch missed 'select' or
'depends on' because GPIOLIB, GPIOLIB_IRQCHIP etc. are already selected
by someone else eventually. So, this kind of error, if any, will be
caught by randconfig bots.
In summary, I am not a big fan of cluttered #ifdef nesting, and this
does not matter for normal developers. The code readability wins.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
If gpiolib is disabled, we use the inline stubs from gpio/consumer.h
instead of regular definitions of GPIO API. The stubs for 'optional'
variants of gpiod_get routines return NULL in this case as if the
relevant GPIO wasn't found. This is correct so far.
Calling other (non-gpio_get) stubs from this header triggers a warning
because the GPIO descriptor couldn't have been requested. The warning
however is unconditional (WARN_ON(1)) and is emitted even if the passed
descriptor pointer is NULL.
We don't want to force the users of 'optional' gpio_get to check the
returned pointer before calling e.g. gpiod_set_value() so let's only
WARN on non-NULL descriptors.
Cc: stable@vger.kernel.org
Reported-by: Claus H. Stovgaard <cst@phaseone.com>
Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
