- silence error messages on probe deferral in gpio-davinci
- fix a memory leak in gpiolib-of
- fix a potential use-after-free error in gpio-em
-----BEGIN PGP SIGNATURE-----
iQIzBAABCAAdFiEEFp3rbAvDxGAT0sefEacuoBRx13IFAl0sTXoACgkQEacuoBRx
13IwUw//RY5GfIrQYJ6kIqUIntLAmqoosJp/DqYstvByKeR6ca6/kpD93nH+uDQL
OBhP0/FTKefvjfADha5RLee/ee3fIxsVYW76YJh8mwKh8xKWdvZhe9ZfpD4c88Zg
6khUNKE0+uI2RMQ3FRKWE79CNPfllxfUVHTlVLJJOFcrLqDkQqxsVowFiisnWMQI
cpjJZJSnq9fSmTMglTY4XEdI8hFZEJrkM6+FEbF/oW46HDx/XKyasIebXfR9d2ce
o1/AmylR4PAo9w61mWk7oN6TM3MZcCC7nIw0yIJvuzRtRxk3dpdvXIlzCmLU6yHf
IvWHbDYxaY3oQO9aYggZk088nHWC39b30Z+cJwSgB+pGYcETPHWdO1nUtN61FU6y
lfsiR184LrLBHX7pBYJrfeQo7y/xHcSLhZxpT4WAQE/OtFS351OpV9LbBahoflGn
xm3eaN2Zl+YgQ8w29XYKpLc7jpBanQZ2BU86JL77DDQxpqQOb8SgmdQnIxhGwfxE
NS63h8XdYGIB1MioAh9QjeRQ8EIqzwTy3/RxpG+0B3qmwx9CfeFW19pa4pLNHx1V
4IVg8p2XmbxU2eY4uGc7qFQCVYX8/0yClIa90e4xnyAG9xsbkzNssdvEaPq/QccT
rNvPlW0c5HpSw8OAZQfhZlwhKFKCge9Rf37i8Yk0RVOWd9V+eW4=
=QeTx
-----END PGP SIGNATURE-----
Merge tag 'gpio-v5.3-rc1-fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/brgl/linux into fixes
GPIO fixes for v5.3-rc1
- silence error messages on probe deferral in gpio-davinci
- fix a memory leak in gpiolib-of
- fix a potential use-after-free error in gpio-em
This reverts commit fbbf145a0e.
It seems I was misguided in my fixup, which was working at the
time but did not work on the final v5.2.
The patch tried to avoid a quirk the gpiolib code not to treat
"spi-gpio" CS gpios "special" by enforcing them to be active
low, in the belief that since the "spi-gpio" driver was
parsing the device tree on its own, it did not care to inspect
the "spi-cs-high" attribute on the device nodes.
That's wrong. The SPI core was inspecting them inside the
of_spi_parse_dt() funtion and setting SPI_CS_HIGH on the
nodes, and the driver inspected this flag when driving the
line.
As of now, the core handles the GPIO and it will consistently
set the GPIO descriptor to 1 to enable CS, strictly requireing
the gpiolib to invert it. And the gpiolib should indeed
enforce active low on the CS line.
Device trees should of course put the right flag on the GPIO
handles, but it used to not matter. If we don't enforce active
low on "gpio-gpio" we may run into ABI backward compatibility
issues, so revert this.
Cc: linux-spi@vger.kernel.org
Cc: stable@vger.kernel.org
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Link: https://lore.kernel.org/r/20190715204529.9539-1-linus.walleij@linaro.org
Each iteration of for_each_child_of_node puts the previous node, but in
the case of a break from the middle of the loop, there is no put, thus
causing a memory leak. Hence add an of_node_put before the break.
Issue found with Coccinelle.
Cc: <stable@vger.kernel.org>
Signed-off-by: Nishka Dasgupta <nishkadg.linux@gmail.com>
[Bartosz: tweaked the commit message]
Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
Core:
- When a gpio_chip request GPIOs from itself, it can now fully
control the line characteristics, both machine and consumer
flags. This makes a lot of sense, but took some time before I
figured out that this is how it has to work.
- Several smallish documentation fixes.
New drivers:
- The PCA953x driver now supports the TI TCA9539.
- The DaVinci driver now supports the K3 AM654 SoCs.
Driver improvements:
- Major overhaul and hardening of the OMAP driver by Russell
King.
- Starting to move some drivers to the new API passing irq_chip
along with the gpio_chip when adding the gpio_chip instead
of adding it separately.
Unrelated:
- Delete the FMC subsystem.
-----BEGIN PGP SIGNATURE-----
iQIzBAABCAAdFiEElDRnuGcz/wPCXQWMQRCzN7AZXXMFAl0i7gEACgkQQRCzN7AZ
XXOeUA/+JKyI2zebTWBcgtxhn6VQCufMCtFmQl2JkEcy4pT7aBJcGWqFQCBW2Szf
VTtqc8nNa90SZoOzsNbkeQgRjNKGZruMbh0ARUPcW4v3ZJHtUNUEDLTo8c3iyTgS
9k/FTeaTLt4WSZujeAO0O7G4KNnOOlTKLh58dr0PmXUR+0v+fbMhcJqJ9ABueV+V
qENdpkTuG1ZcvzgLhBBEXdt3Plw9ICLWmPXtwY+784ewucVPbyQX7jV4+bBZ25fL
DerCuMIgL5vRWWdiFO6/Jp603rHzZpTnjLJJocXUFiD6zA5rvU2jTWxsnUttjisg
8cTLMyQspsDvBxhEhCJVTuIKotbKH900TSaz+vx20W72/A1euy4y6uVi8FGZo4Ww
KDkzB7anwHyEFKGnlYgHzDrfctgZrhQoyFz808DQRYg1JseZB5oGVDvScrPBD43j
nbNDd8gwG4yp3tFnDx9xjIwQy3Ax4d510rAZyUN2801IlbA1bueq4t6Z2cCucWzX
XA1gCKlXe4BUeitRAoZtqZNZG1ymEysW4jXy1V8xrwtAf8+QSN+xO98akz3VpnQL
ae9q+HtF76fDBY1xFSXT37Ma3+4OR2vMF9QWuo4TCb9j1cL7llf8ZxtUq9LEHbDu
erKLSSnwSFmqJNGSEA5SulGOCR/tRPkClngE9x0XEM6gOD+bs6E=
=8zSV
-----END PGP SIGNATURE-----
Merge tag 'gpio-v5.3-1' of git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-gpio
Pull GPIO updates from Linus Walleij:
"This is the big slew of GPIO changes for the v5.3 kernel cycle. This
is mostly incremental work this time.
Three important things:
- The FMC subsystem is deleted through my tree. This happens through
GPIO as its demise was discussed in relation to a patch decoupling
its GPIO implementation from the standard way of handling GPIO. As
it turns out, that is not the only subsystem it reimplements and
the authors think it is better do scratch it and start over using
the proper kernel subsystems than try to polish the rust shiny. See
the commit (ACKed by the maintainers) for details.
- Arnd made a small devres patch that was ACKed by Greg and goes into
the device core.
- SPDX header change colissions may happen, because at times I've
seen that quite a lot changed during the -rc:s in regards to SPDX.
(It is good stuff, tglx has me convinced, and it is worth the
occasional pain.)
Apart from this is is nothing controversial or problematic.
Summary:
Core:
- When a gpio_chip request GPIOs from itself, it can now fully
control the line characteristics, both machine and consumer flags.
This makes a lot of sense, but took some time before I figured out
that this is how it has to work.
- Several smallish documentation fixes.
New drivers:
- The PCA953x driver now supports the TI TCA9539.
- The DaVinci driver now supports the K3 AM654 SoCs.
Driver improvements:
- Major overhaul and hardening of the OMAP driver by Russell King.
- Starting to move some drivers to the new API passing irq_chip along
with the gpio_chip when adding the gpio_chip instead of adding it
separately.
Unrelated:
- Delete the FMC subsystem"
* tag 'gpio-v5.3-1' of git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-gpio: (87 commits)
Revert "gpio: tegra: Clean-up debugfs initialisation"
gpiolib: Use spinlock_t instead of struct spinlock
gpio: stp-xway: allow compile-testing
gpio: stp-xway: get rid of the #include <lantiq_soc.h> dependency
gpio: stp-xway: improve module clock error handling
gpio: stp-xway: simplify error handling in xway_stp_probe()
gpiolib: Clarify use of non-sleeping functions
gpiolib: Fix references to gpiod_[gs]et_*value_cansleep() variants
gpiolib: Document new gpio_chip.init_valid_mask field
Documentation: gpio: Fix reference to gpiod_get_array()
gpio: pl061: drop duplicate printing of device name
gpio: altera: Pass irqchip when adding gpiochip
gpio: siox: Use devm_ managed gpiochip
gpio: siox: Add struct device *dev helper variable
gpio: siox: Pass irqchip when adding gpiochip
drivers: gpio: amd-fch: make resource struct const
devres: allow const resource arguments
gpio: ath79: Pass irqchip when adding gpiochip
gpio: tegra: Clean-up debugfs initialisation
gpio: siox: Switch to IRQ_TYPE_NONE
...
I ran into an intriguing bug caused by
commit ""spi: gpio: Don't request CS GPIO in DT use-case"
affecting all SPI GPIO devices with an active high
chip select line.
The commit switches the CS gpio handling over to the GPIO
core, which will parse and handle "cs-gpios" from the OF
node without even calling down to the driver to get the
job done.
However the GPIO core handles the standard bindings in
Documentation/devicetree/bindings/spi/spi-controller.yaml
that specifies that active high CS needs to be specified
using "spi-cs-high" in the DT node.
The code in drivers/spi/spi-gpio.c never respected this
and never tried to inspect subnodes to see if they contained
"spi-cs-high" like the gpiolib OF quirks does. Instead the
only way to get an active high CS was to tag it in the
device tree using the flags cell such as
cs-gpios = <&gpio 4 GPIO_ACTIVE_HIGH>;
This alters the quirks to not inspect the subnodes of SPI
masters on "spi-gpio" for the standard attribute "spi-cs-high",
making old device trees work as expected.
This semantic is a bit ambigous, but just allowing the
flags on the GPIO descriptor to modify polarity is what
the kernel at large mostly uses so let's encourage that.
Fixes: 249e2632dc ("spi: gpio: Don't request CS GPIO in DT use-case")
Cc: Andrey Smirnov <andrew.smirnov@gmail.com>
Cc: linux-gpio@vger.kernel.org
Cc: linux-spi@vger.kernel.org
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
The stmmac driver currently ignores the GPIO flags which are passed via
devicetree because it operates with legacy GPIO numbers instead of GPIO
descriptors. stmmac assumes that the GPIO is "active HIGH" by default.
This can be overwritten by setting "snps,reset-active-low" to make the
reset line "active LOW".
Recent Amlogic SoCs (G12A which includes S905X2 and S905D2 as well as
G12B which includes S922X) use GPIOZ_14 or GPIOZ_15 for the PHY reset
line. These GPIOs are special because they are marked as "3.3V input
tolerant open drain" pins which means they can only drive the pin output
LOW (to reset the PHY) or to switch to input mode (to take the PHY out
of reset).
The GPIO subsystem already supports this with the GPIO_OPEN_DRAIN and
GPIO_OPEN_SOURCE flags in the devicetree bindings.
Add the stmmac PHY reset line specific active low parsing to gpiolib-of
so stmmac can be ported to GPIO descriptors while being backwards
compatible with device trees which use the "old" way of specifying the
polarity.
Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
The Freescale SPI chipselects are special: while everyone else
is using "cs-gpios" the Freescale platforms just use "gpios".
Fix this by responding with "gpios" when asking for "cs-gpios"
in a freescale device node, so we hide this pecularity from
the SPI core.
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Since GPIO library operates with enumerator when it's subject to handle
the GPIO lookup flags, it will be better to clearly see what default means.
Thus, introduce GPIO_LOOKUP_FLAGS_DEFAULT entry to describe
the default assumptions.
While here, replace 0 by newly introduced constant.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
The library uses enum gpio_lookup_flags to define the possible
characteristics of GPIO pin. Since enumerator listed only individual
bits the common use of it is in a form of a bitmask of
gpio_lookup_flags GPIO_* values. The more correct type for this is
unsigned long.
Due to above convert all users to use unsigned long instead of
enum gpio_lookup_flags except enumerator definition.
While here, make field and parameter descriptions consistent as well.
Suggested-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
If the call to of_gpiochip_scan_gpios() in of_gpiochip_add() fails, no
error handling is performed. This lead to the need of callers to call
of_gpiochip_remove() on failure, which causes "BAD of_node_put() on ..."
if the failure happened before the call to of_node_get().
Fix this by adding proper error handling.
Note that calling gpiochip_remove_pin_ranges() multiple times causes no
harm: subsequent calls are a no-op.
Fixes: dfbd379ba9 ("gpio: of: Return error if gpio hog configuration failed")
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Reviewed-by: Mukesh Ojha <mojha@codeaurora.org>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
"spi-cs-high" is going to be specified in child node of an SPI
controller's representing attached SPI device, so change the code to
look for it there, instead of checking parent node.
Signed-off-by: Andrey Smirnov <andrew.smirnov@gmail.com>
Cc: Linus Walleij <linus.walleij@linaro.org>
Cc: Bartosz Golaszewski <bgolaszewski@baylibre.com>
Cc: Chris Healy <cphealy@gmail.com>
Cc: linux-gpio@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
SPI GPIO device has more than just "cs-gpio" property in its node and
would request those GPIOs as a part of its initialization. To avoid
applying CS-specific quirk to all of them add a check to make sure
that propname is "cs-gpios".
Signed-off-by: Andrey Smirnov <andrew.smirnov@gmail.com>
Cc: Linus Walleij <linus.walleij@linaro.org>
Cc: Bartosz Golaszewski <bgolaszewski@baylibre.com>
Cc: Chris Healy <cphealy@gmail.com>
Cc: linux-gpio@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Core changes:
- The big change this time around is the irqchip handling in
the qualcomm pin controllers, closely coupled with the
gpiochip. This rework, in a classic fall-between-the-chairs
fashion has been sidestepped for too long. The Qualcomm
IRQchips using the SPMI and SSBI transport mechanisms have
been rewritten to use hierarchical irqchip. This creates
the base from which I intend to gradually pull support for
hierarchical irqchips into the gpiolib irqchip helpers to
cut down on duplicate code. We have too many hacks in the
kernel because people have been working around the missing
hierarchical irqchip for years, and once it was there,
noone understood it for a while. We are now slowly adapting
to using it. This is why this pull requests include changes
to MFD, SPMI, IRQchip core and some ARM Device Trees
pertaining to the Qualcomm chip family. Since Qualcomm have
so many chips and such large deployments it is paramount
that this platform gets this right, and now it (hopefully)
does.
- Core support for pull-up and pull-down configuration, also
from the device tree. When a simple GPIO chip support a
"off or on" pull-up or pull-down resistor, we provide a
way to set this up using machine descriptors or device tree.
If more elaborate control of pull up/down (such as
resistance shunt setting) is required, drivers should be
phased over to use pin control. We do not yet provide a
userspace ABI for this pull up-down setting but I suspect
the makers are going to ask for it soon enough. PCA953x
is the first user of this new API.
- The GPIO mockup driver has been revamped after some
discussion improving the IRQ simulator in the process.
The idea is to make it possible to use the mockup for
both testing and virtual prototyping, e.g. when you do
not yet have a GPIO expander to play with but really
want to get something to develop code around before
hardware is available. It's neat. The blackbox testing
usecase is currently making its way into kernelci.
- ACPI GPIO core preserves non direction flags when updating
flags.
- A new device core helper for devm_platform_ioremap_resource()
is funneled through the GPIO tree with Greg's ACK.
New drivers:
- TQ-Systems QTMX86 GPIO controllers (using port-mapped
I/O)
- Gateworks PLD GPIO driver (vaccumed up from OpenWrt)
- AMD G-Series PCH (Platform Controller Hub) GPIO driver.
- Fintek F81804 & F81966 subvariants.
- PCA953x now supports NXP PCAL6416.
Driver improvements:
- IRQ support on the Nintendo Wii (Hollywood) GPIO.
- get_direction() support for the MVEBU driver.
- Set the right output level on SAMA5D2.
- Drop the unused irq trigger setting on the Spreadtrum
driver.
- Wakeup support for PCA953x.
- A slew of cleanups in the various Intel drivers.
-----BEGIN PGP SIGNATURE-----
iQIcBAABAgAGBQJcgoLEAAoJEEEQszewGV1zjBAP/3OmTFGv49PFmJwSx+PlLiYf
V6/UPaQzq81CGSMtHxbS51TyP9Id7PCfsacbuFYutzn0D1efvl7jrkb8qJ6fVvCM
bl/i6q8ipRTPzAf1hD3QCgCe3BXCA064/OcPrz987oIvI3bJQXsmBjBSXHWr4Cwa
WfB5DX/afn9TK3XHhMQGfw5f0d+TtnKAs90RTTVKiz9Ow8eFYZJOhgPkvhCR3Gi9
YJIzIAiwhHZ7/zauo4JAYFU/O/Z3YEC5zeLne2ItebzNooRkSxdz0c9Hs7HlCZmU
930Uv9jNN89N3vPqpZzAHtPvwDOmAILMWvKy9xRSp+eoIukarRJgF7ALPk7QWxK1
yy+tGj4dXBQ6tI8W3wUN1WgjNpii3K1HbJ+1LQVQL2/q9o+3YXXqmjdjuw7C8YYV
5ystNrUppkgfIIciHL4lhqw3wKJJhVEAns2V245hIitoShT+RvIg8GQbGZmWlQFd
YsHbynqHL9iwfRNv26kEqZXZOo/4D1t6Scw+OPVyba2Wyttf+qbmg+XaYMqFaxYW
mfydvdtymeCOUIPJMzw58KGPUTXJ4UPLENyayXNUHokr1a8VO8OIthY7zwi0CpvJ
IcsAY9zoGxvfbRV922mlIsw3oOBcM2IN2lC9sY469ZVnjBrdC3rsQpIBZr+Vzz8i
YlUfXLSGSyuUZUz//2eG
=VoVC
-----END PGP SIGNATURE-----
Merge tag 'gpio-v5.1-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.1 cycle:
Core changes:
- The big change this time around is the irqchip handling in the
qualcomm pin controllers, closely coupled with the gpiochip. This
rework, in a classic fall-between-the-chairs fashion has been
sidestepped for too long.
The Qualcomm IRQchips using the SPMI and SSBI transport mechanisms
have been rewritten to use hierarchical irqchip. This creates the
base from which I intend to gradually pull support for hierarchical
irqchips into the gpiolib irqchip helpers to cut down on duplicate
code.
We have too many hacks in the kernel because people have been
working around the missing hierarchical irqchip for years, and once
it was there, noone understood it for a while. We are now slowly
adapting to using it.
This is why this pull requests include changes to MFD, SPMI,
IRQchip core and some ARM Device Trees pertaining to the Qualcomm
chip family. Since Qualcomm have so many chips and such large
deployments it is paramount that this platform gets this right, and
now it (hopefully) does.
- Core support for pull-up and pull-down configuration, also from the
device tree. When a simple GPIO chip supports an "off or on" pull-up
or pull-down resistor, we provide a way to set this up using
machine descriptors or device tree.
If more elaborate control of pull up/down (such as resistance shunt
setting) is required, drivers should be phased over to use pin
control. We do not yet provide a userspace ABI for this pull
up-down setting but I suspect the makers are going to ask for it
soon enough. PCA953x is the first user of this new API.
- The GPIO mockup driver has been revamped after some discussion
improving the IRQ simulator in the process.
The idea is to make it possible to use the mockup for both testing
and virtual prototyping, e.g. when you do not yet have a GPIO
expander to play with but really want to get something to develop
code around before hardware is available. It's neat. The blackbox
testing usecase is currently making its way into kernelci.
- ACPI GPIO core preserves non direction flags when updating flags.
- A new device core helper for devm_platform_ioremap_resource() is
funneled through the GPIO tree with Greg's ACK.
New drivers:
- TQ-Systems QTMX86 GPIO controllers (using port-mapped I/O)
- Gateworks PLD GPIO driver (vaccumed up from OpenWrt)
- AMD G-Series PCH (Platform Controller Hub) GPIO driver.
- Fintek F81804 & F81966 subvariants.
- PCA953x now supports NXP PCAL6416.
Driver improvements:
- IRQ support on the Nintendo Wii (Hollywood) GPIO.
- get_direction() support for the MVEBU driver.
- Set the right output level on SAMA5D2.
- Drop the unused irq trigger setting on the Spreadtrum driver.
- Wakeup support for PCA953x.
- A slew of cleanups in the various Intel drivers"
* tag 'gpio-v5.1-1' of git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-gpio: (110 commits)
gpio: gpio-omap: fix level interrupt idling
gpio: amd-fch: Set proper output level for direction_output
x86: apuv2: remove unused variable
gpio: pca953x: Use PCA_LATCH_INT
platform/x86: fix PCENGINES_APU2 Kconfig warning
gpio: pca953x: Fix dereference of irq data in shutdown
gpio: amd-fch: Fix type error found by sparse
gpio: amd-fch: Drop const from resource
gpio: mxc: add check to return defer probe if clock tree NOT ready
gpio: ftgpio: Register per-instance irqchip
gpio: ixp4xx: Add DT bindings
x86: pcengines apuv2 gpio/leds/keys platform driver
gpio: AMD G-Series PCH gpio driver
drivers: depend on HAS_IOMEM for devm_platform_ioremap_resource()
gpio: tqmx86: Set proper output level for direction_output
gpio: sprd: Change to use SoC compatible string
gpio: sprd: Use SoC compatible string instead of wildcard string
gpio: of: Handle both enable-gpio{,s}
gpio: of: Restrict enable-gpio quirk to regulator-gpio
gpio: davinci: use devm_platform_ioremap_resource()
...
Handle both enable-gpio and enable-gpios properties of the GPIO
regulator in the quirk. The later is the preferred modern name
of the property.
Signed-off-by: Marek Vasut <marek.vasut+renesas@gmail.com>
Cc: Geert Uytterhoeven <geert+renesas@glider.be>
Cc: Jan Kotas <jank@cadence.com>
Cc: Linus Walleij <linus.walleij@linaro.org>
Cc: Mark Brown <broonie@kernel.org>
Cc: Thierry Reding <treding@nvidia.com>
Cc: Wolfram Sang <wsa+renesas@sang-engineering.com>
Cc: linux-renesas-soc@vger.kernel.org
To: linux-gpio@vger.kernel.org
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Commit 0e7d6f9401 ("gpio: of: Apply regulator-gpio quirk only to
enable-gpios") breaks the device tree ABI specified in the device tree
bindings for fixed regulators (compatible "regulator-fixed"). According
to these bindings the polarity of the GPIO is exclusively controlled by
the presence or absence of the enable-active-high property. As such the
polarity quirk implemented in of_gpio_flags_quirks() must be applied to
the GPIO specified for fixed regulators.
However, commit 0e7d6f9401 ("gpio: of: Apply regulator-gpio quirk only
to enable-gpios") restricted the quirk to the enable-gpios property for
fixed regulators as well, whereas according to the commit message itself
it should only apply to "regulator-gpio" compatible device tree nodes.
Fix this by actually implementing what the offending commit intended,
which is to ensure that the quirk is applied to the GPIO specified by
the "enable-gpio" property for the "regulator-gpio" bindings only.
This fixes a regression on Jetson TX1 where the fixed regulator for the
HDMI +5V pin relies on the flags quirk for the proper polarity.
Fixes: 0e7d6f9401 ("gpio: of: Apply regulator-gpio quirk only to enable-gpios")
Signed-off-by: Thierry Reding <treding@nvidia.com>
Tested-by: Marek Vasut <marek.vasut@gmail.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Since commit d6cd33ad71 ("regulator: gpio: Convert to use descriptors")
the GPIO regulator had inverted the polarity of the control GPIO. This
problem manifested itself on systems with DT containing the following
description (snippet from salvator-common.dtsi):
gpios = <&gpio5 1 GPIO_ACTIVE_HIGH>;
gpios-states = <1>;
states = <3300000 1
1800000 0>;
Prior to the aforementioned commit, the gpio-regulator code used
gpio_request_array() to claim the GPIO(s) specified in the "gpios"
DT node, while the commit changed that to devm_gpiod_get_index().
The legacy gpio_request_array() calls gpio_request_one() and then
gpiod_request(), which parses the DT flags of the "gpios" node and
populates the GPIO descriptor flags field accordingly.
The new devm_gpiod_get_index() calls gpiod_get_index(), then
of_find_gpio(), of_get_named_gpiod_flags() with flags != NULL,
and then of_gpio_flags_quirks(). Since commit a603a2b8d8
("gpio: of: Add special quirk to parse regulator flags"),
of_gpio_flags_quirks() contains a quirk for regulator-gpio
which was never triggered by the legacy gpio_request_array()
code path, but is triggered by devm_gpiod_get_index() code
path.
This quirk checks whether a GPIO is associated with a fixed
or gpio-regulator and if so, checks two additional conditions.
First, whether such GPIO is active-low, and if so, ignores the
active-low flag. Second, whether the regulator DT node does
have an "enable-active-high" property and if the property is
NOT present, sets the GPIO flags as active-low.
The second check triggers a problem, since it is applied to all
GPIOs associated with a gpio-regulator, rather than only on the
"enable" GPIOs, as the old code did. This changes the way the
gpio-regulator interprets the DT description of the control
GPIOs.
The old code using gpio_request_array() explicitly parsed the
"enable-active-high" DT property and only applied it to the
GPIOs described in the "enable-gpios" DT node, and only if
those were present.
This patch fixes the quirk code by only applying the quirk
to "enable-gpios", thus restoring the old behavior.
Signed-off-by: Marek Vasut <marek.vasut+renesas@gmail.com>
Cc: Geert Uytterhoeven <geert+renesas@glider.be>
Cc: Jan Kotas <jank@cadence.com>
Cc: Linus Walleij <linus.walleij@linaro.org>
Cc: Mark Brown <broonie@kernel.org>
Cc: Wolfram Sang <wsa+renesas@sang-engineering.com>
Cc: linux-renesas-soc@vger.kernel.org
To: linux-gpio@vger.kernel.org
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
This commit adds support for configuring the pull-up and pull-down
resistors available in some GPIO controllers. While configuring
pull-up/pull-down is already possible through the pinctrl subsystem,
some GPIO controllers, especially simple ones such as GPIO expanders
on I2C, don't have any pinmuxing capability and therefore do not use
the pinctrl subsystem.
This commit implements the GPIO_PULL_UP and GPIO_PULL_DOWN flags,
which can be used from the Device Tree, to enable a pull-up or
pull-down resistor on a given GPIO.
The flag is simply propagated all the way to the core GPIO subsystem,
where it is used to call the gpio_chip ->set_config callback with the
appropriate existing PIN_CONFIG_BIAS_* values.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
The SPI chip selects were not properly inspected due to
a logic inversion. This made SPI GPIOs not work.
Cc: Jan Kotas <jank@cadence.com>
Reported-by: Jan Kotas <jank@cadence.com>
Tested-by: Jan Kotas <jank@cadence.com>
Fixes: f3186dd876 ("spi: Optionally use GPIO descriptors for CS GPIOs")
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Mark Brown <broonie@kernel.org>
The device tree bindings for the MMC card detect and
write protect lines specify that these should be active
low unless "cd-inverted" or "wp-inverted" has been
specified.
However that is not how the kernel code has worked. It
has always respected the flags passed to the phandle in
the device tree, but respected the "cd-inverted" and
"wp-inverted" flags such that if those are set, the
polarity will be the inverse of that specified in the
device tree.
Switch to behaving like the old code did and fix the
regression.
Fixes: 81c85ec15a ("gpio: OF: Parse MMC-specific CD and WP properties")
Cc: Bartosz Golaszewski <bgolaszewski@baylibre.com>
Cc: Guenter Roeck <linux@roeck-us.net>
Reported-by: Guenter Roeck <linux@roeck-us.net>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
When retrieveing CD (card detect) and WP (write protect)
GPIO handles from the device tree, make sure to assign
them active low by default unless the "cd-inverted" or
"wp-inverted" properties are set. These properties mean
that respective signal is active HIGH since the SDHCI
specification stipulates that this kind of signals
should be treated as active LOW.
If the twocell GPIO flag is also specified as active
low, well that's nice and we will silently ignore the
tautological specification.
If however the GPIO line is specified as active low
in the GPIO flasg cell and "cd-inverted" or "wp-inverted"
is also specified, the latter takes precedence and we
print a warning.
The current effect on the MMC slot-gpio core are as
follows:
For CD GPIOs: no effect. The current code in
mmc/core/host.c calls mmc_gpiod_request_cd() with
the "override_active_level" argument set to true,
which means that whatever the GPIO descriptor
thinks about active low/high will be ignored, the
core will use the MMC_CAP2_CD_ACTIVE_HIGH to keep
track of this and reads the raw value from the
GPIO descriptor, totally bypassing gpiolibs inversion
semantics. I plan to clean this up at a later point
passing the handling of inversion semantics over
to gpiolib, so this patch prepares the ground for
that.
Fow WP GPIOs: this is probably fixing a bug, because
the code in mmc/core/host.c calls mmc_gpiod_request_ro()
with the "override_active_level" argument set to false,
which means it will respect the inversion semantics of
the gpiolib and ignore the MMC_CAP2_RO_ACTIVE_HIGH
flag for everyone using this through device tree.
However the code in host.c confusingly goes to great
lengths setting up the MMC_CAP2_RO_ACTIVE_HIGH flag
from the GPIO descriptor and by reading the "wp-inverted"
property of the node. As far as I can tell this is all
in vain and the inversion is broken: device trees that
use "wp-inverted" do not work as intended, instead the
only way to actually get inversion on a line is by
setting the second cell flag to GPIO_ACTIVE_HIGH (which
will be the default) or GPIO_ACTIVE_LOW if they want
the proper MMC semantics. Presumably all device trees do
this right but we need to parse and handle this properly.
Cc: linux-mmc@vger.kernel.org
Cc: linux-gpio@vger.kernel.org
Cc: Bartosz Golaszewski <bgolaszewski@baylibre.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
It's easy to verify that the change of drivers/gpio/gpiolib-of.c license
header to SPDX standard changes the license from GPLv2+ to GPLv2, and
this change corrects it.
Fixes: dae5f0afcf ("gpio: Use SPDX header for core library")
Signed-off-by: Vladimir Zapolskiy <vz@mleia.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Core changes:
- A patch series from Hans Verkuil to make it possible to
enable/disable IRQs on a GPIO line at runtime and drive GPIO
lines as output without having to put/get them from scratch.
The irqchip callbacks have been improved so that they can
use only the fastpatch callbacks to enable/disable irqs
like any normal irqchip, especially the gpiod_lock_as_irq()
has been improved to be callable in fastpath context.
A bunch of rework had to be done to achieve this but it is
a big win since I never liked to restrict this to slowpath.
The only call requireing slowpath was try_module_get() and
this is kept at the .request_resources() slowpath callback.
In the GPIO CEC driver this is a big win sine a single
line is used for both outgoing and incoming traffic, and
this needs to use IRQs for incoming traffic while actively
driving the line for outgoing traffic.
- Janusz Krzysztofik improved the GPIO array API to pass a
"cookie" (struct gpio_array) and a bitmap for setting or
getting multiple GPIO lines at once. This improvement
orginated in a specific need to speed up an OMAP1 driver and
has led to a much better API and real performance gains
when the state of the array can be used to bypass a lot
of checks and code when we want things to go really fast.
The previous code would minimize the number of calls
down to the driver callbacks assuming the CPU speed was
orders of magnitude faster than the I/O latency, but this
assumption was wrong on several platforms: what we needed
to do was to profile and improve the speed on the hot
path of the array functions and this change is now
completed.
- Clean out the painful and hard to grasp BNF experiments
from the device tree bindings. Future approaches are looking
into using JSON schema for this purpose. (Rob Herring
is floating a patch series.)
New drivers:
- The RCAR driver now supports r8a774a1 (RZ/G2M).
- Synopsys GPIO via CREGs driver.
Major improvements:
- Modernization of the EP93xx driver to use irqdomain and
other contemporary concepts.
- The ingenic driver has been merged into the Ingenic pin
control driver and removed from the GPIO subsystem.
- Debounce support in the ftgpio010 driver.
-----BEGIN PGP SIGNATURE-----
iQIcBAABAgAGBQJbzdyOAAoJEEEQszewGV1zfYcP/0HBEAOPhHD/i5OQxfKs1msh
mFT/t/IbTmRpCgbEv4CDx4Kc/InE0sUnQr1TL/1WvU6uObM6Ncxq5Z90MvyrgzYu
BqQHq2k2tORvkVSNRxcfD/BAAoo1EerXts1kDhutvdKfepfS6DxpENwzvsFgkVlq
2jj1cdZztjv8A+9cspHDpQP+jDvl1VSc10nR5fRu1TttSpUwzRJaB30NBNXJmMJc
5KUr67lEbsQRPsBvFErU11bydPqhfT+pXmODcfIwS0EtATQ8WC5mkSb/Ooei0fvT
oZ7uR3Os8tMf7isOKssEyFabKwhnfOEt6TBt9em0TfUtInOo0Dc7r8TfBcn57fyZ
xg2R9DQEVRfac8bjhF/BI5KHuN9IMGDDvj6XApumQVliZbISRjMnh3jte6RpcV0A
Ejqz8FeDY13qvEdOnW1EPpwmXdDVWiEAq0ebGLStKNls+/4gB2HmyxGUOzJf+og5
hujsxcJzGQqjCe0moeY/1d7vsy0ZjbHoS+p5fy79U212y2O7onEzFU92AX89bxKC
rx2eCNmiZxCUy1nqu8edO62VnH6QdnqG3o+a4DJfCSHPvFM/E/NX9zHemZubQQ4I
rYXNy4bL4tEG9cqWMfBxWrpiDZw7H6l8kXwdZG8IMyRU9BcKu96amgZ+jBXwzoaB
JZelAAUWB9APghJYFr7o
=YosT
-----END PGP SIGNATURE-----
Merge tag 'gpio-v4.20-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 v4.20 series:
Core changes:
- A patch series from Hans Verkuil to make it possible to
enable/disable IRQs on a GPIO line at runtime and drive GPIO lines
as output without having to put/get them from scratch.
The irqchip callbacks have been improved so that they can use only
the fastpatch callbacks to enable/disable irqs like any normal
irqchip, especially the gpiod_lock_as_irq() has been improved to be
callable in fastpath context.
A bunch of rework had to be done to achieve this but it is a big
win since I never liked to restrict this to slowpath. The only call
requireing slowpath was try_module_get() and this is kept at the
.request_resources() slowpath callback. In the GPIO CEC driver this
is a big win sine a single line is used for both outgoing and
incoming traffic, and this needs to use IRQs for incoming traffic
while actively driving the line for outgoing traffic.
- Janusz Krzysztofik improved the GPIO array API to pass a "cookie"
(struct gpio_array) and a bitmap for setting or getting multiple
GPIO lines at once.
This improvement orginated in a specific need to speed up an OMAP1
driver and has led to a much better API and real performance gains
when the state of the array can be used to bypass a lot of checks
and code when we want things to go really fast.
The previous code would minimize the number of calls down to the
driver callbacks assuming the CPU speed was orders of magnitude
faster than the I/O latency, but this assumption was wrong on
several platforms: what we needed to do was to profile and improve
the speed on the hot path of the array functions and this change is
now completed.
- Clean out the painful and hard to grasp BNF experiments from the
device tree bindings. Future approaches are looking into using JSON
schema for this purpose. (Rob Herring is floating a patch series.)
New drivers:
- The RCAR driver now supports r8a774a1 (RZ/G2M).
- Synopsys GPIO via CREGs driver.
Major improvements:
- Modernization of the EP93xx driver to use irqdomain and other
contemporary concepts.
- The ingenic driver has been merged into the Ingenic pin control
driver and removed from the GPIO subsystem.
- Debounce support in the ftgpio010 driver"
* tag 'gpio-v4.20-1' of git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-gpio: (116 commits)
gpio: Clarify kerneldoc on gpiochip_set_chained_irqchip()
gpio: Remove unused 'irqchip' argument to gpiochip_set_cascaded_irqchip()
gpio: Drop parent irq assignment during cascade setup
mmc: pwrseq_simple: Fix incorrect handling of GPIO bitmap
gpio: fix SNPS_CREG kconfig dependency warning
gpiolib: Initialize gdev field before is used
gpio: fix kernel-doc after devres.c file rename
gpio: fix doc string for devm_gpiochip_add_data() to not talk about irq_chip
gpio: syscon: Fix possible NULL ptr usage
gpiolib: Show correct direction from the beginning
pinctrl: msm: Use init_valid_mask exported function
gpiolib: Add init_valid_mask exported function
GPIO: add single-register GPIO via CREG driver
dt-bindings: Document the Synopsys GPIO via CREG bindings
gpio: mockup: use device properties instead of platform_data
gpio: Slightly more helpful debugfs
gpio: omap: Remove set but not used variable 'dev'
gpio: omap: drop omap_gpio_list
Accept partial 'gpio-line-names' property.
gpio: omap: get rid of the conditional PM runtime calls
...
Use the SPDX headers and cut down on boilerplate to indicate the
license in the core gpiolib implementation.
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
The SPI chipselects are assumed to be active low in the current
binding, so when we want to use GPIO descriptors and handle
the active low/high semantics in gpiolib, we need a special
parsing quirk to deal with this.
We check for the property "spi-cs-high" and if that is
NOT present we assume the CS line is active low.
If the line is tagged as active low in the device tree and
has no "spi-cs-high" property all is fine, the device
tree and the SPI bindings are in agreement.
If the line is tagged as active high in the device tree with
the second cell flag and has no "spi-cs-high" property we
enforce active low semantics (as this is the exception we can
just tag on the flag).
If the line is tagged as active low with the second cell flag
AND tagged with "spi-cs-high" the SPI active high property
takes precedence and we print a warning.
Cc: Mark Brown <broonie@kernel.org>
Cc: linux-spi@vger.kernel.org
Cc: Geert Uytterhoeven <geert@linux-m68k.org>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
gpiochip_add_data_with_key() adds the gpiochip to the gpio_devices list
before of_gpiochip_add() is called, but it's only the latter which sets
the ->of_xlate function pointer. gpiochip_find() can be called by
someone else between these two actions, and it can find the chip and
call of_gpiochip_match_node_and_xlate() which leads to the following
crash due to a NULL ->of_xlate().
Unhandled prefetch abort: page domain fault (0x01b) at 0x00000000
Modules linked in: leds_gpio(+) gpio_generic(+)
CPU: 0 PID: 830 Comm: insmod Not tainted 4.18.0+ #43
Hardware name: ARM-Versatile Express
PC is at (null)
LR is at of_gpiochip_match_node_and_xlate+0x2c/0x38
Process insmod (pid: 830, stack limit = 0x(ptrval))
(of_gpiochip_match_node_and_xlate) from (gpiochip_find+0x48/0x84)
(gpiochip_find) from (of_get_named_gpiod_flags+0xa8/0x238)
(of_get_named_gpiod_flags) from (gpiod_get_from_of_node+0x2c/0xc8)
(gpiod_get_from_of_node) from (devm_fwnode_get_index_gpiod_from_child+0xb8/0x144)
(devm_fwnode_get_index_gpiod_from_child) from (gpio_led_probe+0x208/0x3c4 [leds_gpio])
(gpio_led_probe [leds_gpio]) from (platform_drv_probe+0x48/0x9c)
(platform_drv_probe) from (really_probe+0x1d0/0x3d4)
(really_probe) from (driver_probe_device+0x78/0x1c0)
(driver_probe_device) from (__driver_attach+0x120/0x13c)
(__driver_attach) from (bus_for_each_dev+0x68/0xb4)
(bus_for_each_dev) from (bus_add_driver+0x1a8/0x268)
(bus_add_driver) from (driver_register+0x78/0x10c)
(driver_register) from (do_one_initcall+0x54/0x1fc)
(do_one_initcall) from (do_init_module+0x64/0x1f4)
(do_init_module) from (load_module+0x2198/0x26ac)
(load_module) from (sys_finit_module+0xe0/0x110)
(sys_finit_module) from (ret_fast_syscall+0x0/0x54)
One way to fix this would be to rework the hairy registration sequence
in gpiochip_add_data_with_key(), but since I'd probably introduce a
couple of new bugs if I attempted that, simply add a check for a
non-NULL of_xlate function pointer in
of_gpiochip_match_node_and_xlate(). This works since the driver looking
for the gpio will simply fail to find the gpio and defer its probe and
be reprobed when the driver which is registering the gpiochip has fully
completed its probe.
Signed-off-by: Vincent Whitchurch <vincent.whitchurch@axis.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
In preparation to remove the node name pointer from struct device_node,
convert printf users to use the %pOFn format specifier.
Cc: Linus Walleij <linus.walleij@linaro.org>
Cc: linux-gpio@vger.kernel.org
Signed-off-by: Rob Herring <robh@kernel.org>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Core changes:
- Add a new API for explicitly naming GPIO consumers, when needed.
- Don't let userspace set values on input lines. While we do not
think anyone would do this crazy thing we better plug the hole
before someone uses it and think it's a nifty feature.
- Avoid calling chip->request() for unused GPIOs.
New drivers/subdrivers:
- The Mediatek MT7621 is supported which is a big win for OpenWRT
and similar router distributions using this chip, as it seems
every major router manufacturer on the planet has made products
using this chip:
https://wikidevi.com/wiki/MediaTek_MT7621
- The Tegra 194 is now supported.
- The IT87 driver now supports IT8786E and IT8718F super-IO
chips.
- Add support for Rockchip RK3328 in the syscon GPIO driver.
Driver changes:
- Handle the get/set_multiple() properly on MMIO chips with
inverted direction registers. We didn't have this problem
until a new chip appear that has get/set registers AND
inverted direction bits, OK now we handle it.
- A patch series making more error codes percolate upward
properly for different errors on gpiochip_lock_as_irq().
- Get/set multiple for the OMAP driver, accelerating these
multiple line operations if possible.
- A coprocessor interface for the Aspeed driver. Sometimes a few
GPIO lines need to be grabbed by a co-processor for doing
automated tasks, sometimes they are available as GPIO lines.
By adding an explicit API in this driver we make it possible
for the two line consumers to coexist. (This work was
made available on the ib-aspeed branch, which may be appearing
in other pull requests.)
- Implemented .get_direction() and open drain in the SCH311x
driver.
- Continuing cleanup of included headers in GPIO drivers.
-----BEGIN PGP SIGNATURE-----
iQIcBAABAgAGBQJbdDIRAAoJEEEQszewGV1zSVcP/j+dj4HL6R1l8nK4pSqDhY++
Sz7TS5sg7IKa5uLQa7fiheOWllwxJy/gwZ73GjHDxbkT3pol2MlL8ByxC9u7gmm8
4N4xpW0gxO5vMbkbwVj/BdL6qN//JNiwlfp+RtHO74rjUIBgc2At1qL6vul5FEPm
T1HUuyzpZ/jd/+CyGR4kg1FrvncMUrStQOdKWN4pI8qFEzFfsGXSeJ+GCBSCjYwD
A2Ybad6uuBfdTjrWp2AV4GpKmdKwFeQPzPjm8/CKi97nyeOckNYjDJ+M/1xUR+bb
sghn3yJf7+FKO8Qmh+ATvjauPBuDbX5d39FgmFEJRk+ay4Uf2GviroHlwzyWjOi2
5TUaRBubTJM8wFXICCvFvoK8CYLfJEmjJjkHeL12lkkmOlzlCRtcQ0aOLFM+37Ga
T7Z6uloEbFK6lT1P6Q/1pfCEUOhofWKdwlWaPxs+7slhKojVJw092wu7J+arKoX9
uLTIe9qAgi3pDRlAkZLrnNwoKTXm18K8KtTv/Uiq8n+s+JRuxA9pAoki5u242lXF
ow22OnTgGE3hc2D3o4H1yUPZYoxG9H6iDdir0eEnZpp61xboj44iRgvyDu4LxajS
mPOtigcu2qaCEx6EDHTgLIvlKsyQAJmsb0cZ6K4OM3EtUMDfC3WbBzs/VVF//pUa
rb+6ruWdwkzXd+ZrnvBq
=4+uQ
-----END PGP SIGNATURE-----
Merge tag 'gpio-v4.19-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 v4.19 kernel cycle.
I don't know if anything in particular stands out. Maybe the Aspeed
coprocessor thing from Benji: Aspeed is doing baseboard management
chips (BMC's) for servers etc.
These Aspeed's are ARM processors that exist inside (I guess) Intel
servers, and they are moving forward to using mainline Linux in those.
This is one of the pieces of the puzzle to achive that. They are doing
OpenBMC, it's pretty cool: https://lwn.net/Articles/683320/
Summary:
Core changes:
- Add a new API for explicitly naming GPIO consumers, when needed.
- Don't let userspace set values on input lines. While we do not
think anyone would do this crazy thing we better plug the hole
before someone uses it and think it's a nifty feature.
- Avoid calling chip->request() for unused GPIOs.
New drivers/subdrivers:
- The Mediatek MT7621 is supported which is a big win for OpenWRT and
similar router distributions using this chip, as it seems every
major router manufacturer on the planet has made products using
this chip: https://wikidevi.com/wiki/MediaTek_MT7621
- The Tegra 194 is now supported.
- The IT87 driver now supports IT8786E and IT8718F super-IO chips.
- Add support for Rockchip RK3328 in the syscon GPIO driver.
Driver changes:
- Handle the get/set_multiple() properly on MMIO chips with inverted
direction registers. We didn't have this problem until a new chip
appear that has get/set registers AND inverted direction bits, OK
now we handle it.
- A patch series making more error codes percolate upward properly
for different errors on gpiochip_lock_as_irq().
- Get/set multiple for the OMAP driver, accelerating these multiple
line operations if possible.
- A coprocessor interface for the Aspeed driver. Sometimes a few GPIO
lines need to be grabbed by a co-processor for doing automated
tasks, sometimes they are available as GPIO lines. By adding an
explicit API in this driver we make it possible for the two line
consumers to coexist. (This work was made available on the
ib-aspeed branch, which may be appearing in other pull requests.)
- Implemented .get_direction() and open drain in the SCH311x driver.
- Continuing cleanup of included headers in GPIO drivers"
* tag 'gpio-v4.19-1' of git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-gpio: (80 commits)
gpio: it87: Add support for IT8613
gpio: it87: add support for IT8718F Super I/O.
gpiolib: Avoid calling chip->request() for unused gpios
gpio: tegra: Include the right header
gpio: mmio: Fix up inverted direction registers
gpio: xilinx: Use the right include
gpio: timberdale: Include the right header
gpio: tb10x: Use the right include
gpiolib: Fix of_node inconsistency
gpio: vr41xx: Bail out on gpiochip_lock_as_irq() error
gpio: uniphier: Bail out on gpiochip_lock_as_irq() error
gpio: xgene-sb: Don't shadow error code of gpiochip_lock_as_irq()
gpio: em: Don't shadow error code of gpiochip_lock_as_irq()
gpio: dwapb: Don't shadow error code of gpiochip_lock_as_irq()
gpio: bcm-kona: Don't shadow error code of gpiochip_lock_as_irq()
gpiolib: Don't shadow error code of gpiochip_lock_as_irq()
gpio: syscon: rockchip: add GRF GPIO support for rk3328
gpio: omap: Add get/set_multiple() callbacks
gpio: pxa: remove set but not used variable 'gpio_offset'
gpio-it87: add support for IT8786E Super I/O
...
Some platforms are not setting of_node in the driver. On these platforms
defining gpio-reserved-ranges on device tree leads to kernel crash.
It is due to some parts of the gpio core relying on the driver to set up
of_node,while other parts do themselves.This inconsistent behaviour leads
to a crash.
gpiochip_add_data_with_key() calls gpiochip_init_valid_mask() with of_node
as NULL. of_gpiochip_add() fills "of_node" and calls
of_gpiochip_init_valid_mask().
The fix is to move the assignment to chip->of_node from of_gpiochip_add()
to gpiochip_add_data_with_key().
Signed-off-by: Biju Das <biju.das@bp.renesas.com>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Tested-by: Geert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
This fixes up the handling of fixed regulator polarity
inversion flags: while I remembered to fix it for the
undocumented "reg-fixed-voltage" I forgot about the
official "regulator-fixed" binding, there are two ways
to do a fixed regulator.
The error was noticed and fixed.
Fixes: a603a2b8d8 ("gpio: of: Add special quirk to parse regulator flags")
Cc: Mark Brown <broonie@kernel.org>
Cc: Thierry Reding <thierry.reding@gmail.com>
Reported-by: Thierry Reding <thierry.reding@gmail.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
The new helper returns index of the matching string in an array.
We are going to use it here.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
- Sync dtc to upstream version v1.4.6-9-gaadd0b65c987. This adds a bunch
more warnings (hidden behind W=1).
- Build dtc lexer and parser files instead of using shipped versions.
- Rework overlay apply API to take an FDT as input and apply overlays in
a single step.
- Add a phandle lookup cache. This improves boot time by hundreds of
msec on systems with large DT.
- Add trivial mcp4017/18/19 potentiometers bindings.
- Remove VLA stack usage in DT code.
-----BEGIN PGP SIGNATURE-----
iQItBAABCAAXBQJaxiUdEBxyb2JoQGtlcm5lbC5vcmcACgkQ+vtdtY28YcM0+w/+
L7nkug1Hz2476eRrsn5bm6oOO0vCrhQcDTJ/AlvU1YO8XBVgGEetLDs8drmvD0/O
FQDcpumX6G0eFoHTnTNWD7keM+0nY5jZBIAqKQNa9a0HKkjYc4HO5Ot9E02XG8W8
759vvCcGeJpysoCls9u8OplzqiDyNVQJd1a0fLivtafdKypuE/Ywh15wrzckPO+F
bxqWQd+uwm98ZVz8/o3vfYtAOJmA06A+hsyVLXYu7iKQcXYVxi+ZNbRV44MQ50NI
1w5m8GgtWe4A2lpXjmeXk1VmLPO3eEgQKnBoH7gcJmCHaVg/SVfMgBscuGSQZRQa
rQvaYRUNGJ0Mtji8EZpZb5Vip4ZCDtZCQBB3snN24CvGXI6WuIIg/8ncXt0AfLqn
pxFmC32ZcwvJR2NCpPVfTgILm6foT9IzJWKl6SQLVtqqVp9nPFua7T3l8AQak7FB
2MMaaqh7L0l0za0ZgArZZo/IWUHRb0MwZdXAkqBZlQ6f3IBqGQeKCnkclAeH8qYr
OorCOmC2OlKXLPHoz8XHeBzPRdnv1dQ//gEkKXBJ2igLU03hRWv9dxnGju/45sun
Ifo79uBAUc9s3F4Kjd/zs2iLztuPrYCSICHtJh9LPeOxoV1ZUNt+6Cm23yQ014Uo
/GsFW+lzh7c9wB1eETjPHd1WuYXiSrmE4zvbdykyLCk=
=ZWpa
-----END PGP SIGNATURE-----
Merge tag 'devicetree-for-4.17' of git://git.kernel.org/pub/scm/linux/kernel/git/robh/linux
Pull DeviceTree updates from Rob Herring:
- Sync dtc to upstream version v1.4.6-9-gaadd0b65c987. This adds a
bunch more warnings (hidden behind W=1).
- Build dtc lexer and parser files instead of using shipped versions.
- Rework overlay apply API to take an FDT as input and apply overlays
in a single step.
- Add a phandle lookup cache. This improves boot time by hundreds of
msec on systems with large DT.
- Add trivial mcp4017/18/19 potentiometers bindings.
- Remove VLA stack usage in DT code.
* tag 'devicetree-for-4.17' of git://git.kernel.org/pub/scm/linux/kernel/git/robh/linux: (26 commits)
of: unittest: fix an error code in of_unittest_apply_overlay()
of: unittest: move misplaced function declaration
of: unittest: Remove VLA stack usage
of: overlay: Fix forgotten reference to of_overlay_apply()
of: Documentation: Fix forgotten reference to of_overlay_apply()
of: unittest: local return value variable related cleanups
of: unittest: remove unneeded local return value variables
dt-bindings: trivial: add various mcp4017/18/19 potentiometers
of: unittest: fix an error test in of_unittest_overlay_8()
of: cache phandle nodes to reduce cost of of_find_node_by_phandle()
dt-bindings: rockchip-dw-mshc: use consistent clock names
MAINTAINERS: Add linux/of_*.h headers to appropriate subsystems
scripts: turn off some new dtc warnings by default
scripts/dtc: Update to upstream version v1.4.6-9-gaadd0b65c987
scripts/dtc: generate lexer and parser during build instead of shipping
powerpc: boot: add strrchr function
of: overlay: do not include path in full_name of added nodes
of: unittest: clean up changeset test
arm64/efi: Make strrchr() available to the EFI namespace
ARM: boot: add strrchr function
...
Some qcom platforms make some GPIOs or pins unavailable for use by
non-secure operating systems, and thus reading or writing the registers
for those pins will cause access control issues. Add support for a DT
property to describe the set of GPIOs that are available for use so that
higher level OSes are able to know what pins to avoid reading/writing.
Non-DT platforms can add support by directly updating the
chip->valid_mask.
Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
Signed-off-by: Stephen Boyd <swboyd@chromium.org>
Tested-by: Timur Tabi <timur@codeaurora.org>
Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
of_get_named_gpiod_flags() used directly in of_find_gpio() or indirectly
through of_find_spi_gpio() or of_find_regulator_gpio() can return
-EPROBE_DEFER. This gets overwritten by the subsequent of_find_*_gpio()
calls.
This patch fixes this by trying of_find_spi_gpio() or
of_find_regulator_gpio() only if deferred probing was not requested by
the previous of_get_named_gpiod_flags() call.
Fixes: 6a537d4846 ("gpio: of: Support regulator nonstandard GPIO properties")
Fixes: c858233902 ("gpio: of: Support SPI nonstandard GPIO properties")
Signed-off-by: Chen-Yu Tsai <wens@csie.org>
[Augmented to fit with Maxime's patch]
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Commits c858233902 ("gpio: of: Support SPI nonstandard GPIO properties")
and 6a537d4846 ("gpio: of: Support regulator nonstandard GPIO
properties") have introduced a regression in the way error codes from
of_get_named_gpiod_flags are handled.
Previously, those errors codes were returned immediately, but the two
commits mentioned above are now overwriting the error pointer, meaning that
whatever value has been returned will be dropped in favor of whatever the
two new functions will return.
This might not be a big deal except for EPROBE_DEFER, on which GPIOlib
customers will depend on, and that will now be returned as an hard error
which means that they will not probe anymore, instead of gently deferring
their probe.
Since EPROBE_DEFER basically means that we have found a valid property but
there was no GPIO controller registered to handle it, fix this issues by
returning it as soon as we encounter it.
Fixes: c858233902 ("gpio: of: Support SPI nonstandard GPIO properties")
Fixes: 6a537d4846 ("gpio: of: Support regulator nonstandard GPIO properties")
Signed-off-by: Maxime Ripard <maxime.ripard@bootlin.com>
[Fold in fix to the fix]
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Platforms like 96boards have a standardized connector/expansion
slot that exposes signals like GPIOs to expansion boards in an
SoC agnostic way. We'd like the DT overlays for the expansion
boards to be written once without knowledge of the SoC on the
other side of the connector. This avoids the unscalable
combinatorial explosion of a different DT overlay for each
expansion board and SoC pair.
Now that we have nexus support in the OF core let's change the
function call here that parses the phandle lists of gpios to use
the nexus variant. This allows us to remap phandles and their
arguments through any number of nexus nodes and end up with the
actual gpio provider being used.
Cc: Pantelis Antoniou <pantelis.antoniou@konsulko.com>
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Cc: Mark Brown <broonie@kernel.org>
Signed-off-by: Stephen Boyd <stephen.boyd@linaro.org>
Signed-off-by: Rob Herring <robh@kernel.org>
Core changes:
- Disallow open drain and open source flags to be set
simultaneously. This doesn't make electrical sense, and would
the hardware actually respond to this setting, the result
would be short circuit.
- ACPI GPIO has a new core infrastructure for handling quirks.
The quirks are there to deal with broken ACPI tables centrally
instead of pushing the work to individual drivers. In the world
of BIOS writers, the ACPI tables are perfect. Until they find a
mistake in it. When such a mistake is found, we can patch it
with a quirk. It should never happen, the problem is that it
happens. So we accomodate for it.
- Several documentation updates.
- Revert the patch setting up initial direction state from
reading the device. This was causing bad things for drivers
that can't read status on all its pins. It is only affecting
debugfs information quality.
- Label descriptors with the device name if no explicit label is
passed in.
- Pave the ground for transitioning SPI and regulators to use
GPIO descriptors by implementing some quirks in the device tree
GPIO parsing code.
New drivers:
- New driver for the Access PCIe IDIO 24 family.
Other:
- Major refactorings and improvements to the GPIO mockup driver
used for test and verification.
- Moved the AXP209 driver over to pin control since it gained a
pin control back-end. These patches will appear (with the same
hashes) in the pin control pull request as well.
- Convert the onewire GPIO driver w1-gpio to use descriptors.
This is merged here since the W1 maintainers send very few
pull requests and he ACKed it.
- Start to clean up driver headers using <linux/gpio.h> to just
use <linux/gpio/driver.h> as appropriate.
-----BEGIN PGP SIGNATURE-----
iQIcBAABAgAGBQJacIW6AAoJEEEQszewGV1z9b0P/jxWKaCAGFTTu/HZQ79RBAFq
w33nIazzoh+88sN7A9xKexpr4ibOxiCvOwkTtrUBNaxGGy5fslj4+OY5BzunEfBK
1vYxyEqtenvvZK03pOd6CSfHKV+vD5ngnVHGdtGzRvtmDDiSgtzqyEyUhQcXM+l7
PrEh6qrd4TBZezlVR8kn5eqcmclkCBVSQCuLSq+ThMmCKRZuOdf1Im3D6eBzh1/N
P81HdcglqbSsfUl1RcFiHs9Z+KcZOq83CNl2Ej1LePK2JBZbmkx9dR+WSJmV1u4P
6wvzFcQDhfGEiiteg2BS5c+o6aAyShpuRNut+2MLre8icmdfpqUEqFotHbfQjW5y
sqaejGsJ5aHcRBq7UUM+F9s1R0iN3tlafi3L0WEhl0Tn5huRQq3Uqcw6e5l+XrWd
0h+b5PbKJZO/iqzRhSl+rhc0V2CFDJOCwvY+JX6356fvrcF0T6LhvKfDYtKU3Iyb
HB0RG1OcYe228f96azvafCkFyBIYX9mqHBvOXpQQgrZQYXfN1rupLvpOhxC+Wbvn
nsGE2bdD6HA1bytTbkxbL+QWP7faHf5YVcZpaN7UWbO3sOzL46fj8eHwHUim95Tr
pR5kDZRhZd8+9SCNZ/ttpaEbis9MOqS/3Mlxrj4GXtfFFmR53hjFy2bG/Z7R2RB0
MlSEJRc8iDIs+1j3D2RR
=k5nL
-----END PGP SIGNATURE-----
Merge tag 'gpio-v4.16-1' of git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-gpio
Pull GPIO updates from Linus Walleij:
"The is the bulk of GPIO changes for the v4.16 kernel cycle. It is
pretty calm this time around I think. I even got time to get to things
like starting to clean up header includes.
Core changes:
- Disallow open drain and open source flags to be set simultaneously.
This doesn't make electrical sense, and would the hardware actually
respond to this setting, the result would be short circuit.
- ACPI GPIO has a new core infrastructure for handling quirks. The
quirks are there to deal with broken ACPI tables centrally instead
of pushing the work to individual drivers. In the world of BIOS
writers, the ACPI tables are perfect. Until they find a mistake in
it. When such a mistake is found, we can patch it with a quirk. It
should never happen, the problem is that it happens. So we
accomodate for it.
- Several documentation updates.
- Revert the patch setting up initial direction state from reading
the device. This was causing bad things for drivers that can't read
status on all its pins. It is only affecting debugfs information
quality.
- Label descriptors with the device name if no explicit label is
passed in.
- Pave the ground for transitioning SPI and regulators to use GPIO
descriptors by implementing some quirks in the device tree GPIO
parsing code.
New drivers:
- New driver for the Access PCIe IDIO 24 family.
Other:
- Major refactorings and improvements to the GPIO mockup driver used
for test and verification.
- Moved the AXP209 driver over to pin control since it gained a pin
control back-end. These patches will appear (with the same hashes)
in the pin control pull request as well.
- Convert the onewire GPIO driver w1-gpio to use descriptors. This is
merged here since the W1 maintainers send very few pull requests
and he ACKed it.
- Start to clean up driver headers using <linux/gpio.h> to just use
<linux/gpio/driver.h> as appropriate"
* tag 'gpio-v4.16-1' of git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-gpio: (103 commits)
gpio: Timestamp events in hardirq handler
gpio: Fix kernel stack leak to userspace
gpio: Fix a documentation spelling mistake
gpio: Documentation update
gpiolib: remove redundant initialization of pointer desc
gpio: of: Fix NPE from OF flags
gpio: stmpe: Delete an unnecessary variable initialisation in stmpe_gpio_probe()
gpio: stmpe: Move an assignment in stmpe_gpio_probe()
gpio: stmpe: Improve a size determination in stmpe_gpio_probe()
gpio: stmpe: Use seq_putc() in stmpe_dbg_show()
gpio: No NULL owner
gpio: stmpe: i2c transfer are forbiden in atomic context
gpio: davinci: Include proper header
gpio: da905x: Include proper header
gpio: cs5535: Include proper header
gpio: crystalcove: Include proper header
gpio: bt8xx: Include proper header
gpio: bcm-kona: Include proper header
gpio: arizona: Include proper header
gpio: amd8111: Include proper header
...
Some calls to of_get_named_gpio() calls sets the flags
argument to NULL because they are not interested in the
flags. This caused a null pointer exception since we were
unconditionally using these flags. Fix it.
Fixes: 6a537d4846 ("gpio: of: Support regulator nonstandard GPIO properties")
Cc: Heiner Kallweit <hkallweit1@gmail.com>
Reported-by: Heiner Kallweit <hkallweit1@gmail.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
While most GPIOs are indicated to be active low or open drain using
their twocell flags, we have legacy regulator bindings to take into
account.
Add a quirk respecting the special boolean active-high and open
drain flags when parsing regulator nodes for GPIOs.
This makes it possible to get rid of duplicated inversion semantics
handling in the regulator core and any regulator drivers parsing
and handling this separately.
Unfortunately the old regulator inversion semantics are specified
such that the presence or absence of "enable-active-high" solely
controls the semantics, so we cannot deprecate this in favor
of the phandle-provided inversion flag, instead any such phandle
inversion flag provided in the second cell of a GPIO handle must be
actively ignored, so we print a warning to contain the situation
and make things easy for the users.
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Before it was clearly established that all GPIO properties in the
device tree shall be named "foo-gpios" (with the deprecated variant
"foo-gpio" for single lines) we unfortunately merged a few bindings
for regulators with random phandle names.
As we want to switch the GPIO regulator driver to using descriptors,
we need devm_gpiod_get() to return something reasonable when looking
up these in the device tree.
Put in a special #ifdef:ed kludge to do this special lookup only
for the regulator case and gets compiled out if we're not enabling
regulators. Supply a whitelist with properties we accept.
Cc: Rob Herring <robh@kernel.org>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Before it was clearly established that all GPIO properties in the
device tree shall be named "foo-gpios" (with the deprecated variant
"foo-gpio" for single lines) we unfortunately merged a few bindings
which named the lines "gpio-foo" instead.
This is most prominent in the GPIO SPI driver in Linux which names
the lines "gpio-sck", "gpio-mosi" and "gpio-miso".
As we want to switch the GPIO SPI driver to using descriptors, we
need devm_gpiod_get() to return something reasonable when looking
up these in the device tree.
Put in a special #ifdef:ed kludge to do this special lookup only
for the SPI case and gets compiled out if we're not enabling SPI.
If we have more oddly defined legacy GPIOs like this, they can be
handled in a similar manner.
Reviewed-by: Rob Herring <robh@kernel.org>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Following commit 9427ecbed4 ("gpio: Rework of_gpiochip_set_names()
to use device property accessors"), "gpio-line-names" DT property is
not retrieved anymore when chip->parent is not set by the driver.
This is due to OF based property reads having been replaced by device
based property reads.
This patch fixes that by making use of
fwnode_property_read_string_array() instead of
device_property_read_string_array() and handing over either
of_fwnode_handle(chip->of_node) or dev_fwnode(chip->parent)
to that function.
Fixes: 9427ecbed4 ("gpio: Rework of_gpiochip_set_names() to use device property accessors")
Cc: stable@vger.kernel.org
Signed-off-by: Christophe Leroy <christophe.leroy@c-s.fr>
Acked-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
General support for state persistence is added to gpiolib with the
introduction of a new pinconf parameter to propagate the request to
hardware. The existing persistence support for sleep is adapted to
include hardware support if the GPIO driver provides it. Persistence
continues to be enabled by default; in-kernel consumers can opt out, but
userspace (currently) does not have a choice.
The *_SLEEP_MAY_LOSE_VALUE and *_SLEEP_MAINTAIN_VALUE symbols are
renamed, dropping the SLEEP prefix to reflect that the concept is no
longer sleep-specific. I feel that renaming to just *_MAY_LOSE_VALUE
could initially be misinterpreted, so I've further changed the symbols
to *_TRANSITORY and *_PERSISTENT to address this.
The sysfs interface is modified only to keep consistency with the
chardev interface in enforcing persistence for userspace exports.
Signed-off-by: Andrew Jeffery <andrew@aj.id.au>
Reviewed-by: Charles Keepax <ckeepax@opensource.cirrus.com>
Acked-by: Rob Herring <robh@kernel.org>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Literally.
I expect "lose" was meant here, rather than "loose", though you could feasibly
use a somewhat uncommon definition of "loose" to mean what would be meant by
"lose": "Loose the hounds" for instance, as in "Release the hounds".
Substituting in "value" for "hounds" gives "release the value", and makes some
sense, but futher substituting back to loose gives "loose the value" which
overall just seems a bit anachronistic.
Instead, use modern, pragmatic English and save a character.
Cc: Russell Currey <ruscur@russell.cc>
Signed-off-by: Andrew Jeffery <andrew@aj.id.au>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Add descriptions for missing fields and fix up some parameter references
to match the code.
Signed-off-by: Thierry Reding <treding@nvidia.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Now that we have a custom printf format specifier, convert users of
full_name to use %pOF instead. This is preparation to remove storing
of the full path string for each node.
Signed-off-by: Rob Herring <robh@kernel.org>
Cc: Tien Hock Loh <thloh@altera.com>
Cc: Linus Walleij <linus.walleij@linaro.org>
Cc: Alexandre Courbot <gnurou@gmail.com>
Cc: Brian Norris <computersforpeace@gmail.com>
Cc: Florian Fainelli <f.fainelli@gmail.com>
Cc: bcm-kernel-feedback-list@broadcom.com
Cc: Michal Simek <michal.simek@xilinx.com>
Cc: "Sören Brinkmann" <soren.brinkmann@xilinx.com>
Cc: linux-gpio@vger.kernel.org
Cc: linux-arm-kernel@lists.infradead.org
Acked-by: Gregory Fong <gregory.0xf0@gmail.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Add new flags to allow users to specify that they are not concerned with
the status of GPIOs whilst in a sleep/low power state.
Signed-off-by: Charles Keepax <ckeepax@opensource.wolfsonmicro.com>
Acked-by: Rob Herring <robh@kernel.org>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Currently, the GPIO interface is said to Open Drain if it is Single
Ended and active LOW. Similarly, it is said as Open Source if it is
Single Ended and active HIGH.
The active HIGH/LOW is used in the interface for setting the pin
state to HIGH or LOW when enabling/disabling the interface.
In Open Drain interface, pin is set to HIGH by putting pin in
high impedance and LOW by driving to the LOW.
In Open Source interface, pin is set to HIGH by driving pin to
HIGH and set to LOW by putting pin in high impedance.
With above, the Open Drain/Source is unrelated to the active LOW/HIGH
in interface. There is interface where the enable/disable of interface
is ether active LOW or HIGH but it is Open Drain type.
Hence decouple the Open Drain with Single Ended + Active LOW and
Open Source with Single Ended + Active HIGH.
Adding different flag for the Open Drain/Open Source which is valid
only when Single ended flag is enabled.
Signed-off-by: Laxman Dewangan <ldewangan@nvidia.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Linus Walleij