This patch sets the gpio_chip names option with an array of GPIO line
names that match the manual documentation for the ACCES 104-DIO-48E.
This should make it easier for users to identify which GPIO line
corresponds to a respective GPIO pin on the device.
Signed-off-by: William Breathitt Gray <vilhelm.gray@gmail.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Setting driver_data was necessary to access private data in the
ws16c48_remove function. Now that the ws16c48_remove function is gone,
driver_data is no longer used. This patch removes the relevant code.
Signed-off-by: William Breathitt Gray <vilhelm.gray@gmail.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Setting driver_data was necessary to access private data in the
gpiomm_remove function. Now that the gpiomm_remove function is gone,
driver_data is no longer used. This patch removes the relevant code.
Signed-off-by: William Breathitt Gray <vilhelm.gray@gmail.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Setting driver_data was necessary to access private data in the
idio_16_remove function. Now that the idio_16_remove function is gone,
driver_data is no longer used. This patch removes the relevant code.
Signed-off-by: William Breathitt Gray <vilhelm.gray@gmail.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Setting driver_data was necessary to access private data in the
idi_48_remove function. Now that the idi_48_remove function is gone,
driver_data is no longer used. This patch removes the relevant code.
Signed-off-by: William Breathitt Gray <vilhelm.gray@gmail.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Setting driver_data was necessary to access private data in the
dio48e_remove function. Now that the dio48e_remove function is gone,
driver_data is no longer used. This patch removes the relevant code.
Signed-off-by: William Breathitt Gray <vilhelm.gray@gmail.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Use regmap API to save some lines of codes and have
debugfs support for all of the MCP's registers.
Signed-off-by: Sebastian Reichel <sre@kernel.org>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
The devm_ resource manager functions allow memory to be automatically
released when a device is unbound. This patch takes advantage of the
resource manager functions and replaces the gpiochip_add_data call and
request_irq call with the devm_gpiochip_add_data call and
devm_request_irq call respectively. In addition, the ws16c48_remove
function has been removed as no longer necessary due to the use of the
relevant devm_ resource manager functions.
Signed-off-by: William Breathitt Gray <vilhelm.gray@gmail.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
The devm_ resource manager functions allow memory to be automatically
released when a device is unbound. This patch takes advantage of the
resource manager functions and replaces the gpiochip_add_data call with
the devm_gpiochip_add_data call. In addition, the gpiomm_remove function
has been removed as no longer necessary due to the use of the relevant
devm_ resource manager functions.
Signed-off-by: William Breathitt Gray <vilhelm.gray@gmail.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
The devm_ resource manager functions allow memory to be automatically
released when a device is unbound. This patch takes advantage of the
resource manager functions and replaces the gpiochip_add_data call and
request_irq call with the devm_gpiochip_add_data call and
devm_request_irq call respectively. In addition, the idio_16_remove
function has been removed as no longer necessary due to the use of the
relevant devm_ resource manager functions.
Signed-off-by: William Breathitt Gray <vilhelm.gray@gmail.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
The devm_ resource manager functions allow memory to be automatically
released when a device is unbound. This patch takes advantage of the
resource manager functions and replaces the gpiochip_add_data call and
request_irq call with the devm_gpiochip_add_data call and
devm_request_irq call respectively. In addition, the idi_48_remove
function has been removed as no longer necessary due to the use of the
relevant devm_ resource manager functions.
Signed-off-by: William Breathitt Gray <vilhelm.gray@gmail.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
The devm_ resource manager functions allow memory to be automatically
released when a device is unbound. This patch takes advantage of the
resource manager functions and replaces the gpiochip_add_data call and
request_irq call with the devm_gpiochip_add_data call and
devm_request_irq call respectively. In addition, the dio48e_remove
function has been removed as no longer necessary due to the use of the
relevant devm_ resource manager functions.
Signed-off-by: William Breathitt Gray <vilhelm.gray@gmail.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Currently we already have two pin configuration related callbacks
available for GPIO chips .set_single_ended() and .set_debounce(). In
future we expect to have even more, which does not scale well if we need
to add yet another callback to the GPIO chip structure for each possible
configuration parameter.
Better solution is to reuse what we already have available in the
generic pinconf.
To support this, we introduce a new .set_config() callback for GPIO
chips. The callback takes a single packed pin configuration value as
parameter. This can then be extended easily beyond what is currently
supported by just adding new types to the generic pinconf enum.
If the GPIO driver is backed up by a pinctrl driver the GPIO driver can
just assign gpiochip_generic_config() (introduced in this patch) to
.set_config and that will take care configuration requests are directed
to the pinctrl driver.
We then convert the existing drivers over .set_config() and finally
remove the .set_single_ended() and .set_debounce() callbacks.
Suggested-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
This is less straight-forward than one would hope, as some banks only
have 4 pins rather than 8, others are output only, yet more (W and
X, already supported) are input-only, and in the case of the g4 SoC bank
AC doesn't exist.
Add some structs to describe the varying properties of different banks
and integrate mechanisms to deny requests for unsupported
configurations.
Signed-off-by: Andrew Jeffery <andrew@aj.id.au>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
The Aspeed SoCs have more GPIOs than can be represented with A-Z. The
documentation uses two letter names such as AA and AB, so make the names
a three-character array in the bank struct to accommodate this.
Signed-off-by: Joel Stanley <joel@jms.id.au>
Signed-off-by: Andrew Jeffery <andrew@aj.id.au>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Exar XR17V352/354/358 chips have 16 multi-purpose inputs/outputs which
can be controlled using gpio interface.
Add the gpio specific code.
Signed-off-by: Sudip Mukherjee <sudip.mukherjee@codethink.co.uk>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
The WinSystems WS16C48 provides registers where 8 lines of GPIO may be
set at a time. This patch add support for the set_multiple callback
function, thus allowing multiple GPIO output lines to be set more
efficiently in groups.
Signed-off-by: William Breathitt Gray <vilhelm.gray@gmail.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
The Diamond Systems GPIO-MM series provides registers where 8 lines of
GPIO may be set at a time. This patch add support for the set_multiple
callback function, thus allowing multiple GPIO output lines to be set
more efficiently in groups.
Signed-off-by: William Breathitt Gray <vilhelm.gray@gmail.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
The ACCES 104-IDIO-16 series provides registers where 8 lines of GPIO
may be set at a time. This patch add support for the set_multiple
callback function, thus allowing multiple GPIO output lines to be set
more efficiently in groups.
Signed-off-by: William Breathitt Gray <vilhelm.gray@gmail.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
The ACCES 104-DIO-48E series provides registers where 8 lines of GPIO
may be set at a time. This patch add support for the set_multiple
callback function, thus allowing multiple GPIO output lines to be set
more efficiently in groups.
Signed-off-by: William Breathitt Gray <vilhelm.gray@gmail.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
This is a heavy edit/rewrite of the GPIO driver for the Gemini
SoC from arch/arm/mach-gemini/gpio.c.
This rewrite uses all the best-in-class helper like generic
GPIO and GPIOLIB_IRQCHIP and has been tested on ITian Square One
Gemini-based NAS/router.
Cc: Janos Laube <janos.dev@gmail.com>
Cc: Paulius Zaleckas <paulius.zaleckas@gmail.com>
Cc: Hans Ulli Kroll <ulli.kroll@googlemail.com>
Cc: Florian Fainelli <f.fainelli@gmail.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
With the current redesign of driver it's not necessary to have
custom .xlate() as the gpiolib will assign default of_gpio_simple_xlate().
Suggested-by: Grygorii Strashko <grygorii.strashko@ti.com>
Signed-off-by: Keerthy <j-keerthy@ti.com>
Reviewed-by: Grygorii Strashko <grygorii.strashko@ti.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Update GPIO driver to support Multiple GPIO controllers by updating
the base of subsequent GPIO chips with total of previous chips
gpio count so that gpio_add_chip gets unique numbers.
Signed-off-by: Keerthy <j-keerthy@ti.com>
Reviewed-by: Grygorii Strashko <grygorii.strashko@ti.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
The Davinci GPIO driver is implemented to work with one monolithic
Davinci GPIO platform device which may have up to Y(144) gpios.
The Davinci GPIO driver instantiates number of GPIO chips with
max 32 gpio pins per each during initialization and one IRQ domain.
So, the current GPIO's opjects structure is:
<platform device> Davinci GPIO controller
|- <gpio0_chip0> ------|
... |--- irq_domain (hwirq [0..143])
|- <gpio0_chipN> ------|
Current driver creates one chip for every 32 GPIOs in a controller.
This was a limitation earlier now there is no need for that. Hence
redesigning the driver to create one gpio chip for all the ngpio
in the controller.
|- <gpio0_chip0> ------|--- irq_domain (hwirq [0..143]).
The previous discussion on this can be found here:
https://www.spinics.net/lists/linux-omap/msg132869.html
Signed-off-by: Keerthy <j-keerthy@ti.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
gpio2regs is written making an assumption that driver supports only
one instance of gpio controller. Removing this and adding a generic
array so as to support multiple instances of gpio controllers.
Signed-off-by: Keerthy <j-keerthy@ti.com>
Reviewed-by: Grygorii Strashko <grygorii.strashko@ti.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
The only usage of function intel_gpio_runtime_idle() is here (in the
same file):
static const struct dev_pm_ops intel_gpio_pm_ops = {
SET_RUNTIME_PM_OPS(NULL, NULL, intel_gpio_runtime_idle)
};
And when CONFIG_PM is not set, the macro SET_RUNTIME_PM_OPS expands to
nothing, causing the following compiler warning:
drivers/gpio/gpio-intel-mid.c:324:12: warning: ‘intel_gpio_runtime_idle’
defined but not used [-Wunused-function]
static int intel_gpio_runtime_idle(struct device *dev)
Fix it by annotating the function with __maybe_unused.
Signed-off-by: Augusto Mecking Caringi <augustocaringi@gmail.com>
Acked-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Currently all users of fwnode_get_named_gpiod() have no way to
specify a label for the GPIO. So GPIOs listed in debugfs are shown
with label "?". With this change a proper label is used.
Also adjust all users so they can pass a label, properly retrieved
from device tree properties.
Signed-off-by: Alexander Stein <alexander.stein@systec-electronic.com>
Cc: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Acked-by: Jacek Anaszewski <jacek.anaszewski@gmail.com>
Acked-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
Acked-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Make fwnode_get_named_gpiod() consistent with the rest of
gpiod_get() like API, i.e. configure GPIO pin immediately after
request.
Besides obvious clean up it will help to configure pins based
on firmware provided resources.
Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
The helper function for adding a GPIO chip compiles in a lockdep
key for debugging, the same key is needed for nested chips as
well.
The macro construction is unreadable, replace this with two
static inlines instead.
The _gpiochip_irqchip_add prefixed function is not helpful,
rename it with gpiochip_irqchip_add_key() that tell us what the
function is actually doing.
Fixes: d245b3f9bd ("gpio: simplify adding threaded interrupts")
Cc: Roger Quadros <rogerq@ti.com>
Reported-by: Clemens Gruber <clemens.gruber@pqgruber.com>
Reported-by: Roger Quadros <rogerq@ti.com>
Reported-by: Grygorii Strashko <grygorii.strashko@ti.com>
Tested-by: Clemens Gruber <clemens.gruber@pqgruber.com>
Tested-by: Grygorii Strashko <grygorii.strashko@ti.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Casting a pointer to an int is not portable, and provokes a compiler
warning. Cast to unsigned long instead to avoid the warning.
drivers/gpio/gpio-mvebu.c: In function 'mvebu_gpio_probe':
drivers/gpio/gpio-mvebu.c:662:17: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]
soc_variant = (int) match->data;
^
This will be needed when building gpio-mvebu for Armada 7k/8k ARM64
SoCs.
Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Add optional reset-gpios pin control. If present, de-assert the
specified reset gpio pin to bring the chip out of reset.
v2:
- Specify that reset signal to PCA953x chip is active low, in
binding doc.
- reorder includes in gpio-pca953x.c.
- remove dev_err() on devm_gpiod_get_optional() error return.
Cc: Alexandre Courbot <gnurou@gmail.com>
Cc: linux-gpio@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Steve Longerbeam <steve_longerbeam@mentor.com>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Reviewed-by: Vladimir Zapolskiy <vladimir_zapolskiy@mentor.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
container_of() does pointer math on the pointer that's passed in.
If it were to return a NULL pointer the value passed in would
need to be perfectly offset from 0 to make that so. Remove these
checks because they don't make sense.
Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
It seems the code had been changed, but description left untouched.
Update description of the struct acpi_gpio_info and relative comments
accordingly.
Fixes: commit 52044723cd ("ACPI / gpio: Add irq_type when a GPIO is used as an interrupt")
Cc: Christophe RICARD <christophe.ricard@gmail.com>
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 macro for_each_set_bit() effectively looks up to the next
set bit in array of bits.
Instead of open coding that switch to for_each_set_bit() in
gpio_chip_set_multiple().
While here, make gpio_chip_set_multiple() non-destructive
against its parameters. We are safe since all callers, i.e.
gpiod_set_array_value_complex(), handle that already.
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>
davinci_gpio_controller struct has set_data, in_data, clr_data
members that are assigned and never used.
Signed-off-by: Keerthy <j-keerthy@ti.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
We have already a global array of possible GPIO suffixes. Use it here instead
of another copy of them.
Unfortunately this will not reduce the memory footprint, though allows to easy
maintain list in only one place.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
When listing multiple GPIOs in the "gpios" property of a GPIO hog, only
the first GPIO is affected. The user is left clueless about the
dysfunctioning of the other GPIOs specified.
Fix this by adding and documenting support for specifying multiple
GPIOs in a single GPIO hog.
Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
Acked-by: Rob Herring <robh@kernel.org>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
This patch updates my email address as I no longer have access to the old
one.
Signed-off-by: John Crispin <john@phrozen.org>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
When removing a gpiochip that uses GPIO hogging (e.g. by unloading the
chip's DT overlay), a warning is printed:
gpio gpiochip8: REMOVING GPIOCHIP WITH GPIOS STILL REQUESTED
This happens because gpiochip_free_hogs() is called after the gdev->chip
pointer is reset to NULL. Hence __gpiod_free() cannot determine the
chip in use, and cannot clear flags nor call the optional chip-specific
.free() callback.
Move the call to gpiochip_free_hogs() up to fix this.
Cc: stable@vger.kernel.org
Fixes: ff2b135922 ("gpio: make the gpiochip a real device")
Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Building with an old toolchain, I ran into this warning:
WARNING: vmlinux.o(.text+0x63eef0): Section mismatch in reference
from the function mxs_gpio_probe() to the function
.init.text:mxs_gpio_init_gc()
Clearly the annotation is wrong, since the function is called from the
non-init probe, so let's remove it.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Currently the chip name buffer is allocated on the stack and the
address of the buffer is passed to the gpio framework. It's invalid
after probe() returns, so the sysfs label attribute displays garbage.
Use devm_kasprintf() for each string instead.
Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
This variable is not used outside this module. Make it static.
Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Currently gpio modules are runtime-resumed at probe time. This means the
gpio module will be active all the time (except during system suspend,
if not configured as a wake-up source).
While an R-Car Gen2 gpio module retains pins configured for output at
the requested level while put in standby mode, gpio register cannot be
accessed while suspended. Unfortunately pm_runtime_get_sync() cannot be
called from all contexts where gpio register access is needed. Hence
move the Runtime PM handling from probe/remove time to gpio request/free
time, which is probably the best we can do.
On r8a7791/koelsch, gpio modules 0, 1, 3, and 4 are now suspended during
normal use (gpio2 is used for LEDs and regulators, gpio5 for keys, gpio6
for SD-Card CD & WP, gpio7 for keys and regulators).
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
[Niklas: s/gpio_to_priv(chip)/gpiochip_get_data(chip)/]
Signed-off-by: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
This enables Runtime PM handling for interrupts.
By setting the parent_device in struct irq_chip genirq will call the
pm_runtime_get/put APIs when an IRQ is requested/freed.
Signed-off-by: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Core changes:
- Simplify threaded interrupt handling: instead of passing
numbed parameters to gpiochip_irqchip_add_chained() we
create a new call: gpiochip_irqchip_add_nested() so the two
types are clearly semantically different. Also make sure
that all nested chips call gpiochip_set_nested_irqchip()
which is necessary for IRQ resend to work properly if
it happens.
- Return error on seek operations for the chardev.
- Clamp values set as part of gpio[d]_direction_output() so
that anything != 0 will be send down to the driver as "1"
not the value passed in.
- ACPI can now support naming of GPIO lines, hogs and holes
in the GPIO lists.
New drivers:
- The SX150x driver was deemed unfit for the GPIO subsystem
and was moved over to a combined GPIO+pinctrl driver in the
pinctrl subsystem.
New features:
- Various cleanups to various drivers.
-----BEGIN PGP SIGNATURE-----
iQIcBAABAgAGBQJYTnG4AAoJEEEQszewGV1zbbsQAIxxsAobyQDnBaWyAJtVP33R
mzoR5iBuWrN02rvWmYw8k3euj+2pH2Mxnl0FeezRQ5KomNLKeOghWM4VuMLPE+Mf
hz/twZvMH3biTxWDzP5C6xsmqiCZbvqnHo0dClgGOphxwcxtRJd7nCVGssqBSVJ+
FNoTvWhyEbF49fF1tPpKXSsjdYNNO8k119hu7QxwGQBde6zy2QbZd9fAZdjLGk1N
nzn7Jah895nX95rUx37wwp2H8O6G3+ns1/uLzfnJRJ37+wWCxrr9Xx1peOErxpG9
dwYYI3aNwR1/xYdMjAhJGDNqK7Jjt2w4c8vku/H5JDRoARCSfdFiTTvVBvEvU/Mq
IQCMW8D0/cCp6wFGrjyX7lzrfZMh5byWeVID6GKi1wDUop+ed/MX7Et1fFKRuDPC
s0FXE3onW9BJlT0zUANrt9fQRK+54g8VsUlHmZX1cu0VNCkCb51lqnc6WE5AMeqH
1t2bB5U96pcebNKe0yJsOj2JdvBL/EEZVuJua5fEMIdwmEidZqthBV+rMqAfJhza
t4G86q8qcyo98EgPVwVYILOOiOhXjk90SERh7MN/tiHmGVzJvoBmlQ+TYAxCTjFh
X7s4DLGZWyT5duDBodZvkIqoz/yYNF6mPfyCok18yQkz/a0Zptr1dIxN1Vu3A8yl
CEUfW/uTUtpTmmJd7jqI
=2UpT
-----END PGP SIGNATURE-----
Merge tag 'gpio-v4.10-1' of git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-gpio
Pull GPIO updates from Luinus Walleij:
"Bulk GPIO changes for the v4.10 kernel cycle:
Core changes:
- Simplify threaded interrupt handling: instead of passing numbed
parameters to gpiochip_irqchip_add_chained() we create a new call:
gpiochip_irqchip_add_nested() so the two types are clearly
semantically different. Also make sure that all nested chips call
gpiochip_set_nested_irqchip() which is necessary for IRQ resend to
work properly if it happens.
- Return error on seek operations for the chardev.
- Clamp values set as part of gpio[d]_direction_output() so that
anything != 0 will be send down to the driver as "1" not the value
passed in.
- ACPI can now support naming of GPIO lines, hogs and holes in the
GPIO lists.
New drivers:
- The SX150x driver was deemed unfit for the GPIO subsystem and was
moved over to a combined GPIO+pinctrl driver in the pinctrl
subsystem.
New features:
- Various cleanups to various drivers"
* tag 'gpio-v4.10-1' of git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-gpio: (49 commits)
gpio: merrifield: Implement gpio_get_direction callback
gpio: merrifield: Add support for hardware debouncer
gpio: chardev: Return error for seek operations
gpio: arizona: Tidy up probe error path
gpio: arizona: Remove pointless set of platform drvdata
gpio: pl061: delete platform data handling
gpio: pl061: move platform data into driver
gpio: pl061: rename variable from chip to pl061
gpio: pl061: rename state container struct
gpio: pl061: use local state for parent IRQ storage
gpio: set explicit nesting on drivers
gpio: simplify adding threaded interrupts
gpio: vf610: use builtin_platform_driver
gpio: axp209: use correct register for GPIO input status
gpio: stmpe: fix interrupt handling bug
gpio: em: depnd on ARCH_SHMOBILE
gpio: zx: depend on ARCH_ZX
gpio: x86: update config dependencies for x86 specific hardware
gpio: mb86s7x: use builtin_platform_driver
gpio: etraxfs: use builtin_platform_driver
...
By default all pins are configured to use a glitch filter. Writing 1 to the
certain bit of the specific register might be useful in case someone needs to
bypass the glitch filter completely for a given GPIO pin.
This patch adds support for that in the Intel Merrifield GPIO driver.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
The GPIO chardev is used for management tasks (allocating line and event
handles) and does neither support read() nor write() operations. Hence it
does not make much sense to allow seek operations.
Currently the chardev uses noop_llseek() for its seek implementation. This
function does not move the pointer and simply returns the current position
(always 0 for the GPIO chardev). noop_llseek() is primarily meant for
devices that can not support seek, but where there might be a user that
depends on the seek() operation succeeding. For newly added devices that
can not support seek operations it is recommended to use no_llseek(), which
will return an error. For more information see commit 6038f373a3
("llseek: automatically add .llseek fop").
Unfortunately this was overlooked when the GPIO chardev ABI was introduced.
But it is highly unlikely that since then userspace applications have
appeared that rely on being able to perform non-failing seek operations on
a GPIO chardev file descriptor. So it should be safe to change from
noop_llseel() to no_seek(). Also use nonseekable_open() in the chardev
open() callback to clear the FMODE_SEEK, FMODE_PREAD and FMODE_PWRITE flags
from the file. Neither of these should be set on a file that does not
support seek operations.
Cc: stable@vger.kernel.org
Fixes: 3c702e9987 ("gpio: add a userspace chardev ABI for GPIOs")
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
There is some unnecessary complexity in the error path which now things
are converted to devm is actually very simple. This patch simplifies
things.
Signed-off-by: Charles Keepax <ckeepax@opensource.wolfsonmicro.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
We use the gpio chip private data in all the callbacks so remove this
redundant line of code.
Signed-off-by: Charles Keepax <ckeepax@opensource.wolfsonmicro.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Platform data is a remnant of board files and all boards using
the PL061 have been migrated to use device tree or ACPI instead.
The custom mechanism to set line by default as inputs/outputs has
been superceded by the GPIO-internal hogging mechanism.
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
No boardfile defines any PL061 platform data anymore: the
Integrator IM/PD-1 includes the file but is not making use
of the struct. Let's delete the include and all references,
then move the platform data into the driver for later
consolidation into the driver state container.
The only resource defined by the IM/PD-1 is the IRQ which
is passed through the AMBA PrimeCell bus abstraction
struct amba_device.
Cc: arm@vger.kernel.org
Cc: linux-arm-kernel@lists.infradead.org
Cc: Russell King <linux@armlinux.org.uk>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Rename the local variable "chip" referring to the struct pl061
state container to "pl061": we already have gpio_chip and irq_chip
in the driver, we are needlessly adding yet another "chip" to
the confusion.
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
The PL061 state container is named "pl061_gpio", let's rename it
to simply pl061. Less is more.
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
The driver is poking around in the struct gpio_chip internals,
which is a no-no. Use a variable in the local state container.
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
The ADNP, CrystalCove and WhiskeyCove are all nested GPIO
irqchips, but were avoiding to connect the parent IRQ to
the gpiochip. This works, but is kind of sloppy as the
child IRQs are not marked as having the parent IRQ as
parent.
Cc: Mika Westerberg <mika.westerberg@linux.intel.com>
Cc: Ajay Thomas <ajay.thomas.david.rajamanickam@intel.com>
Cc: Bin Gao <bin.gao@linux.intel.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
This tries to simplify the use of CONFIG_GPIOLIB_IRQCHIP when
using threaded interrupts: add a new call
gpiochip_irqchip_add_nested() to indicate that we're dealing
with a nested rather than a chained irqchip, then create a
separate gpiochip_set_nested_irqchip() to mirror
the gpiochip_set_chained_irqchip() call to connect the
parent and child interrupts.
In the nested case gpiochip_set_nested_irqchip() does nothing
more than call irq_set_parent() on each valid child interrupt,
which has little semantic effect in the kernel, but this is
probably still formally correct.
Update all drivers using nested interrupts to use
gpiochip_irqchip_add_nested() so we can now see clearly
which these users are.
The DLN2 driver can drop its specific hack with
.irq_not_threaded as we now recognize whether a chip is
threaded or not from its use of gpiochip_irqchip_add_nested()
signature rather than from inspecting .can_sleep.
We rename the .irq_parent to .irq_chained_parent since this
parent IRQ is only really kept around for the chained
interrupt handlers.
Cc: Lars Poeschel <poeschel@lemonage.de>
Cc: Octavian Purdila <octavian.purdila@intel.com>
Cc: Daniel Baluta <daniel.baluta@intel.com>
Cc: Bin Gao <bin.gao@linux.intel.com>
Cc: Mika Westerberg <mika.westerberg@linux.intel.com>
Cc: Ajay Thomas <ajay.thomas.david.rajamanickam@intel.com>
Cc: Semen Protsenko <semen.protsenko@globallogic.com>
Cc: Alexander Stein <alexander.stein@systec-electronic.com>
Cc: Phil Reid <preid@electromag.com.au>
Cc: Bartosz Golaszewski <bgolaszewski@baylibre.com>
Cc: Patrice Chotard <patrice.chotard@st.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Use builtin_platform_driver() helper to simplify the code.
Signed-off-by: Geliang Tang <geliangtang@gmail.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
The GPIO input status was read from control register
(AXP20X_GPIO[210]_CTRL) instead of status register (AXP20X_GPIO20_SS).
Signed-off-by: Quentin Schulz <quentin.schulz@free-electrons.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
commit 43db289d00 ("gpio: stmpe: Rework registers access")
reworked the STMPE register access so as to use
[STMPE_IDX_*_LSB + i] to access the 8bit register for a
certain bank, assuming the CSB and MSB will follow after
the enumerator. For this to work the index needs to go from
(size-1) to 0 not 0 to (size-1).
However for the GPIO IRQ handler, the status registers we read
register MSB + 3 bytes ahead for the 24 bit GPIOs and index
registers from MSB upwards and run an index i over the
registers UNLESS we are STMPE1600.
This is not working when we get to clearing the interrupt
EDGE status register STMPE_IDX_GPEDR_[LCM]SB: it is indexed
like all other registers [STMPE_IDX_*_LSB + i] but in this
loop we index from 0 to get the right bank index for the
calculations, and we need to just add i to the MSB.
Before this, interrupts on the STMPE2401 were broken, this
patch fixes it so it works again.
Cc: stable@vger.kernel.org
Cc: Patrice Chotard <patrice.chotard@st.com>
Fixes: 43db289d00 ("gpio: stmpe: Rework registers access")
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
The GPIO_EM is part of the Renesas SoCs so depend on the arch.
Signed-off-by: Peter Robinson <pbrobinson@gmail.com>
[Changed to depend on ARCH_EMEV2]
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Set GPIO_ZX to depend on ARCH_ZX as it's SOC specific.
Signed-off-by: Peter Robinson <pbrobinson@gmail.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
The devices here are specific to x86 so lets depend on x86.
Signed-off-by: Peter Robinson <pbrobinson@gmail.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Use builtin_platform_driver() helper to simplify the code.
Signed-off-by: Geliang Tang <geliangtang@gmail.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Use builtin_platform_driver() helper to simplify the code.
Signed-off-by: Geliang Tang <geliangtang@gmail.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Adding max20024 compatible string to the device id list
to support both max77620 and max20024 devices.
Signed-off-by: Venkat Reddy Talla <vreddytalla@nvidia.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
This option was added in 6a89a314ab to
allow use of the devm_gpio_* functions without CONFIG_GPIOLIB.
However, only a few months later in
b69ac52449, CONFIG_GPIOLIB was added
as a dependency, defeating the original purpose of this option.
Instead of that patch, the original commit could have just been
reverted (and in fact was partially so in
403c1d0be5). Further, since this
option has a dependency on HAS_IOMEM, even though it does not
require it, it causes build failures when !HAS_IOMEM (e.g. in a
uml build).
Fix that by completely removing the option, in essence completing
the reversion of the original commit.
Signed-off-by: Keno Fischer <keno@juliacomputing.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Use builtin_pci_driver() helper to simplify the code.
Signed-off-by: Geliang Tang <geliangtang@gmail.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
The bit in the TC3589x direction register is 0 for input
and 1 for output, but the gpiolib expects the reverse.
Fix up the logic.
Cc: stable@vger.kernel.org
Fixes: 14063d71e5 ("gpio: tc3589x: add .get_direction() and small cleanup")
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
When a GPIO line is marked as used for an interrupt, it is
helpful to set the label to "interrupt" so we know what is
going on when inspecting the lines.
If a GPIO is already properly named by gpiod_get*() we don't
need to do this. It only happens when a line is used from
the irqchip side of a GPIO driver without communicating
with the GPIO side, such as when gpiochip is used as interrupt
provider in the device tree.
If the line is still marked as used by "interrupt" when we
unmark it as used by an interrupt, also remove this label
from the descriptor.
Also shape up the code around unmarking IRQ lines.
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
I saw weird values != [0,1] being passed down to drivers
in their .set_direction_output() callbacks. Go over the
gpiolib and make sure to hammer it to [0,1] before hitting
the driver to avoid undesired side effects.
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
When locking a GPIO line as IRQ, we go to lengths to
double-check that the line is really set as input before
marking it as used for IRQ. This is not good on GPIO chips
that can sleep, because this function is called in IRQ-safe
context. Just skip this if it can't be checked quickly.
Currently this happens on sleeping expanders such as STMPE
or TC3589x:
BUG: scheduling while atomic: swapper/1/0x00000002
Modules linked in:
CPU: 0 PID: 1 Comm: swapper Not tainted 4.9.0-rc1+ #38
Hardware name: Nomadik STn8815
[<c000f2e0>] (unwind_backtrace) from [<c000d244>] (show_stack+0x10/0x14)
[<c000d244>] (show_stack) from [<c0037b78>] (__schedule_bug+0x54/0x80)
[<c0037b78>] (__schedule_bug) from [<c042df14>] (__schedule+0x3a0/0x460)
[<c042df14>] (__schedule) from [<c042e028>] (schedule+0x54/0xb8)
(...)
This patch fixes that problem and relies on the direction
read from the chip when it was added.
Cc: stable@vger.kernel.org
Fixes: 9c10280d85 ("gpio: flush direction status in gpiochip_lock_as_irq()")
Cc: Patrice Chotard <patrice.chotard@st.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
When the hardware is in output mode, reading the value from the
hardware is not giving the correct value back. Instead read the
value from the cache so we get the right value.
Suggested-by: Russell King <linux@arm.linux.org.uk>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
This makes is possible to read out the current direction of a
GPIO line on the HTC CPLD GPIO expander.
Suggested-by: Russell King <linux@arm.linux.org.uk>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
The newly added acpi_gpiochip_scan_gpios function produces a few harmless
warnings:
drivers/gpio/gpiolib-acpi.c: In function ‘acpi_gpiochip_add’:
drivers/gpio/gpiolib-acpi.c:925:7: error: ‘dflags’ may be used uninitialized in this function [-Werror=maybe-uninitialized]
drivers/gpio/gpiolib-acpi.c:925:9: error: ‘lflags’ may be used uninitialized in this function [-Werror=maybe-uninitialized]
The problem is that he compiler cannot know that a negative return value
from fwnode_property_read_u32_array() or acpi_gpiochip_pin_to_gpio_offset()
implies that the IS_ERR(gpio_desc) is true, as the value could in theory
be below -MAX_ERRNO.
The function already initializes its output values to zero, and moving
that intialization a little higher up ensures that we can never have
uninitialized data in the caller.
Fixes: c80f1ba75d ("ACPI / gpio: Add hogging support")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Acked-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
The gpiod framework uses the chip label to match a specific chip.
The davinci gpio driver, creates several chips using always the same
label, which is not compatible with gpiod.
To allow platform data to declare gpio lookup tables, and for drivers
to use the gpiod framework, allocate unique label per registered chip.
Signed-off-by: Axel Haslam <ahaslam@baylibre.com>
Reviewed-by: Sekhar Nori <nsekhar@ti.com>
Acked-by: Kevin Hilman <khilman@baylibre.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Need to ensure that reg_output is not updated while setting multiple
bits. This makes the mutex locking behaviour for the set_multiple call
consistent with that of the set_value call.
Cc: stable@vger.kernel.org
Fixes: b4818afeac ("gpio: pca953x: Add set_multiple to allow multiple")
Signed-off-by: Phil Reid <preid@electromag.com.au>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
gpiod_set_array_value_complex does not clear the bits field.
Therefore when the drivers set_multiple funciton is called bits outside
the mask are undefined and can be either set or not. So bank_val needs
to be masked with bank_mask before or with the reg_val cache.
Cc: stable@vger.kernel.org
Fixes: b4818afeac ("gpio: pca953x: Add set_multiple to allow multiple")
Signed-off-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 HTC_EGPIO
drivers/gpio/Kconfig: bool "HTC EGPIO support"
...meaning that it currently is not being built as a module by anyone.
Lets remove the modular code that is essentially orphaned, so that
when reading the driver there is no doubt it is builtin-only.
We explicitly disallow a driver unbind, since that doesn't have a
sensible use case anyway, and it allows us to drop the ".remove"
code for non-modular drivers.
Since module_init was not in use by this code, the init ordering
remains unchanged with this commit.
We also delete the MODULE_LICENSE tag etc. since all that information
is already contained at the top of the file in the comments.
Cc: Linus Walleij <linus.walleij@linaro.org>
Cc: Alexandre Courbot <gnurou@gmail.com>
Cc: Kevin O'Connor <kevin@koconnor.net>
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 fixes the irq allocation in this driver to not print:
irq: Cannot allocate irq_descs @ IRQ34, assuming pre-allocated
irq: Cannot allocate irq_descs @ IRQ66, assuming pre-allocated
Which happens because the driver already called irq_alloc_descs()
and so the change to use irq_domain_add_simple resulted in calling
irq_alloc_descs() twice.
Modernize the irq allocation in this driver to use the
irq_domain_add_linear flow directly and eliminate the use of
irq_domain_add_simple/legacy
Fixes: ce931f571b ("gpio/mvebu: convert to use irq_domain_add_simple()")
Signed-off-by: Jason Gunthorpe <jgunthorpe@obsidianresearch.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Sylvain Lemieux reports the LPC32xx GPIO driver is broken since
commit 762c2e46c0 ("gpio: of: remove of_gpiochip_and_xlate() and
struct gg_data"). Probably, gpio-etraxfs.c and gpio-davinci.c are
broken too.
Those drivers register multiple gpio_chip that are associated to a
single OF node, and their own .of_xlate() checks if the passed
gpio_chip is valid.
Now, the problem is of_find_gpiochip_by_node() returns the first
gpio_chip found to match the given node. So, .of_xlate() fails,
except for the first GPIO bank.
Reverting the commit could be a solution, but I do not want to go
back to the mess of struct gg_data. Another solution here is to
take the match by a node pointer and the success of .of_xlate().
It is a bit clumsy to call .of_xlate twice; for gpio_chip matching
and for really getting the gpio_desc index. Perhaps, our long-term
goal might be to convert the drivers to single chip registration,
but this commit will solve the problem until then.
Fixes: 762c2e46c0 ("gpio: of: remove of_gpiochip_and_xlate() and struct gg_data")
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Reported-by: Sylvain Lemieux <slemieux.tyco@gmail.com>
Tested-by: David Lechner <david@lechnology.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
When allocating a new line handle or event a file is allocated that it is
associated to. The file is attached to a file descriptor of the current
process and the file descriptor is returned to userspace using
copy_to_user(). If this copy operation fails the line handle or event
allocation is aborted, all acquired resources are freed and an error is
returned.
But the file struct is not freed and left attached to the userspace
application and even though the file descriptor number was not copied it is
trivial to guess. If a userspace application performs a IOCTL on such a
left over file descriptor it will trigger a use-after-free and if the file
descriptor is closed (latest when the application exits) a double-free is
triggered.
anon_inode_getfd() performs 3 tasks, allocate a file struct, allocate a
file descriptor for the current process and install the file struct in the
file descriptor. As soon as the file struct is installed in the file
descriptor it is accessible by userspace (even if the IOCTL itself hasn't
completed yet), this means uninstalling the fd on the error path is not an
option, since userspace might already got a reference to the file.
Instead anon_inode_getfd() needs to be broken into its individual steps.
The allocation of the file struct and file descriptor is done first, then
the copy_to_user() is executed and only if it succeeds the file is
installed.
Since the file struct is reference counted it can not be just freed, but
its reference needs to be dropped, which will also call the release()
callback, which will free the state attached to the file. So in this case
the normal error cleanup path should not be taken.
Cc: stable@vger.kernel.org
Fixes: d932cd4918 ("gpio: free handles in fringe cases")
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
When terminating for_each_available_child_of_node() iteration
with break or return, of_node_put() should be used to prevent
stale device node references from being left behind.
This is detected by Coccinelle semantic patch.
Signed-off-by: Wei Yongjun <weiyongjun1@huawei.com>
Reviewed-by: Vladimir Zapolskiy <vladimir_zapolskiy@mentor.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Fixes the following sparse warning:
drivers/gpio/gpiolib-acpi.c:863:18: warning:
symbol 'acpi_gpiochip_parse_own_gpio' was not declared. Should it be static?
Signed-off-by: Wei Yongjun <weiyongjun1@huawei.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
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.
This is detected by Coccinelle semantic patch.
Signed-off-by: Wei Yongjun <weiyongjun1@huawei.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Currently read directly calls the repmap read function. Hence
remove the redundant wrapper and use regmap read wherever
needed.
Signed-off-by: Keerthy <j-keerthy@ti.com>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
Confirm the chip->parent is valid before dereferencing because
the parent parameter is optional.
Signed-off-by: Thor Thayer <tthayer@opensource.altera.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
It's not necessary to unregister gpio_chip which registered
with devm_gpiochip_add_data().
Also get rid of useless altr_a10sr_gpio_remove().
Signed-off-by: Wei Yongjun <weiyongjun1@huawei.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
According to the reference manual level interrupts can't be acked
using the IRQSTAT registers. The effect is that when a level interrupt
triggers the following ack is a no-op and the same interrupt triggers
again right after it has been unmasked after running the interrupt
handler.
The reference manual says:
Status bits for pins configured as level sensitive interrupts cannot be
cleared unless either the actual pin is in the non-interrupting state, or
the pin has been disabled as an interrupt source by clearing its bit in
HW_PINCTRL_PIN2IRQ.
To work around the duplicated interrupts we can use the PIN2IRQ
rather than the IRQEN registers to mask the interrupts. This
probably does not work for the edge interrupts, so we have to split up
the irq chip into two chip types, one for the level interrupts and
one for the edge interrupts. We now make use of two different enable
registers, so we have to take care to always enable the right one,
especially during switching of the interrupt type. An easy way
to accomplish this is to use the IRQCHIP_SET_TYPE_MASKED which
makes sure that set_irq_type is called with masked interrupts. With this
the flow to change the irq type is like:
- core masks interrupt (using the current chip type)
- mxs_gpio_set_irq_type() changes chip type if necessary
- mxs_gpio_set_irq_type() unconditionally sets the enable bit in the
now unused enable register
- core eventually unmasks the interrupt (using the new chip type)
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
Reviewed-by: Marek Vasut <marex@denx.de>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
The mxs gpio controller does not only have a mask register to mask
interrupts, but also enable/disable registers. Use the enable/disable
registers rather than the mask register. This does not have any
advantage for now, but makes the next patch simpler.
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
Reviewed-by: Marek Vasut <marex@denx.de>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Now that we have the new helper function that sets nice names for GPIO
lines based on "gpio-line-names" device property, we can take advantage of
this in acpi_gpiochip_add().
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
In order to use "gpio-line-names" property in systems not having DT as
their boot firmware, rework of_gpiochip_set_names() to use device property
accessors. This reworked function is placed in a separate file making it
clear it deals with universal device properties.
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
GPIO hogging means that the GPIO controller can "hog" and configure certain
GPIOs without need for a driver or userspace to do that. This is useful in
open-connected boards where BIOS cannot possibly know beforehand which
devices will be connected to the board.
This adds GPIO hogging mechanism to ACPI analogous to Device Tree.
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Make it possible to have an empty GPIOs in a GPIO list for device. For
example a SPI master may use both GPIOs and native pins as chip selects and
we need to be able to distinguish between the two.
This makes it mandatory to have exactly 3 arguments for GPIOs and then
converts gpiolib to use of __acpi_node_get_property_reference() instead. In
addition we make acpi_gpio_package_count() to handle holes as well (this
matches the DT version).
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Add compatible string for the MAX7318 part. This is a two bank,
16 lines, I2C GPIO expander with interrupt line.
Signed-off-by: Marek Vasut <marex@denx.de>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
All the boards supported by the gpio-ts4900 driver are i.MX6 boards,
so only offer the driver for building on this platform, unless
build-testing.
Signed-off-by: Jean Delvare <jdelvare@suse.de>
Cc: Lucile Quirion <lucile.quirion@savoirfairelinux.com>
Cc: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Add the GPIO functionality for the Altera Arria10 MAX5 System Resource
Chip. The A10 MAX5 has 12 bits of GPIO assigned to switches, buttons,
and LEDs as a GPIO extender on the SPI bus.
Signed-off-by: Thor Thayer <tthayer@opensource.altera.com>
Acked-by: Linus Walleij <linus.walleij@linaro.org>i
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
We switch the default handler to be handle_bad_irq() instead of
handle_simple_irq() (which was not correct anyway).
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Current code does not use gpio_irq/irq_base/gpio_base fields from
struct max77620_gpio, so remove them.
Signed-off-by: Axel Lin <axel.lin@ingics.com>
Acked-by: Laxman Dewangan <ldewangan@nvidia.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Since the I2C sx150x GPIO expander driver uses platform_data to manage
the pins configurations, rewrite the driver as a pinctrl driver using
pinconf to get/set pin configurations from DT or debugfs.
The pinctrl driver is functionnally equivalent as the gpio-only driver
and can use DT for pinconf. The platform_data confirmation is dropped.
This patchset removed the gpio-only driver and selects the Pinctrl driver
config instead. This patchset also migrates the gpio dt-bindings to pinctrl
and add the pinctrl optional properties.
The driver was tested with a SX1509 device on a BeagleBone black with
interrupt support and on an X86_64 machine over an I2C to USB converter.
This is a fixed version that builds and runs on non-OF platforms and on
arm based OF. The GPIO version is removed and the bindings are also moved
to the pinctrl bindings.
Changes since v2
- rebased on v4.9-rc1
- removed MODULE_DEVICE_TABLE as in upstream bb411e771b
("gpio: sx150x: fix implicit assumption module.h is present")
Changes since v1
- Fix Kconfig descriptions on pinctrl and gpio
- Fix Kconfig dependency
- Remove oscio support for non-789 devices
- correct typo in dt bindings
- remove probe reset for non-789 devices
Changes since RFC
- Put #ifdef CONFIG_OF/CONFIG_OF_GPIO to remove OF code for non-of platforms
- No more rely on OF_GPIO config
- Moved and enhanced bindings to pinctrl bindings
- Removed gpio-sx150x.c
- Temporary select PINCTRL_SX150X when GPIO_SX150X
- Temporary mark GPIO_SX150X as deprecated
Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
Tested-by: Peter Rosin <peda@axentia.se>
Acked-by: Rob Herring <robh@kernel.org>
ested-by: Andrey Smirnov <andrew.smirnov@gmail.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
From the beginning of the gpio-mpc8xxx.c, the "handle_level_irq"
has being used to handle GPIO interrupts in the PowerPC/Layerscape
platforms. But actually, almost all PowerPC/Layerscape platforms
assert an interrupt request upon either a high-to-low change or
any change on the state of the signal.
So the "handle_level_irq" is not reasonable for PowerPC/Layerscape
GPIO interrupt, it should be "handle_edge_irq". Otherwise the system
may lost some interrupts from the PIN's state changes.
Signed-off-by: Liu Gang <Gang.Liu@nxp.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
If the driver is built as a module, autoload won't work because the module
alias information is not filled. So user-space can't match the registered
device with the corresponding module.
Export the module alias information using the MODULE_DEVICE_TABLE() macro.
Before this patch:
$ modinfo drivers/gpio/gpio-ath79.ko | grep alias
$
After this patch:
$ modinfo drivers/gpio/gpio-ath79.ko | grep alias
alias: of:N*T*Cqca,ar9340-gpioC*
alias: of:N*T*Cqca,ar9340-gpio
alias: of:N*T*Cqca,ar7100-gpioC*
alias: of:N*T*Cqca,ar7100-gpio
Signed-off-by: Javier Martinez Canillas <javier@osg.samsung.com>
Acked-by: Aban Bedel <albeu@free.fr>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
If the driver is built as a module, autoload won't work because the module
alias information is not filled. So user-space can't match the registered
device with the corresponding module.
Export the module alias information using the MODULE_DEVICE_TABLE() macro.
Before this patch:
$ modinfo drivers/gpio/gpio-ts4800.ko | grep alias
$
After this patch:
$ modinfo drivers/gpio/gpio-ts4800.ko | grep alias
alias: of:N*T*Ctechnologic,ts4800-gpioC*
alias: of:N*T*Ctechnologic,ts4800-gpio
Signed-off-by: Javier Martinez Canillas <javier@osg.samsung.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
The GPIO_GET_LINEEVENT_IOCTL currently ignores unknown or undefined
linehandle and lineevent flags. From a backwards and forwards compatibility
viewpoint it is highly desirable to reject unknown flags though.
On one hand an application that is using newer flags and is running on
an older kernel has no way to detect if the new flags were handled
correctly if they are silently discarded.
On the other hand an application that (accidentally) passes undefined flags
will run fine on an older kernel, but may break on a newer kernel when
these flags get defined.
Ensure that requests that have undefined flags set are rejected with an
error, rather than silently discarding the undefined flags.
Cc: stable@vger.kernel.org
Fixes: 61f922db72 ("gpio: userspace ABI for reading GPIO line events")
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
The GPIO_GET_LINEHANDLE_IOCTL currently ignores unknown or undefined
linehandle flags. From a backwards and forwards compatibility viewpoint it
is highly desirable to reject unknown flags though.
On one hand an application that is using newer flags and is running on
an older kernel has no way to detect if the new flags were handled
correctly if they are silently discarded.
On the other hand an application that (accidentally) passes undefined flags
will run fine on an older kernel, but may break on a newer kernel when
these flags get defined.
Ensure that requests that have undefined flags set are rejected with an
error, rather than silently discarding the undefined flags.
Cc: stable@vger.kernel.org
Fixes: d7c51b47ac ("gpio: userspace ABI for reading/writing GPIO lines")
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
The GPIOHANDLE_GET_LINE_VALUES_IOCTL handler allocates a gpiohandle_data
struct on the stack and then passes it to copy_to_user(). But depending on
the number of requested line handles the struct is only partially
initialized.
This exposes the previous, potentially sensitive, stack content to the
issuing userspace application. To avoid this make sure that the struct is
fully initialized.
Cc: stable@vger.kernel.org
Fixes: d7c51b47ac ("gpio: userspace ABI for reading/writing GPIO lines")
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
The line offset that is used as an index into the descs array is provided
by userspace and might go beyond the bounds of the array. If that happens
undefined behavior will occur.
Make sure that the offset is within the bounds of the desc array and reject
any requests that specify a value outside of it.
Cc: stable@vger.kernel.org
Fixes: 61f922db72 ("gpio: userspace ABI for reading GPIO line events")
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
The GPIOHANDLE_GET_LINE_VALUES_IOCTL handler allocates a gpiohandle_data
struct on the stack and then passes it to copy_to_user(). But only the
first element of the values array in the struct is set, which leaves the
struct partially initialized.
This exposes the previous, potentially sensitive, stack content to the
issuing userspace application. To avoid this make sure that the struct is
fully initialized.
Cc: stable@vger.kernel.org
Fixes: 61f922db72 ("gpio: userspace ABI for reading GPIO line events")
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
The line offset that is used as an index into the descs array is provided
by userspace and might go beyond the bounds of the array. If that happens
undefined behavior will occur.
Make sure that the offset is within the bounds of the desc array and reject
any requests that specify a value outside of it.
Cc: stable@vger.kernel.org
Fixes: d7c51b47ac ("gpio: userspace ABI for reading/writing GPIO lines")
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
The GPIO_GET_CHIPINFO_IOCTL handler allocates a gpiochip_info struct on the
stack and then passes it to copy_to_user(). But depending on the length of
the GPIO chip name and label the struct is only partially initialized.
This exposes the previous, potentially sensitive, stack content to the
issuing userspace application. To avoid this make sure that the struct is
fully initialized.
Cc: stable@vger.kernel.org
Fixes: 521a2ad6f8 ("gpio: add userspace ABI for GPIO line information")
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
The current line offset validation is off by one. Depending on the data
stored behind the descs array this can either cause undefined behavior or
disclose arbitrary, potentially sensitive, memory to the issuing userspace
application.
Make sure that offset is within the bounds of the desc array.
Cc: stable@vger.kernel.org
Fixes: 521a2ad6f8 ("gpio: add userspace ABI for GPIO line information")
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
acpi_dev_gpio_irq_get() currently ignores the error returned
by acpi_get_gpiod_by_index() and overwrites it with -ENOENT.
Problem is this error can be -EPROBE_DEFER, which just blows
up some drivers when the module ordering is not correct.
Cc: stable@vger.kernel.org
Signed-off-by: David Arcari <darcari@redhat.com>
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Acked-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Building the gpio-mockup driver without SYSFS results in a harmless Kconfig
warning:
warning: (GPIO_MOCKUP) selects GPIO_SYSFS which has unmet direct dependencies (GPIOLIB && SYSFS)
We can easily avoid that warning by adding a dependency on SYSFS.
Fixes: 0f98dd1b27 ("gpio/mockup: add virtual gpio device")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
&& was obviously intended here.
Fixes: 6936e1f88d ('gpio: stmpe: Write int status register only when needed')
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Acked-by: Patrice Chotard <patrice.chotard@st.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
This is a follow-up to commit 559b46990e ("gpio: pca953x: fix an
incorrect lockdep warning"). The reason for calling
lockdep_set_subclass() in pca953x_probe() is not explained in
the code.
Add a comment describing the problem, partial solution and required
future extensions.
Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
Pull i2c updates from Wolfram Sang:
"Here is the 4.9 pull request from I2C including:
- centralized error messages when registering to the core
- improved lockdep annotations to prevent false positives
- DT support for muxes, gates, and arbitrators
- bus speeds can now be obtained from ACPI
- i2c-octeon got refactored and now supports ThunderX SoCs, too
- i2c-tegra and i2c-designware got a bigger bunch of updates
- a couple of standard driver fixes and improvements"
* 'i2c/for-4.9' of git://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux: (71 commits)
i2c: axxia: disable clks in case of failure in probe
i2c: octeon: thunderx: Limit register access retries
i2c: uniphier-f: fix misdetection of incomplete STOP condition
gpio: pca953x: variable 'id' was used twice
i2c: i801: Add support for Kaby Lake PCH-H
gpio: pca953x: fix an incorrect lockdep warning
i2c: add a warning to i2c_adapter_depth()
lockdep: make MAX_LOCKDEP_SUBCLASSES unconditionally visible
i2c: export i2c_adapter_depth()
i2c: rk3x: Fix variable 'min_total_ns' unused warning
i2c: rk3x: Fix sparse warning
i2c / ACPI: Do not touch an I2C device if it belongs to another adapter
i2c: octeon: Fix high-level controller status check
i2c: octeon: Avoid sending STOP during recovery
i2c: octeon: Fix set SCL recovery function
i2c: rcar: add support for r8a7796 (R-Car M3-W)
i2c: imx: make bus recovery through pinctrl optional
i2c: meson: add gxbb compatible string
i2c: uniphier-f: set the adapter to master mode when probing
i2c: uniphier-f: avoid WARN_ON() of clk_disable() in failure path
...
Subsystem improvements:
- Do away with the last users of the obsolete Kconfig options
ARCH_REQUIRE_GPIOLIB and ARCH_WANT_OPTIONAL_GPIOLIB (the latter
always sounded like an item on a wishlist to Santa Claus to
me). We can now select GPIOLIB and be done with it, for all
archs. After some struggle it even work on UM. Not that it has
GPIO, but if it wants to, it can select the library.
- Continued efforts to make drivers properly either tristate or
bool.
- Introduce a warning for drivers assigning default triggers to
their irqchip lines when probed from device tree, so we find and
fix these ambigous drivers. It is agreed that in the OF config
path, the device tree defines trigger characteristics.
- The same warning, mutatis mutandis, for ACPI-probed GPIO
irqchips.
- We introduce the ability to mark certain IRQ lines as "unusable"
as they can be taken by BIOS/firmware, unrouted in silicon and
generally nasty if you use them, and such things. This is
put to good use in the STMPE driver and also in the Cherryview
pin control driver.
- A new "mockup" virtual GPIO device that can be used for testing.
The plan is to add unit tests under tools/* for exercising this
device and verify that the kernel code paths are working as they
should.
- Make memory-mapped I/O-drivers depend on HAS_IOMEM. This was
implicit all the time, but when people started building UM
with allyesconfig or allmodconfig it exploded in their face.
- Move some stray bits of device tree and ACPI HW description
callbacks down into their respective implementation silo. These
were causing issues when compiling on !HAS_IOMEM as well, so
now eventually UM compiles the GPIOLIB library if it wants to.
New drivers:
- New driver for the Aspeed GPIO front-end companion to the
pin controller merged through the pin control tree.
- New driver for the LP873x PMIC GPIO portions.
- New driver for Technologic Systems' I2C FPGA GPIO such as
TS4900, TS-7970, TS-7990 and TS-4100.
- New driver for the Broadcom BCM63xx series including BCM6338
and BCM6345.
- New driver for the Intel WhiskeyCove PMIC GPIO.
- New driver for the Allwinner AXP209 PMIC GPIO portions.
- New driver for Diamond Systems 48 line GPIO-MM, another of
these port-mapped I/O expansion cards.
- Support the STMicroelectronics STMPE1600 variant in the STMPE
driver.
Driver improvements:
- The STMPE driver now supports rising/falling edge detection
properly for IRQs.
- The PCA954x will now fetch and enable its VCC regulator properly.
- Major rework of the PCA953x driver with the goal of eventually
switching it over to use regmap and thus modernize it even more.
- Switch the IOP driver to use the generic MMIO GPIO library.
- Move the ages old HTC EGPIO (extended GPIO) GPIO expander driver
over to this subsystem from MFD, achieveing some separation of
concerns.
-----BEGIN PGP SIGNATURE-----
iQIcBAABAgAGBQJX9OvDAAoJEEEQszewGV1zsPQP/3VLy1fNIpMF0DDyq5tA/GNv
sinnaPgMtt+qBrM2sbJcTVwV9xtHrs12CC3+2lAhBCIEm4YfHbXvaUMNE+aKJzk4
ZM7/rb8WMUxjQqzDKStdETsQGo6fxh0qU81OEQNbX9alir20jik9DvTufcs6xCgx
sqh8KsNGO4Y6tiuKZ6mTZvIjVhMwiTm0NBSDKhdim0DdsOcuxyh6xVOj/0LB2Ei6
g75X1w++wjh0ryY3bzaeWkQSlXDC6eEKeez7VaEkSUyrxH86buomy0+aP0fqs7vY
LRZzn/TC97YLT6hslS/OhB7uXrDIY2POSwO/SvusJcveGP7WPGyGr5mDtA4ATRWI
ios0DBWl629kHfhAMzg3kPJS8LfjCerapvtbdAgqvhH+Vb5IPFx45vypDkR2WtJ7
bNAySIRMQSHZvJSCvYzjqh8AbWdE4i4k70tFXRMOpWeKIvRVI1cDvLD6cLn3hATM
IPTytM6i2xqnzcq7mK7EJ18afcR0mv1jHgGAv4M0RMkyJ2IrURvFyZIvUB2MTyuL
PEBh1ZvTs+MO50eeFwzltY91eagkzgWB0f6sm3l7I7bL2oxE2f/WVcVL9jWbgwpF
otjFO27u0/6rIulfLUQzDo3gbOq7UaN0VTW4E9CYbOtFtNzCxjFIKTv0IJhTu4TT
OSur7oFpzAMOGYlpYP8j
=ABbi
-----END PGP SIGNATURE-----
Merge tag 'gpio-v4.9-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.9 series:
Subsystem improvements:
- do away with the last users of the obsolete Kconfig options
ARCH_REQUIRE_GPIOLIB and ARCH_WANT_OPTIONAL_GPIOLIB (the latter
always sounded like an item on a wishlist to Santa Claus to me). We
can now select GPIOLIB and be done with it, for all archs. After
some struggle it even work on UM. Not that it has GPIO, but if it
wants to, it can select the library.
- continued efforts to make drivers properly either tristate or bool.
- introduce a warning for drivers assigning default triggers to their
irqchip lines when probed from device tree, so we find and fix
these ambigous drivers. It is agreed that in the OF config path,
the device tree defines trigger characteristics.
- the same warning, mutatis mutandis, for ACPI-probed GPIO irqchips.
- we introduce the ability to mark certain IRQ lines as "unusable" as
they can be taken by BIOS/firmware, unrouted in silicon and
generally nasty if you use them, and such things. This is put to
good use in the STMPE driver and also in the Cherryview pin control
driver.
- a new "mockup" virtual GPIO device that can be used for testing.
The plan is to add unit tests under tools/* for exercising this
device and verify that the kernel code paths are working as they
should.
- make memory-mapped I/O-drivers depend on HAS_IOMEM. This was
implicit all the time, but when people started building UM with
allyesconfig or allmodconfig it exploded in their face.
- move some stray bits of device tree and ACPI HW description
callbacks down into their respective implementation silo. These
were causing issues when compiling on !HAS_IOMEM as well, so now
eventually UM compiles the GPIOLIB library if it wants to.
New drivers:
- new driver for the Aspeed GPIO front-end companion to the pin
controller merged through the pin control tree.
- new driver for the LP873x PMIC GPIO portions.
- new driver for Technologic Systems' I2C FPGA GPIO such as TS4900,
TS-7970, TS-7990 and TS-4100.
- new driver for the Broadcom BCM63xx series including BCM6338 and
BCM6345.
- new driver for the Intel WhiskeyCove PMIC GPIO.
- new driver for the Allwinner AXP209 PMIC GPIO portions.
- new driver for Diamond Systems 48 line GPIO-MM, another of these
port-mapped I/O expansion cards.
- support the STMicroelectronics STMPE1600 variant in the STMPE
driver.
Driver improvements:
- the STMPE driver now supports rising/falling edge detection
properly for IRQs.
- the PCA954x will now fetch and enable its VCC regulator properly.
- major rework of the PCA953x driver with the goal of eventually
switching it over to use regmap and thus modernize it even more.
- switch the IOP driver to use the generic MMIO GPIO library.
- move the ages old HTC EGPIO (extended GPIO) GPIO expander driver
over to this subsystem from MFD, achieveing some separation of
concerns"
* tag 'gpio-v4.9-1' of git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-gpio: (81 commits)
gpio: add missing static inline
gpio: OF: localize some gpiochip init functions
gpio: acpi: separation of concerns
gpio: OF: separation of concerns
gpio: make memory-mapped drivers depend on HAS_IOMEM
gpio: stmpe: use BIT() macro
gpio: stmpe: forbid unused lines to be mapped as IRQs
mfd/gpio: Move HTC GPIO driver to GPIO subsystem
gpio: MAINTAINERS: Add an entry for GPIO mockup driver
gpio/mockup: add virtual gpio device
gpio: Added zynq specific check for special pins on bank zero
gpio: axp209: Implement get_direction
gpio: aspeed: remove redundant return value check
gpio: loongson1: remove redundant return value check
ARM: omap2: fix missing include
gpio: tc3589x: fix up complaints on unsigned
gpio: tc3589x: add .get_direction() and small cleanup
gpio: f7188x: use gpiochip_get_data instead of container_of
gpio: tps65218: use devm_gpiochip_add_data() for gpio registration
gpio: aspeed: fix return value check in aspeed_gpio_probe()
...
of_get_named_gpiod_flags() was missing a static inline version
when compiling without OF_GPIO. Add this.
Reported-by: kbuild test robot <fengguang.wu@intel.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
of_gpiochip_add() and of_gpiochip_remove() are only used locally
in the gpio subsystem so move these functions to the local
header.
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
The generic GPIO library directly implement code for acpi_find_gpio()
which is only used with CONFIG_ACPI. This was probably done because
OF did the same thing, but I removed that so remove this too.
Rename the internal acpi_find_gpio() in gpiolib-acpi.c to
acpi_populate_gpio_lookup() which seems to be more appropriate anyway
so as to avoid a namespace clash with the same function.
Make the stub return -ENOENT rather than -ENOSYS (as that is for
syscalls!).
For some reason the sunxi pin control driver was including the private
gpiolib header, it works just fine without it so remove that oneliner.
Cc: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Acked-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
The generic GPIO library directly implement code for of_find_gpio()
which is only used with CONFIG_OF and causes compilation problems
on archs that do not even have stubs for OF functions, especially
on UM that does not implement any IO remap functions.
Move the function to gpiolib-of.c, implement a static inline stub
in gpiolib.h returning PTR_ERR(-ENOENT) if CONFIG_OF_GPIO is not
set and be done with it.
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
This one is pretty obvious: on UM Linux compilation of things
like allmodconfig and allyesconfig will fail due to the
absence of IO memory. Simply make these drivers depend on
HAS_IOMEM, it has been implicitly assumed all the time, so
just make it explicit.
The generic MMIO library also assumes that IOMEM is present
so make also this depend on HAS_IOMEM.
Reported-by: kbuild test robot <fengguang.wu@intel.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Exploit the new mechanism for masking off disallowed IRQs
added by Mika Westerberg to properly manage the STMPE
"norequest mask" to disallow also mapping said lines as
IRQs.
Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Reviewed-by: Patrice Chotard <patrice.chotard@st.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
The HTC GPIO driver is a pure GPIO driver and I just can not
see what it is doing inside MFD. Let's just move it to GPIO
and take this opportunity to move the platform data to
<linux/platform_data/gpio-htc-egpio.h>
Cc: arm@kernel.org
Cc: Russell King <linux@armlinux.org.uk>
Acked-by: Lee Jones <lee.jones@linaro.org>
Acked-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
This patch add basic structure of a virtual gpio device(gpio-mockup)
for testing gpio subsystem. The tester could manipulate such device
through userspace(sysfs or char device) and check the result from
debugfs.
Currently, it support one or more gpiochip(determined by module
parameters with base,ngpio pair). One could test the overlap of
different gpiochip and test the direction and/or output values of
these chips.
Signed-off-by: Kamlakant Patel <kamlakant.patel@broadcom.com>
Signed-off-by: Bamvor Jian Zhang <bamvor.zhangjian@linaro.org>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
sparse rightfully said:
drivers/gpio/gpio-pca953x.c:771:45: warning: symbol 'id' shadows an earlier one
drivers/gpio/gpio-pca953x.c:742:36: originally declared here
So, name them explicitly 'i2c_id' and 'acpi_id' to avoid any confusion.
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
If an I2C GPIO multiplexer is driven by a GPIO provided by an expander
when there's a second expander using the same device driver on one of
the I2C bus segments, lockdep prints a deadlock warning when trying to
set the direction or the value of the GPIOs provided by the second
expander.
The below diagram presents the setup:
- - - - -
------- --------- Bus segment 1 | |
| | | |--------------- Devices
| | SCL/SDA | | | |
| Linux |-----------| I2C MUX | - - - - -
| | | | | Bus segment 2
| | | | |-------------------
------- | --------- |
| | - - - - -
------------ | MUX GPIO | |
| | | Devices
| GPIO | | | |
| Expander 1 |---- - - - - -
| | |
------------ | SCL/SDA
|
------------
| |
| GPIO |
| Expander 2 |
| |
------------
The reason for lockdep warning is that we take the chip->i2c_lock in
pca953x_gpio_set_value() or pca953x_gpio_direction_output() and then
come right back to pca953x_gpio_set_value() when the GPIO mux kicks
in. The locks actually protect different expanders, but for lockdep
both are of the same class, so it says:
Possible unsafe locking scenario:
CPU0
----
lock(&chip->i2c_lock);
lock(&chip->i2c_lock);
*** DEADLOCK ***
May be due to missing lock nesting notation
In order to get rid of the warning, retrieve the adapter nesting depth
and use it as lockdep subclass for chip->i2c_lock.
Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
Acked-by: Peter Rosin <peda@axentia.se>
Acked-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
This patch adds zynq specific check for bank 0 pins 7 and 8
are special and cannot be used as inputs
Signed-off-by: Nava kishore Manne <navam@xilinx.com>
Reported-by: Jonas Karlsson <Jonas.d.karlsson@gmail.com>
Acked-by: Sören Brinkmann <soren.brinkmann@xilinx.com>
Acked-by: Michal Simek <michal.simek@xilinx.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Implement the get_direction callback for the GPIOs found in the AXP209
PMIC.
Due to the way they are implemented, in the same register you have the
muxing options, GPIO directions and GPIO values. Since you have no control
over what value is there at reset, simply use output as the default.
Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Remove unneeded error handling on the result of a call
to platform_get_resource() when the value is passed to
devm_ioremap_resource().
Signed-off-by: Wei Yongjun <weiyongjun1@huawei.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Remove unneeded error handling on the result of a call
to platform_get_resource() when the value is passed to
devm_ioremap_resource().
Signed-off-by: Wei Yongjun <weiyongjun1@huawei.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
When using GPIO irqchip helpers to setup irqchip for a gpiolib based
driver, it is not possible to select which GPIOs to add to the IRQ domain.
Instead it just adds all GPIOs which is not always desired. For example
there might be GPIOs that for some reason cannot generated normal
interrupts at all.
To support this we add a flag irq_need_valid_mask to struct gpio_chip. When
this flag is set the core allocates irq_valid_mask that holds one bit for
each GPIO the chip has. By default all bits are set but drivers can
manipulate this using set_bit() and clear_bit() accordingly.
Then when gpiochip_irqchip_add() is called, this mask is checked and all
GPIOs with bit is set are added to the IRQ domain created for the GPIO
chip.
Suggested-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
A bunch of variables were just declared "unsigned" and should
be "unsigned int". Fix it up for this driver.
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
This adds a .get_direction() callback to the TC3589x and
renames the function for setting single-ended mode to be
more to the point.
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
William Breathitt Gray