Avoid the unnecessary if-else in pca953x_read_regs() by spltting the
routine into smaller, specialized functions and calling the right one
via a function pointer held in struct pca953x.
Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Avoid the unnecessary if-else in pca953x_write_regs() by splitting
the routine into smaller, specialized functions and calling the right
one via a function pointer held in struct pca953x_chip.
Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
There are multiple places in the driver code where a
switch (chip->chip_type) is used to determine the proper register
offset.
Unduplicate the code by adding a simple structure holding the possible
offsets that differ between the pca953x and pca957x chip families and
use it to avoid the checks.
Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
ARM LPC32xx platform is device-tree only, there is no need to keep
a file with GPIO platform data structures, however some of macro
definitions should be moved to the driver code, which is the only user
of the removed header file.
Signed-off-by: Vladimir Zapolskiy <vz@mleia.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Using a default trigger is a bad idea if using DT to configure
interrupts, as the device's interrupt specifier will always contain
the trigger configuration.
Let's warn about that particular situation, and revert to not
having a default. Hopefully, the couple of drivers still using
this feature will quickly be fixed.
Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
R-Car Gen3's GPIO blocks are identical to Gen2's in every respect.
Based on work for the r8a7795 (R-Car H3) by Ulrich Hecht.
Cc: Ulrich Hecht <ulrich.hecht+renesas@gmail.com>
Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Tested-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
The Aspeed SoCs contain GPIOs banked by letter, where each bank contains
8 pins. The GPIO banks are then grouped in sets of four in the register
layout.
The implementation exposes multiple banks through the one driver and
requests and releases pins via the pinctrl subsystem. The hardware
supports generation of interrupts from all GPIO-capable pins.
A number of hardware features are not yet supported: Configuration of
interrupt direction (ARM or LPC), debouncing, and WDT reset tolerance
for output ports.
Signed-off-by: Joel Stanley <joel@jms.id.au>
Signed-off-by: Alistair Popple <alistair@popple.id.au>
Signed-off-by: Jeremy Kerr <jk@ozlabs.org>
Signed-off-by: Andrew Jeffery <andrew@aj.id.au>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
The recent addition of the regulator support has led to the pca953x_remove
function returning uninitialized data when no platform data pointer is
provided, as gcc warns when using -Wmaybe-uninitialized:
drivers/gpio/gpio-pca953x.c: In function 'pca953x_remove':
drivers/gpio/gpio-pca953x.c:860:9: error: 'ret' may be used uninitialized in this function [-Werror=maybe-uninitialized]
This restores the previous behavior, returning 0 on success.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Fixes: e23efa3111 ("gpio: pca954x: Add vcc regulator and enable it")
Acked-by: Phil Reid <preid@electromag.com.au>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
The Kconfig currently controlling compilation of this code is:
drivers/gpio/Kconfig:config GPIO_VF610
drivers/gpio/Kconfig: def_bool y
...meaning that it currently is not being built as a module by anyone.
Lets remove the couple traces of modular infrastructure use, so that
when reading the driver there is no doubt it is builtin-only.
We delete the MODULE_LICENSE tag etc. since all that information
is now contained at the top of the file in the comments.
We don't replace module.h with init.h since the file already has that.
Cc: Alexandre Courbot <gnurou@gmail.com>
Cc: Stefan Agner <stefan@agner.ch>
Cc: linux-gpio@vger.kernel.org
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
The Kconfig currently controlling compilation of this code is:
drivers/gpio/Kconfig:config GPIO_SPEAR_SPICS
drivers/gpio/Kconfig: bool "ST SPEAr13xx SPI Chip Select as GPIO support"
...meaning that it currently is not being built as a module by anyone.
Lets remove the couple traces of modular infrastructure use, so that
when reading the driver there is no doubt it is builtin-only.
We delete the MODULE_LICENSE tag etc. since all that information
is now contained at the top of the file in the comments.
Also note that MODULE_DEVICE_TABLE is a no-op for non-modular code.
Cc: Alexandre Courbot <gnurou@gmail.com>
Cc: Shiraz Hashim <shiraz.linux.kernel@gmail.com>
Cc: linux-gpio@vger.kernel.org
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
The Kconfig currently controlling compilation of this code is:
drivers/gpio/Kconfig:config GPIO_MXC
drivers/gpio/Kconfig: def_bool y
...meaning that it currently is not being built as a module by anyone.
Lets remove the couple traces of modular infrastructure use, so that
when reading the driver there is no doubt it is builtin-only.
We delete the MODULE_LICENSE tag etc. since all that information
was (or is now) contained at the top of the file in the comments.
Note the original e-mail had a missing/typo'd @ symbol anyway.
We don't replace module.h with init.h since the file already has that.
Cc: Alexandre Courbot <gnurou@gmail.com>
Cc: Daniel Mack <daniel@caiaq.de>
Cc: Juergen Beisert <kernel@pengutronix.de>
Cc: linux-gpio@vger.kernel.org
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
The Kconfig currently controlling compilation of this code is:
drivers/gpio/Kconfig:config GPIO_MSIC
drivers/gpio/Kconfig: bool "Intel MSIC mixed signal gpio support"
...meaning that it currently is not being built as a module by anyone.
Lets remove the couple traces of modular infrastructure use, so that
when reading the driver there is no doubt it is builtin-only.
We delete the MODULE_LICENSE tag etc. since all that information
is already contained at the top of the file in the comments.
We don't replace module.h with init.h since the file already has that.
Cc: Alexandre Courbot <gnurou@gmail.com>
Cc: Mathias Nyman <mathias.nyman@linux.intel.com>
Cc: linux-gpio@vger.kernel.org
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
This patch adds .get_direction method for the gpio_chip structure
of the wcove_gpio driver.
Signed-off-by: Bin Gao <bin.gao@intel.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
This driver is generic and aims to support all Technologic Systems's
boards embedding FPGA GPIOs with an I2C interface.
This driver supports TS-4900, TS-7970, TS-7990 and TS-4100 series.
Signed-off-by: Lucile Quirion <lucile.quirion@savoirfairelinux.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
The if...else... block after the loop can be dropped with
a slight refactoring.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
This patch adds support for the GPIO found in Broadcom's bcm63xx-gpio
chips.
This GPIO controller is used in the following Broadcom SoCs: BCM6338, BCM6345.
It can be used in newer SoCs, without the capability of pin multiplexing.
Signed-off-by: Christian Lamparter <chunkeey@googlemail.com>
Signed-off-by: Álvaro Fernández Rojas <noltari@gmail.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
The Diamond Systems GPIO-MM device features 48 lines of digital I/O via
the emulation of dual 82C55A PPI chips. This driver provides GPIO
support for these 48 channels of digital I/O. The base port addresses
for the devices may be configured via the base array module parameter.
Signed-off-by: William Breathitt Gray <vilhelm.gray@gmail.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
This patch introduces a separate GPIO driver for Intel WhiskeyCove PMIC.
This driver is based on gpio-crystalcove.c.
Changes in v7:
- Fixed various coding style comments from Andy Shevchenko
Changes in v6:
- Removed unnecessary wcove_gpio_remove()
- Used devm_gpiochip_remove() instead of gpiochip_remove()
- Various coding style changes per Mika's comment
Changes in v5:
- Revisited the interrupt handler code to iterate until all pending
interrupts are handled. This change is to avoid missing interrupt
when we're inside the interrupt handler.
- Used regmap_bulk_read() to read address adjacent registers.
Changes in v4:
- Converted CTLI_INTCNT_XX macros to less verbose ones INT_DETECT_XX.
- Add comments about why there is no .pm for the driver.
- Header files re-ordered.
- Various coding style change to address Andy's comments.
Changes in v3:
- Fixed the year in copyright line(2015-->2016).
- Removed DRV_NAME macro.
- Added kernel-doc for regmap_irq_chip of the wcove_gpio structure.
- Line length fix.
Changes in v2:
- Typo fix (Whsikey --> Whiskey).
- Included linux/gpio/driver.h instead of linux/gpio.h
- Implemented .set_single_ended().
- Added GPIO register description.
- Replaced container_of() with gpiochip_get_data().
- Removed unnecessary "if (gpio > WCOVE_VGPIO_NUM" check.
- Removed the device id table and added MODULE_ALIAS().
Signed-off-by: Ajay Thomas <ajay.thomas.david.rajamanickam@intel.com>
Signed-off-by: Bin Gao <bin.gao@intel.com>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
The AXP209 PMIC has a bunch of GPIOs accessible, that are usually used to
control LEDs or backlight.
Add a driver for them
Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
Acked-by: Rob Herring <robh@kernel.org>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Some i2c gpio devices are connected to a switchable power supply
which needs to be enabled prior to probing the device. This patch
allows the drive to enable the devices vcc regulator prior to probing.
Signed-off-by: Phil Reid <preid@electromag.com.au>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
The particularities of this variant are:
- GPIO_XXX_LSB and GPIO_XXX_MSB memory locations are inverted compared
to other variants.
- There is no Edge detection, Rising Edge and Falling Edge registers.
- IRQ flags are cleared when read, no need to write in Status register.
Signed-off-by: Amelie DELAUNAY <amelie.delaunay@st.com>
Signed-off-by: Patrice Chotard <patrice.chotard@st.com>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
This update allows to use registers map as following :
regs[reg_index + offset] instead of
regs[reg_index] + offset
This makes code clearer and will facilitate the addition of STMPE1600
on which LSB and MSB registers are respectively located at addr and addr + 1.
Despite for all others STMPE variant, LSB and MSB registers are respectively
located in reverse order at addr + 1 and addr.
For variant which have 3 registers's bank, we use LSB,CSB and MSB indexes
which contains respectively LSB (or LOW), CSB (or MID) and MSB (or HIGH)
register addresses (STMPE1801/STMPE24xx).
For variant which have 2 registers's bank, we use LSB and CSB indexes only.
In this case the CSB index contains the MSB regs address (STMPE 1601).
Signed-off-by: Patrice Chotard <patrice.chotard@st.com>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
On STMPE801/1801 datasheets, it's mentionned writing
in interrupt status register has no effect, bits are
cleared when reading.
Signed-off-by: Amelie DELAUNAY <amelie.delaunay@st.com>
Signed-off-by: Patrice Chotard <patrice.chotard@st.com>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
By cross-checking STMPE 610/801/811/1601/2401/2403 datasheets,
it appears that edge detection and rising/falling edge detection
is not supported by all STMPE variant:
GPIO GPIO
Edge detection rising/falling
edge detection
610 | X | X |
801 | | |
811 | X | X |
1600 | | |
1601 | X | X |
1801 | | X |
2401 | X | X |
2403 | X | X |
Rework stmpe_dbg_show_one() and stmpe_gpio_irq to correctly
take these cases into account.
Signed-off-by: Patrice Chotard <patrice.chotard@st.com>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
The GPIOLIB is now selectable explicitly, and always available
for all archs. All archs that require GPIOLIB are switched to
select GPIOLIB directly. Delete the hairy ARCH_REQUIRE_GPIOLIB
and ARCH_WANTS_OPTIONAL_GPIOLIB Kconfig symbols.
Cc: Michael Büsch <m@bues.ch>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Core changes:
- The big item is of course the completion of the character
device ABI. It has now replaced and surpassed the former
unmaintainable sysfs ABI: we can now hammer (bitbang)
individual lines or sets of lines and read individual lines
or sets of lines from userspace, and we can also register
to listen to GPIO events from userspace. As a tie-in we
have two new tools in tools/gpio: gpio-hammer and
gpio-event-mon that illustrate the proper use of the new
ABI. As someone said: the wild west days of GPIO are now
over.
- Continued to remove the pointless
ARCH_[WANT_OPTIONAL|REQUIRE]_GPIOLIB Kconfig symbols.
I'm patching hexagon, openrisc, powerpc, sh, unicore,
ia64 and microblaze. These are either ACKed by their
maintainers or patched anyways after a grace period and
no response from maintainers. Some archs (ARM) come in from
their trees, and others (x86) are still not fixed, so I
might send a second pull request to root it out later in
this merge window, or just defer to v4.9.
- The GPIO tools are moved to the tools build system.
New drivers:
- New driver for the MAX77620/MAX20024.
- New driver for the Intel Merrifield.
- Enabled PCA953x for the TI PCA9536.
- Enabled PCA953x for the Intel Edison.
- Enabled R8A7792 in the RCAR driver.
Driver improvements:
- The STMPE and F7188x now supports the .get_direction()
callback.
- The Xilinx driver supports setting multiple lines at
once.
- ACPI support for the Vulcan GPIO controller.
- The MMIO GPIO driver supports device tree probing.
- The Acer One 10 is supported through the _DEP ACPI
attribute.
Cleanups:
- A major cleanup of the OF/DT support code. It is way
easier to read and understand now, probably this improves
performance too.
- Drop a few redundant .owner assignments.
- Remove CLPS711x boardfile support: we are 100% DT.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQIcBAABAgAGBQJXlcT4AAoJEEEQszewGV1zACwQAK5SZr0F5c3QvYbJSiJBCGA7
MZKUYHnYoBpZaPKcFKoOXEM1WOvlABlh9U0y0xkL8gQ6giyKup1wYJJCuYgW29gL
ny4r7Z8rs2Wm1ujL+FLAwuxIwCY3BnhUucp8YiSaHPBuKRfsHorFPvXiAgLZjNYC
Qk3Q48xYW4inw9sy2BbMfsU3CZnkvgy5euooyy1ezwachRhuHdBy/MVCG012PC4s
0d6LGdByEx1uK4NeV7ssPys444M8unep2EWgy6Rvc1U+FmGA487EvL+X8nxTQTj3
uTMxA8nddmZTEeEIqhpRw/dPiFlWxPFwfWmNEre05gKLb/LUK2tgsUOnmIFgVUw/
t41IzdQNLQQZxmiXplZn6s5mAr2VNuTxkRq1CIl4SwQW+Uy4TU3q8aDPkKzsyhiR
yw6o6ul0pQs8UZEggnht8ie6JiSnJ55ehI/nlRxpK/797Ff6Yp4FARs3ZtFnQDDu
SWewnbRatZQ89lvy4BA7QCWeV4Scjk4k/e2HjUAFnkfMDaYqpi4vTdzwnWdVjd+F
hMgu6VnkN3oSE7ZMrKJMh7b7h1uMnIwKBFWbkrlOEuhT1X0ZDsEOBv5juSBPYomN
EOIJUyWqxn0ZfxeONbdbCPteYlfJF+TW/rE9LQMxS1nNwsqw2IQW6NCmrM9Nx6Fv
FP++26nYMTSh82gwOYw3
=NwcK
-----END PGP SIGNATURE-----
Merge tag 'gpio-v4.8-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.8 kernel cycle. The big
news is the completion of the chardev ABI which I'm very happy about
and apart from that it's an ordinary, quite busy cycle. The details
are below.
The patches are tested in linux-next for some time, patches to other
subsystem mostly have ACKs.
I got overly ambitious with configureing lines as input for IRQ lines
but it turns out that some controllers have their interrupt-enable and
input-enabling in orthogonal settings so the assumption that all IRQ
lines are input lines does not hold. Oh well, revert and back to the
drawing board with that.
Core changes:
- The big item is of course the completion of the character device
ABI. It has now replaced and surpassed the former unmaintainable
sysfs ABI: we can now hammer (bitbang) individual lines or sets of
lines and read individual lines or sets of lines from userspace,
and we can also register to listen to GPIO events from userspace.
As a tie-in we have two new tools in tools/gpio: gpio-hammer and
gpio-event-mon that illustrate the proper use of the new ABI. As
someone said: the wild west days of GPIO are now over.
- Continued to remove the pointless ARCH_[WANT_OPTIONAL|REQUIRE]_GPIOLIB
Kconfig symbols. I'm patching hexagon, openrisc, powerpc, sh,
unicore, ia64 and microblaze. These are either ACKed by their
maintainers or patched anyways after a grace period and no response
from maintainers.
Some archs (ARM) come in from their trees, and others (x86) are
still not fixed, so I might send a second pull request to root it
out later in this merge window, or just defer to v4.9.
- The GPIO tools are moved to the tools build system.
New drivers:
- New driver for the MAX77620/MAX20024.
- New driver for the Intel Merrifield.
- Enabled PCA953x for the TI PCA9536.
- Enabled PCA953x for the Intel Edison.
- Enabled R8A7792 in the RCAR driver.
Driver improvements:
- The STMPE and F7188x now supports the .get_direction() callback.
- The Xilinx driver supports setting multiple lines at once.
- ACPI support for the Vulcan GPIO controller.
- The MMIO GPIO driver supports device tree probing.
- The Acer One 10 is supported through the _DEP ACPI attribute.
Cleanups:
- A major cleanup of the OF/DT support code. It is way easier to
read and understand now, probably this improves performance too.
- Drop a few redundant .owner assignments.
- Remove CLPS711x boardfile support: we are 100% DT"
* tag 'gpio-v4.8-1' of git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-gpio: (67 commits)
MAINTAINERS: Add INTEL MERRIFIELD GPIO entry
gpio: dwapb: add missing fwnode_handle_put() in dwapb_gpio_get_pdata()
gpio: merrifield: Protect irq_ack() and gpio_set() by lock
gpio: merrifield: Introduce GPIO driver to support Merrifield
gpio: intel-mid: Make it depend to X86_INTEL_MID
gpio: intel-mid: Sort header block alphabetically
gpio: intel-mid: Remove potentially harmful code
gpio: rcar: add R8A7792 support
gpiolib: remove duplicated include from gpiolib.c
Revert "gpio: convince line to become input in irq helper"
gpiolib: of_find_gpio(): Don't discard errors
gpio: of: Allow overriding the device node
gpio: free handles in fringe cases
gpio: tps65218: Add platform_device_id table
gpio: max77620: get gpio value based on direction
gpio: lynxpoint: avoid potential warning on error path
tools/gpio: add install section
tools/gpio: move to tools buildsystem
gpio: intel-mid: switch to devm_gpiochip_add_data()
gpio: 74x164: Use spi_write() helper instead of open coding
...
fwnode_handle_put() should be used when terminating
device_for_each_child_node() iteration with break or
return to prevent stale device node references from
being left behind.
Generated by Coccinelle.
Fixes: 4ba8cfa79f ("gpio: dwapb: convert device node to fwnode")
Signed-off-by: Wei Yongjun <yongjun_wei@trendmicro.com.cn>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
There is a potential race when two threads do the writes to the same register
in parallel.
Prevent out of order in such case by protecting I/O access by spin lock.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Intel Merrifield platform has a special GPIO controller to
drive pads when they are muxed in corresponding mode.
Intel Merrifield GPIO IP is slightly different here and there
in comparison to the older Intel MID platforms. These differences
include in particular the shaked register offsets, specific
support of level triggered interrupts and wake capable sources,
as well as a pinctrl which is a separate IP.
Instead of uglifying existing driver I decide to provide a new
one slightly based on gpio-intel-mid.c. So, anyone can easily
compare what changes are happened to be here.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Acked-by: Brian J Wood <brian.j.wood@intel.com>
Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
This GPIO controller is a part of Intel MID platforms which are somehow
different to pure PCs. Thus, there is no need that driver is compiled for them.
Replace dependency to X86_INTEL_MID.
While here, fix capitalization of MID abbreviation.
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>
Sort the header inclusion lines by alphabetical order.
While here, update Intel Copyright.
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 commit d56d6b3d7d ("gpio: langwell: add Intel Merrifield support")
doesn't look at all as a proper support for Intel Merrifield and I dare to say
that it distorts the behaviour of the hardware.
The register map is different on Intel Merrifield, i.e. only 6 out of 8
register have the same purpose but none of them has same location in the
address space. The current case potentially harmful to existing hardware since
it's poking registers on wrong offsets and may set some pin to be GPIO output
when connected hardware doesn't expect such.
Besides the above GPIO and pinctrl on Intel Merrifield have been located in
different IP blocks. The functionality has been extended as well, i.e. added
support of level interrupts, special registers for wake capable sources and
thus, in my opinion, requires a completele separate driver.
If someone wondering the existing gpio-intel-mid.c would be converted to actual
pinctrl (which by the fact it is now), though I wouldn't be a volunteer to do
that.
Fixes: d56d6b3d7d ("gpio: langwell: add Intel Merrifield support")
Cc: stable@vger.kernel.org # v3.13+
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>
Renesas R8A7792 SoC is a member of the R-Car gen2 family, add support for
its GPIO controllers.
Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
I stumbled over a build error with COMPILE_TEST and CONFIG_OF
disabled:
drivers/gpio/gpio-tegra.c: In function 'tegra_gpio_probe':
drivers/gpio/gpio-tegra.c:603:9: error: 'struct gpio_chip' has no member named 'of_node'
The problem is that the newly added GPIO_TEGRA Kconfig symbol
does not have a dependency on CONFIG_OF. However, there is another
problem here as the driver gets enabled unconditionally whenever
COMPILE_TEST is set.
This fixes both problems, by making the symbol user-visible
when COMPILE_TEST is set and default-enabled for ARCH_TEGRA=y.
As a side-effect, it is now possible to compile-test a Tegra
kernel with GPIO support disabled, which is harmless.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Fixes: 4dd4dd1d21 ("gpio: tegra: Allow compile test")
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
This reverts commit 7e7c059cb5.
I was wrong about trying to do this, as it breaks the
orthogonality between gpiochips and irqchips.
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Since commit dd34c37aa3 ("gpio: of: Allow -gpio suffix for property
names") when requesting a GPIO from the devicetree gpiolib looks for
properties with both the '-gpio' and the '-gpios' suffix. This was
implemented by first searching for the property with the '-gpios' suffix
and if that yields an error try the '-gpio' suffix. This approach has the
issue that any error returned when looking for the '-gpios' suffix is
silently discarded.
Commit 06fc3b70f1 ("gpio: of: Fix handling for deferred probe for -gpio
suffix") partially addressed the issue by treating the EPROBE_DEFER error
as a special condition. This fixed the case when the property is specified,
but the GPIO provider is not ready yet. But there are other cases in which
of_get_named_gpiod_flags() returns an error even though the property is
specified, e.g. if the specification is incorrect.
of_find_gpio() should only try to look for the property with the '-gpio'
suffix if no property with the '-gpios' suffix was found. If the property
was not found of_get_named_gpiod_flags() will return -ENOENT, so update the
condition to abort and propagate the error to the caller in all other
cases.
This is important for gpiod_get_optinal() and friends to behave correctly
in case the specifier contains errors. Without this patch they'll return
NULL if the property uses the '-gpios' suffix and the specifier contains
errors, which falsely indicates to the caller that no GPIO was specified.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
When registering a GPIO chip, drivers can override the device tree node
associated with the chip by setting the chip's ->of_node field. If set,
this field is supposed to take precedence over the ->parent->of_node
field, but the code doesn't actually do that.
Commit 762c2e46c0 ("gpio: of: remove of_gpiochip_and_xlate() and
struct gg_data") exposes this because it now no longer matches on the
GPIO chip's ->of_node field, but the GPIO device's ->of_node field that
is set using the procedure described above.
Signed-off-by: Thierry Reding <treding@nvidia.com>
Acked-by: Alexandre Courbot <acourbot@nvidia.com>
Reviewed-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
This reverts commit 1e4a806403.
This creates more problems than it solves right now. Compile
testing needs to go in with patches fixing the problems it
uncovers.
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
If we fail when copying the ioctl() struct to userspace we still
need to clean up the cruft otherwise left behind or it will stay
around until the issuing process terminates the file handle.
Reported-by: Alexander Stein <alexander.stein@systec-electronic.com>
Acked-by: Alexander Stein <alexander.stein@systec-electronic.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
This reverts commit 923b93e451.
Make sure consumers do not overwrite gpio flags for pins that have
already been claimed.
While adding support for gpio drivers to refuse a request using
unsupported flags, the order of when the requested flag was checked and
the new flags were applied was reversed to that consumers could
overwrite flags for already requested gpios.
This not only affects device-tree setups where two drivers could request
the same gpio using conflicting configurations, but also allowed user
space to clear gpio flags for already claimed pins simply by attempting
to export them through the sysfs interface. By for example clearing the
FLAG_ACTIVE_LOW flag this way, user space could effectively change the
polarity of a signal.
Reverting this change obviously prevents gpio drivers from doing sanity
checks on the flags in their request callbacks. Fortunately only one
recently added driver (gpio-tps65218 in v4.6) appears to do this, and a
follow up patch could restore this functionality through a different
interface.
Cc: stable <stable@vger.kernel.org> # 4.4
Signed-off-by: Johan Hovold <johan@kernel.org>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
This fixes the issue descirbe in bug 117531
(https://bugzilla.kernel.org/show_bug.cgi?id=117531).
It's a regression introduced in linux 4.5 that causes a Oops at load of
gpio_sch and prevents powering off the computer.
The issue is that sch_gpio_reg_set is called in sch_gpio_probe before
gpio_chip data is initialized with the pointer to the sch_gpio struct. As
sch_gpio_reg_set calls gpiochip_get_data, it returns NULL which causes
the Oops.
The patch follows Mika's advice (https://lkml.org/lkml/2016/5/9/61) and
consists in modifying sch_gpio_reg_get and sch_gpio_reg_set to take a
sch_gpio struct directly instead of a gpio_chip, which avoids the call to
gpiochip_get_data.
Thanks Mika for your patience with me :-)
Cc: stable@vger.kernel.org
Signed-off-by: Colin Pitrat <colin.pitrat@gmail.com>
Acked-by: Alexandre Courbot <acourbot@nvidia.com>
Acked-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
platform_device_id table is needed for adding the tps65218-gpio
module to the mfd_cell array.
Signed-off-by: Keerthy <j-keerthy@ti.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Gpio direction is determined by DIRx bit of GPIO
configuration register, return max77620 gpio value
based on direction in or out.
Signed-off-by: Venkat Reddy Talla <vreddytalla@nvidia.com>
Reviewed-by: Alexandre Courbot <acourbot@nvidia.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
- Driver fixes for i.MX, single register, Tegra and BayTrail.
- MAINTAINERS entry for the documentation
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQIcBAABAgAGBQJXc3S0AAoJEEEQszewGV1zbZoP+wcffLAiH4YWO/iKPpZatSLK
zAtFIYPvzHgITaF8VTyNKvNRiOv+11QECQAw8Eibn2hd28AUGrpPpNkeU6edCFdK
myh/QSROM1VYTCDq76KW+zsRaCkZ9HRPj2HGz3vyqe8pStJgOYlCPY7hKTDdr3/h
Umg01CBlzr74dMIQ51CgfiIAR7IMYBfoE2TU+/kR7C+HaLyRB7sUDSw+/HGkG+g/
5++dwPMbk+Z7J+bDjnKlO+jNcuLrRERwoMGCd2mzu8rvmd7Yh0c0IamKbbiTfZS5
QfT+fI6eVulcStlImAOZdLR79KB2JEdQH/1wSFupABCrucHBVxQiPSisKsa6qzw5
cia6hW8IzLwbGfytYIX89lPYP43FLbUqfjIplCXMZaUIQcnikgmmyIi/VgZAN1AY
Mi1SxXJ8EUtoQ/21nZpYdqIb4kRWiIqmjklSPDc/oiFnGGIuH+X5jnRka4Fws7Cz
1ilGpccfoQL04lvaWpKQK2FnNXU9USPGXg8hV/RXuAjNddrvxa9PQU0NxrVVhR9S
h1u2LVtjx4CELnPY9+hWUgxfXGEGbgv1V4xHOdofytBvfVhf+Qyzbg7Gn5+30s1p
VgVliGHyA0/Up7u8E1HTSsxbioyJkdvZ1A+6ibESJnlnCL5/2oKFhMAbMTdD/QQ9
LXmkKpXY+kWhEM/9z8MV
=e4gh
-----END PGP SIGNATURE-----
Merge tag 'pinctrl-v4.7-3' of git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-pinctrl
Pull pin control fixes from Linus Walleij:
"Here are a bunch of fixes for pin control. Just drivers and a
MAINTAINERS fixup:
- Driver fixes for i.MX, single register, Tegra and BayTrail.
- MAINTAINERS entry for the documentation"
* tag 'pinctrl-v4.7-3' of git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-pinctrl:
pinctrl: baytrail: Fix mingled clock pins
MAINTAINERS: belong Documentation/pinctrl.txt properly
pinctrl: tegra: Fix build dependency
gpio: tegra: Make lockdep class file-scoped
pinctrl: single: Fix missing flush of posted write for a wakeirq
pinctrl: imx: Do not treat a PIN without MUX register as an error
When devres API is in use we are not supposed to call plain gpiochip_remove().
Remove redundant call to gpiochip_remove().
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Acked-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
The error handling is not correct since the commit 3f7dbfd8ee ("gpio:
intel-mid: switch to using gpiolib irqchip helpers"). Switch to devres API to
fix the potential resource leak.
Fixes: commit 3f7dbfd8ee ("gpio: intel-mid: switch to using gpiolib irqchip helpers")
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
The conversion from a DT spec to struct gpio_desc is common between
of_get_named_gpiod_flags() and of_parse_own_gpio(). Factor out the
common code to a new helper, of_xlate_and_get_gpiod_flags().
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Bartosz Golaszewski