Commtech adapters need the MPIOs for internal purposes, and the
gpio-exar driver already refused to pick them up. But there is actually
no point in even creating the underlying platform device.
Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
acpi_walk_resources will stop as soon as the callback passed in returns
an error status. On a x86 tablet I have the first GpioInt in the _AEI
resource list has no handler defined in the DSDT, causing
acpi_walk_resources to abort scanning the rest of the resource list,
which does define valid ACPI GPIO events.
This commit changes the return for not finding a handler from
AE_BAD_PARAMETER to AE_OK so that the rest of the resource list will
get scanned normally in case of missing event handlers.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Acked-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Acked-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Renesas RZ/G1M (R8A7743) SoC GPIO blocks are identical to the R-Car Gen2
family. Add support for its GPIO controllers.
Signed-off-by: Biju Das <biju.das@bp.renesas.com>
Reviewed-by: Chris Paterson <chris.paterson2@renesas.com>
Acked-by: Geert Uytterhoeven <geert+renesas@glider.be>
Acked-by: Rob Herring <robh@kernel.org>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
According to Whiskey Cove PMIC GPIO controller specification, for GPIO
pins 0-12, GPIO input and output register control address range from,
0x4e44-0x4e50 for GPIO outputs control register
0x4e51-0x4e5d for GPIO input control register
But, currently when calculating the GPIO register offsets in to_reg()
function, all GPIO pins in the same bank uses the same GPIO control
register address. This logic is incorrect. This patch fixes this
issue.
This patch also adds support to selectively skip register modification
for virtual GPIOs.
In case of Whiskey Cove PMIC, ACPI code may use up 94 virtual GPIOs.
These virtual GPIOs are used by the ACPI code as means to access various
non GPIO bits of PMIC. So for these virtual GPIOs, we don't need to
manipulate the physical GPIO pin register. A similar patch has been
merged recently by Hans for Crystal Cove PMIC GPIO driver. You can
find more details about it in Commit 9a752b4c9a ("gpio: crystalcove:
Do not write regular gpio registers for virtual GPIOs")
Signed-off-by: Kuppuswamy Sathyanarayanan <sathyanarayanan.kuppuswamy@linux.intel.com>
Reported-by: Jukka Laitinen <jukka.laitinen@intel.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
GPIOEVENT_REQUEST_BOTH_EDGES is not a single flag, but a binary OR of
GPIOEVENT_REQUEST_RISING_EDGE and GPIOEVENT_REQUEST_FALLING_EDGE.
The expression 'le->eflags & GPIOEVENT_REQUEST_BOTH_EDGES' we'll get
evaluated to true even if only one event type was requested.
Fix it by checking both RISING & FALLING flags explicitly.
Cc: stable@vger.kernel.org
Fixes: 61f922db72 ("gpio: userspace ABI for reading GPIO line events")
Signed-off-by: Bartosz Golaszewski <brgl@bgdev.pl>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Add driver for lp87565 PMIC family GPIOs. Three GPIOs are supported
and can be configured in Open-drain output or Push-pull output.
Signed-off-by: Keerthy <j-keerthy@ti.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
dwapb_irq_set_type overwrites polarity register value for
IRQ_TYPE_EDGE_BOTH case. If the polarity of one gpio is 0
by default, then it will set falling edge irq trigger.
and the gpio may requires rising edge irq for the first time,
and it will be missed.
Do not overwrite polarity register for IRQ_TYPE_EDGE_BOTH case
can solve this issue.
Signed-off-by: Xiaoguang Chen <xgchenshy@gmail.com>
Tested-by: Jisheng Zhang <jszhang@marvell.com>
[Fix some really weird text encoding problem]
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
As it turns out more than just Armada 370 and XP support using GPIO
lines as PWM lines. For example the Armada 38x family has the same
hardware support. As such "marvell,armada-370-xp-gpio" for the
compatible string is a misnomer.
Change the compatible string to "marvell,armada-370-gpio" before the
driver makes it out of the -rc stage. This also follows the practice of
using only the first device family supported as part of the name.
Also update the documentation and comments in the code accordingly.
Fixes: 757642f9a5 ("gpio: mvebu: Add limited PWM support")
Signed-off-by: Ralph Sennhauser <ralph.sennhauser@gmail.com>
Acked-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
Acked-by: Rob Herring <robh@kernel.org>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
First, the logic for translating a register bit to the return code of
exar_get_direction and exar_get_value were wrong. And second, there was
a flip regarding the register bank in exar_get_direction.
Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Do not allocate resources on behalf of the parent device but on our own.
Otherwise, cleanup does not properly work if gpio-exar is removed but
not the parent device.
Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
This fixes reloading of the GPIO driver for the same platform device
instance as created by the exar UART driver: First of all, the driver
sets drvdata to its own value during probing and does not restore the
original value on exit. But this won't help anyway as the core clears
drvdata after the driver left.
Set the platform device parent instead.
Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
When allocating a zeroed array of objects use devm_kcalloc() instead
of manually calculating the required size and using devm_kzalloc().
Signed-off-by: Bartosz Golaszewski <brgl@bgdev.pl>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Just taking credit for the recent changes and new features. :)
Signed-off-by: Bartosz Golaszewski <brgl@bgdev.pl>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Indicate the error number and make the message a bit more elaborate.
Signed-off-by: Bartosz Golaszewski <brgl@bgdev.pl>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
When the requested number of GPIO lines is 0, return -EINVAL, not
-1 which is -EPERM.
Signed-off-by: Bartosz Golaszewski <brgl@bgdev.pl>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
We currently shift bits here and there without actually explaining
what we're doing. Add some helper variables with names indicating
their purpose to improve the code readability.
Signed-off-by: Bartosz Golaszewski <brgl@bgdev.pl>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Currently we ignore the last odd range value, since each chip is
described by two values. Be more strict and require the user to
pass an even number of ranges.
Signed-off-by: Bartosz Golaszewski <brgl@bgdev.pl>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Invert the logic of the irq_enabled check and only access the private
data after the input is sanitized.
Signed-off-by: Bartosz Golaszewski <brgl@bgdev.pl>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
We're currently only checking the first character of the input to the
debugfs event files, so a string like '0sdfdsf' is valid and indicates
a falling edge event.
Be more strict and only allow '0', '1', '0\n' & '1\n'.
While we're at it: move the sanitization code before the irq_enabled
check so that we indicate an error on invalid input even if nobody is
waiting for events.
Signed-off-by: Bartosz Golaszewski <brgl@bgdev.pl>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Currently all PMIC GPIO domain IRQs are consumed by the same
device(bxt_wcove_gpio), so there is no need to export them as
separate interrupts. We can just export only the first level
GPIO IRQ(BXTWC_GPIO_LVL1_IRQ) as an IRQ resource and let the
GPIO device driver(bxt_wcove_gpio) handle the GPIO sub domain
IRQs based on status value of GPIO level2 interrupt status
register. Also, just using only the first level IRQ will eliminate
the bug involved in requesting only the second level IRQ and not
explicitly enable the first level IRQ. For more info on this
issue please read the details at,
https://lkml.org/lkml/2017/2/27/148
This patch also makes relevant change in Whiskey cove GPIO driver to
use only first level PMIC GPIO IRQ.
Signed-off-by: Kuppuswamy Sathyanarayanan <sathyanarayanan.kuppuswamy@linux.intel.com>
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Acked-for-MFD-by: Lee Jones <lee.jones@linaro.org>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
The Armada 7K and 8K SoCs use the same gpio controller as most of the
other mvebu SoCs. However, the main difference is that the GPIO
controller is part of a bigger system controller, and a syscon is used to
control the overall system controller. Therefore, the driver needs to be
adjusted to retrieve the regmap of the syscon to access registers, and
account for the fact that registers are located at a certain offset
within the regmap.
This commit add the support of the syscon and introduce a new variant for
this case.
It was based on the preliminary work of Thomas Petazzoni.
Tested-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
In some place in the driver regmap_update_bits was misused. Indeed the
last argument is not the value of the bit (or group of bits) itself but
the mask value inside the register.
So when setting the bit N, then the value must be BIT(N) and not 1.
CC: Ralph Sennhauser <ralph.sennhauser@gmail.com>
Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
Reviewed-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Tested-by: Ralph Sennhauser <ralph.sennhauser@gmail.com>
Tested-by: Chris Packham <Chris.Packham@alliedtelesis.co.nz>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
The one quirk used in the zynq GPIO driver was called FOO which is not
very descriptive. Rename the quirk to IS_ZYNQ as it indicates whether
the HW is a zynq or zynqmp device to allow handling of device-specific
differences of the HW.
Also provide a helper function to test whether the HW is zynq or zynqmp.
Signed-off-by: Soren Brinkmann <soren.brinkmann@xilinx.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
I don't remember how linux/gpio.h made the source, now it seems unused.
Remove it.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
The class_attrs pointer is long depreciated, and is about to be finally
removed, so move to use the class_groups pointer instead.
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Cc: Alexandre Courbot <gnurou@gmail.com>
Cc: <linux-gpio@vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
If more than one gpio bank has the "pwm" property, only one will be
registered successfully, all the others will fail with:
mvebu-gpio: probe of f1018140.gpio failed with error -17
That's because in alloc_pwms(), the chip->base (aka "int pwm"), was not
set (thus, ==0) ; and 0 is a meaningful start value in alloc_pwm().
What was intended is mvpwm->chip->base = -1.
Like that, the numbering will be done auto-magically
Moreover, as the region might be already occupied by another pwm, we
shouldn't force:
mvpwm->chip->base = 0
nor
mvpwm->chip->base = id * MVEBU_MAX_GPIO_PER_BANK;
Tested on clearfog-pro (Marvell 88F6828)
Fixes: 757642f9a5 ("gpio: mvebu: Add limited PWM support")
Signed-off-by: Richard Genoud <richard.genoud@gmail.com>
Reviewed-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
The blink counter A was always selected because 0 was forced in the
blink select counter register.
The variable 'set' was obviously there to be used as the register value,
selecting the B counter when id==1 and A counter when id==0.
Tested on clearfog-pro (Marvell 88F6828)
Fixes: 757642f9a5 ("gpio: mvebu: Add limited PWM support")
Reviewed-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
Reviewed-by: Ralph Sennhauser <ralph.sennhauser@gmail.com>
Signed-off-by: Richard Genoud <richard.genoud@gmail.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Without the regmap code, we get a link error:
drivers/gpio/built-in.o: In function `xra1403_probe':
(.text+0x132e0): undefined reference to `__devm_regmap_init_spi'
Fixes: 5704520d78 ("gpio: xra1403: Add EXAR XRA1403 SPI GPIO expander driver")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Reviewed-by: Nandor Han <nandor.han@ge.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
This was left behind by a cleanup patch:
drivers/gpio/gpiolib.c: In function 'gpiochip_irqchip_init_valid_mask':
drivers/gpio/gpiolib.c:1474:6: error: unused variable 'i' [-Werror=unused-variable]
Fixes: 923a654c18 ("gpiolib: Re-use bitmap_fill() instead of open coded loop")
Reported-by: kbuild test robot <fengguang.wu@intel.com>
Reported-by: Stephen Rothwell <sfr@canb.auug.org.au>
Reported-by: Colin King <colin.king@canonical.com>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Fix compile errors due to missing OF.
Cc: Paul Cercueil <paul@crapouillou.net>
Reported-by: Randy Dunlap <rdunlap@infradead.org>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
include/linux/i2c is not for client devices. Move the header file to a
more appropriate location.
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
Acked-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
This function can fail, so check the return value before dereferencing
the returned pointer.
Signed-off-by: Bartosz Golaszewski <brgl@bgdev.pl>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
This function can fail, so check the return value before dereferencing
the returned pointer.
Signed-off-by: Bartosz Golaszewski <brgl@bgdev.pl>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
This function can fail, so check the return value before dereferencing
the returned pointer.
Signed-off-by: Bartosz Golaszewski <brgl@bgdev.pl>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Even though this is a testing module, be nice and actually implement
these functions.
Signed-off-by: Bartosz Golaszewski <brgl@bgdev.pl>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
When inserting and removing the module repeatedly (e.g. when running
the libgpiod test-suite) the kernel log gets clobbered with messages
reporting successful creation of dummy gpiochips.
Remove this message and only emit logs when something bad happens.
Signed-off-by: Bartosz Golaszewski <brgl@bgdev.pl>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
All internal symbols except for the direction enum follow the same
convention and use the gpio_mockup prefix. Add the prefix to the
DIR_IN and DIR_OUT definitions as well for consistency across the
file.
Signed-off-by: Bartosz Golaszewski <brgl@bgdev.pl>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
The comment in linux/gpio/driver.h says:
@get_direction: returns direction for signal "offset", 0=out, 1=in
We got those switched at some point. Fix the values.
Signed-off-by: Bartosz Golaszewski <brgl@bgdev.pl>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Re-use bitmap_fill() instead of open coded loop for setting an area of
bits in a bitmap.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
The helper does retrieve pointer to struct acpi_resource_gpio from
struct acpi_resource if it represents GpioInt() resource.
It will be used by PNP code later on.
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>
This allows ACPI GPIO code to modify flags based on
ACPI GpioIo() / GpioInt() resources.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Tested-by: Jarkko Nikula <jarkko.nikula@linux.intel.com>
Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
The helper function acpi_gpio_to_gpiod_flags() will be used later to configure
pin properly whenever it's requested.
While here, introduce a checking error code returned by gpiod_configure_flags()
and bail out if it's not okay.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Tested-by: Jarkko Nikula <jarkko.nikula@linux.intel.com>
Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
If we pass connection ID to the both functions and at the same time
acpi_can_fallback_to_crs() returns false we will get different results,
i.e. the number of GPIO resources returned by acpi_gpio_count() might be
not correct.
Fix this by calling acpi_can_fallback_to_crs() in acpi_gpio_count()
before trying to fallback.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Tested-by: Jarkko Nikula <jarkko.nikula@linux.intel.com>
Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
The commit 10cf4899f8 ("gpiolib: tighten up ACPI legacy gpio lookups")
prevents to getting same resource twice if the driver asks twice using
different connection ID.
But the whole idea of fallback might bring some problems. Imagine the case when
we have two versions of BIOS/hardware where in one _DSD is introduced along
with GPIO resources, but the other one uses just plain GPIO resource for
another purpose
Case 1:
Device (DEVX)
{
...
Name (_CRS, ResourceTemplate ()
{
GpioIo (Exclusive, PullUp, 0, 0, IoRestrictionInputOnly,
"\\_SB.GPO0", 0, ResourceConsumer) {15}
})
Name (_DSD, Package ()
{
ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"),
Package ()
{
Package () {"some-gpios", Package() {^DEVX, 0, 0, 0 }},
}
})
}
Case 2:
Device (DEVX)
{
...
Name (_CRS, ResourceTemplate ()
{
GpioIo (Exclusive, PullUp, 0, 0, IoRestrictionInputOnly,
"\\_SB.GPO0", 0, ResourceConsumer) {27}
})
}
To prevent the possible misconfiguration tighten up even more GPIO ACPI lookups
for case without connection ID provided.
In the past the issue had been triggered by "use mctrl_gpio helpers" series
[1,2].
[1] commit 4ef03d3287 ("tty/serial/8250: use mctrl_gpio helpers")
[2] https://patchwork.kernel.org/patch/9283745/
Cc: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Cc: Bastien Nocera <hadess@hadess.net>
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Tested-by: Jarkko Nikula <jarkko.nikula@linux.intel.com>
Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Check that we don't ask for output direction on GpioInt resource
in cases with or without _DSD defined.
Reviewed-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Tested-by: Jarkko Nikula <jarkko.nikula@linux.intel.com>
Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
By some reason acpi_find_gpio() and acpi_gpio_count() have compared
connection ID to "gpios" when tries to check if suffix is needed or not.
Don't do any assumptions about what connection ID can be and, when defined,
use it only with suffix as it's done in the device tree version.
Reviewed-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Tested-by: Jarkko Nikula <jarkko.nikula@linux.intel.com>
Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
This is preparatory patch for enabling GPIO ACPI to configure a pin
accordingly.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Tested-by: Jarkko Nikula <jarkko.nikula@linux.intel.com>
Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
The Arizona devices only maintain the state of output GPIOs whilst the
CODEC is active, this can cause issues if the CODEC suspends whilst
something is relying on the state of one of its GPIOs. However, in
many systems the CODEC GPIOs are used for audio related features
and thus the state of the GPIOs is unimportant whilst the CODEC is
suspended. Often keeping the CODEC resumed in such a system would
incur a power impact that is unacceptable.
Allow the user to select whether a GPIO output should keep the
CODEC resumed, by adding a flag through the second cell of the GPIO
specifier in device tree.
Signed-off-by: Charles Keepax <ckeepax@opensource.wolfsonmicro.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Add new flags to allow users to specify that they are not concerned with
the status of GPIOs whilst in a sleep/low power state.
Signed-off-by: Charles Keepax <ckeepax@opensource.wolfsonmicro.com>
Acked-by: Rob Herring <robh@kernel.org>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
clk_prepare_enable() can fail here and we must check its return value.
Signed-off-by: Arvind Yadav <arvind.yadav.cs@gmail.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Since the commit "gpio: mvebu: switch to regmap for register access" the
driver use the regmap. Explicitly select the REGMAP_MMIO symbol to fix
build error.
Reported-by: kbuild test robot <fengguang.wu@intel.com>
Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Broadcom Vulcan (ARCH_VULCAN) has been discontinued and will be deleted
soon. So, update the GPIO_XLP Kconfig entry to remove the ARCH_VULCAN
dependency.
Also update the documentation to note that Cavium ThunderX2 uses this
driver.
Signed-off-by: Jayachandran C <jnair@caviumnetworks.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
include/linux/i2c is not for client devices. Move the header file to a
more appropriate location.
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
include/linux/i2c is not for client devices. Move the header file to a
more appropriate location.
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
The mvebu gpio driver can also be used on arm64 mvebu SoC such as the
Armada 7K/8K. This commit allows to build the driver for them (when only
ARCH_MVEBU is defined)
Reviewed-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
In order to be able to use this driver with the Armada 7K/8K SoCs, we
need to use the regmap to access the registers. Indeed for these new SoCs,
the gpio node will be part of a syscon.
[gregory.clement@free-electrons.com:
- fixed merge conflcit from 4.10 to 4.12-rc1
- added a commit log]
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
The Crystal Cove PMIC has 16 real GPIOs but the ACPI code for devices
with this PMIC may address up to 95 GPIOs, these extra GPIOs are
called virtual GPIOs and are used by the ACPI code as a method of
accessing various non GPIO bits of PMIC.
Commit dcdc3018d6 ("gpio: crystalcove: support virtual GPIO") added
dummy support for these to avoid a bunch of ACPI errors, but instead of
ignoring writes / reads to them by doing:
if (gpio >= CRYSTALCOVE_GPIO_NUM)
return 0;
It accidentally introduced the following wrong check:
if (gpio > CRYSTALCOVE_VGPIO_NUM)
return 0;
Which means that attempts by the ACPI code to access these gpios
causes some arbitrary gpio to get touched through for example
GPIO1P0CTLO + gpionr % 8.
Since we do support input/output (but not interrupts) on the 0x5e
virtual GPIO, this commit makes to_reg return -ENOTSUPP for unsupported
virtual GPIOs so as to not have to check for (gpio >= CRYSTALCOVE_GPIO_NUM
&& gpio != 0x5e) everywhere and to make it easier to add support for more
virtual GPIOs in the future.
It then adds a check for to_reg returning an error to all callers where
this may happen fixing the ACPI code accessing virtual GPIOs accidentally
causing changes to real GPIOs.
Fixes: dcdc3018d6 ("gpio: crystalcove: support virtual GPIO")
Cc: Aaron Lu <aaron.lu@intel.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
This moves the mcp23s08 driver from gpio to pinctrl. Actual
pinctrl support for configuration of the pull-up resistors
follows in its own patch.
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.co.uk>
Acked-by: Sylvain Lemieux <slemieux.tyco@gmail.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
This driver support basic XRA1403 functionalities:
- set gpio direction
- get gpio direction
- set gpio high/low
- get gpio status
Signed-off-by: Nandor Han <nandor.han@ge.com>
Signed-off-by: Semi Malinen <semi.malinen@ge.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
This driver handles the GPIOs of all the Ingenic JZ47xx SoCs
currently supported by the upsteam Linux kernel.
Signed-off-by: Paul Cercueil <paul@crapouillou.net>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
For hot-pluggable devices adding GPIOs dynamically we need to
assemble and add the gpio lookup tables at probe time in modules,
so that requesting these GPIOs in attached drivers can work.
Export lookup table functions for modules.
Signed-off-by: Anatolij Gustschin <agust@denx.de>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
We warn the user at driver probe time that debouncing is disabled.
However, if they request debouncing later on we print a confusing error
message:
gpio_aspeed 1e780000.gpio: Failed to convert 5000us to cycles at 0Hz: -524
Instead bail out when the clock is not present.
Fixes: 5ae4cb94b3 (gpio: aspeed: Add debounce support)
Signed-off-by: Joel Stanley <joel@jms.id.au>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
-----BEGIN PGP SIGNATURE-----
iQIVAwUAWPiW6vSw1s6N8H32AQLOrw/+NTqGf7bjq+64YKS6NfR0XDgE+wNJltGO
ck7zJW3NHIg76RNu8s0I9xg5aVmwizz3Z5DGROZquaolnezux4tQihZ3AFyxIzLc
+Y3WHYagcML7yFfjl/WznCLRD5EW3yPln4lCvQO0nW/xICRYeRI057JaIbi2Dtek
BhcXt3c4AjXDLdYJkgtHV3p2R2mt8hcdFdWqqx6s7JaIThZNRGNzxAgtbcB9k5IW
HVG9ZEIL73VBYWHrYivzjHYF5rBnNCPt87eOwDQeTOSkhv8te+u9k+bH8vxZw1T0
XUtDrLBndKiuVo2GUfLkkF8LItx3Q9eLCJYy0joaIliyPqTEsPx9KjQ+Af0cxS9s
ZPCZ5SYf96stKmDeL5xaMfrAmeyVHJ4lc4JTOqdzbIT8blsOSfYO/03p0ALShSDv
/RQLaKGlf8Bjoy8PwKFcXb4sIDufcd/U1Av/EMFXxOfgN/u2JUkGKq6EaIM5B68L
fHPje+aR9VNELPmPjwNOWtmN4I79EH3EItQf7zv0KG+UeKhcHLx/EAcSJ3ZRKEkH
Lathg7pPOEJGArPiVO79TZzBG01ADn1aiwv65XObMzNZ+54xI/mN/Y1DNF/kL5jU
XzvNzEjFt8mwMIZGVNdAt4+pDyMfIZGZSyUkSRKFnaQZMIvQrfQIU9RLBYLX5eOx
+/p0VkIwDpg=
=lbS7
-----END PGP SIGNATURE-----
Merge tag 'hwparam-20170420' of git://git.kernel.org/pub/scm/linux/kernel/git/dhowells/linux-fs
Pull hw lockdown support from David Howells:
"Annotation of module parameters that configure hardware resources
including ioports, iomem addresses, irq lines and dma channels.
This allows a future patch to prohibit the use of such module
parameters to prevent that hardware from being abused to gain access
to the running kernel image as part of locking the kernel down under
UEFI secure boot conditions.
Annotations are made by changing:
module_param(n, t, p)
module_param_named(n, v, t, p)
module_param_array(n, t, m, p)
to:
module_param_hw(n, t, hwtype, p)
module_param_hw_named(n, v, t, hwtype, p)
module_param_hw_array(n, t, hwtype, m, p)
where the module parameter refers to a hardware setting
hwtype specifies the type of the resource being configured. This can
be one of:
ioport Module parameter configures an I/O port
iomem Module parameter configures an I/O mem address
ioport_or_iomem Module parameter could be either (runtime set)
irq Module parameter configures an I/O port
dma Module parameter configures a DMA channel
dma_addr Module parameter configures a DMA buffer address
other Module parameter configures some other value
Note that the hwtype is compile checked, but not currently stored (the
lockdown code probably won't require it). It is, however, there for
future use.
A bonus is that the hwtype can also be used for grepping.
The intention is for the kernel to ignore or reject attempts to set
annotated module parameters if lockdown is enabled. This applies to
options passed on the boot command line, passed to insmod/modprobe or
direct twiddling in /sys/module/ parameter files.
The module initialisation then needs to handle the parameter not being
set, by (1) giving an error, (2) probing for a value or (3) using a
reasonable default.
What I can't do is just reject a module out of hand because it may
take a hardware setting in the module parameters. Some important
modules, some ipmi stuff for instance, both probe for hardware and
allow hardware to be manually specified; if the driver is aborts with
any error, you don't get any ipmi hardware.
Further, trying to do this entirely in the module initialisation code
doesn't protect against sysfs twiddling.
[!] Note that in and of itself, this series of patches should have no
effect on the the size of the kernel or code execution - that is
left to a patch in the next series to effect. It does mark
annotated kernel parameters with a KERNEL_PARAM_FL_HWPARAM flag in
an already existing field"
* tag 'hwparam-20170420' of git://git.kernel.org/pub/scm/linux/kernel/git/dhowells/linux-fs: (38 commits)
Annotate hardware config module parameters in sound/pci/
Annotate hardware config module parameters in sound/oss/
Annotate hardware config module parameters in sound/isa/
Annotate hardware config module parameters in sound/drivers/
Annotate hardware config module parameters in fs/pstore/
Annotate hardware config module parameters in drivers/watchdog/
Annotate hardware config module parameters in drivers/video/
Annotate hardware config module parameters in drivers/tty/
Annotate hardware config module parameters in drivers/staging/vme/
Annotate hardware config module parameters in drivers/staging/speakup/
Annotate hardware config module parameters in drivers/staging/media/
Annotate hardware config module parameters in drivers/scsi/
Annotate hardware config module parameters in drivers/pcmcia/
Annotate hardware config module parameters in drivers/pci/hotplug/
Annotate hardware config module parameters in drivers/parport/
Annotate hardware config module parameters in drivers/net/wireless/
Annotate hardware config module parameters in drivers/net/wan/
Annotate hardware config module parameters in drivers/net/irda/
Annotate hardware config module parameters in drivers/net/hamradio/
Annotate hardware config module parameters in drivers/net/ethernet/
...
Here is the big set of new char/misc driver drivers and features for
4.12-rc1.
There's lots of new drivers added this time around, new firmware drivers
from Google, more auxdisplay drivers, extcon drivers, fpga drivers, and
a bunch of other driver updates. Nothing major, except if you happen to
have the hardware for these drivers, and then you will be happy :)
All of these have been in linux-next for a while with no reported
issues.
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-----BEGIN PGP SIGNATURE-----
iG0EABECAC0WIQT0tgzFv3jCIUoxPcsxR9QN2y37KQUCWQvAgg8cZ3JlZ0Brcm9h
aC5jb20ACgkQMUfUDdst+yknsACgzkAeyz16Z97J3UTaeejbR7nKUCAAoKY4WEHY
8O9f9pr9gj8GMBwxeZQa
=OIfB
-----END PGP SIGNATURE-----
Merge tag 'char-misc-4.12-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc
Pull char/misc driver updates from Greg KH:
"Here is the big set of new char/misc driver drivers and features for
4.12-rc1.
There's lots of new drivers added this time around, new firmware
drivers from Google, more auxdisplay drivers, extcon drivers, fpga
drivers, and a bunch of other driver updates. Nothing major, except if
you happen to have the hardware for these drivers, and then you will
be happy :)
All of these have been in linux-next for a while with no reported
issues"
* tag 'char-misc-4.12-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc: (136 commits)
firmware: google memconsole: Fix return value check in platform_memconsole_init()
firmware: Google VPD: Fix return value check in vpd_platform_init()
goldfish_pipe: fix build warning about using too much stack.
goldfish_pipe: An implementation of more parallel pipe
fpga fr br: update supported version numbers
fpga: region: release FPGA region reference in error path
fpga altera-hps2fpga: disable/unprepare clock on error in alt_fpga_bridge_probe()
mei: drop the TODO from samples
firmware: Google VPD sysfs driver
firmware: Google VPD: import lib_vpd source files
misc: lkdtm: Add volatile to intentional NULL pointer reference
eeprom: idt_89hpesx: Add OF device ID table
misc: ds1682: Add OF device ID table
misc: tsl2550: Add OF device ID table
w1: Remove unneeded use of assert() and remove w1_log.h
w1: Use kernel common min() implementation
uio_mf624: Align memory regions to page size and set correct offsets
uio_mf624: Refactor memory info initialization
uio: Allow handling of non page-aligned memory regions
hangcheck-timer: Fix typo in comment
...
Core changes
- Return NULL from gpiod_get_optional() when GPIOLIB is disabled.
This was a much discussed change. It affects use cases where people
write drivers that might or might not be using GPIO resources.
I have decided that this is the lesser evil right now.
- Make gpiod_count() behave consistently across different hardware
descriptions.
- Fix the syntax around open drain/open source to not infer active
high/low semantics.
New drivers
- A new single-register fixed-direction framework driver for hardware
that have lines controlled by a single register that just work in
one direction (out or in), including IRQ support.
- Support the Fintek F71889A GPIO SuperIO controller.
- Support the National NI 169445 MMIO GPIO.
- Support for the X-Gene derivative of the DWC GPIO controller
- Support for the Rohm BD9571MWV-M PMIC GPIO controller.
- Refactor the Gemini GPIO driver to a generic Faraday FTGPIO driver
and replace both the Gemini and the Moxa ART custom drivers with
this driver.
Driver improvements
- A whole slew of drivers have their spinlocks chaned to raw spinlocks
as they provide irqchips, and thus we are progressing on realtime
compliance.
- Use devm_irq_alloc_descs() in a slew of drivers, getting managed
resources.
- Support for the embedded PWM controller inside the MVEBU driver.
- Debounce, open source and open drain support for the Aspeed driver.
- Misc smaller fixes like spelling and syntax and whatnot.
-----BEGIN PGP SIGNATURE-----
iQIcBAABAgAGBQJZCusBAAoJEEEQszewGV1zengP/i3YgmSXJdaf26t/NxG3klU3
qx3akdQ3gEQ6BOlIY7Ew+b6qgMJynYNZa1trZgqTgLxPEKWjidyCgz+LHQ0OY+ir
a7x6wr+gBj5WlgV+nBjVs4l6W8pVKCfnap/04OPEQDpxZOHs2LU5pqxxUZ9AxkKS
urDFMDX55baFviQ+xAuHgamok87YoGP36A/e/fHIBepZmnochf0mCcPfIh0t8lRh
s2x29PN5ZFRkl403RzjZfVCEMr9bMnSqmDquvPO++Kq0bL+3rOhuMErocd1Bg8ao
LxBktkryujTaw699xK7Rq5SwcnOAPpaBY4NTmwsIJvAJuCh7qLy9JxQSBsSOT2bx
61NWUt5T/Xsi0ECYZM4YvsNpUP6XrpSTyG3c8T3fY9vXYLNKZBv1ht6OODpLeuke
DxULAWP+DdzUS8a3qfKQvIJzSTloU31a1MBG58DWNJ072EQfa2YNaVE75VQk/z5/
0xZbSHdPY/0Xgx8ltpKu37bSO676JiVQZZ1HEAuti4h21+USYueYD2L8/Bx4k9e/
4UaOcw3MaCDHP/sf5hg17kQBjhhS0lV9Zv6H9QbHZUocJTJlIU+vXtgkQlrfi3n8
8j5m+ywVarmLtPqg1j2rqcw7LBCPe0qRXH3e5X/YmNMc3rH9bQz4cTo8ZSN9r8zS
c17zGbbAqlGsBkpFAbQz
=DGPb
-----END PGP SIGNATURE-----
Merge tag 'gpio-v4.12-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.12 kernel cycle.
Core changes:
- Return NULL from gpiod_get_optional() when GPIOLIB is disabled.
This was a much discussed change. It affects use cases where people
write drivers that might or might not be using GPIO resources. I
have decided that this is the lesser evil right now.
- Make gpiod_count() behave consistently across different hardware
descriptions.
- Fix the syntax around open drain/open source to not infer active
high/low semantics.
New drivers:
- A new single-register fixed-direction framework driver for hardware
that have lines controlled by a single register that just work in
one direction (out or in), including IRQ support.
- Support the Fintek F71889A GPIO SuperIO controller.
- Support the National NI 169445 MMIO GPIO.
- Support for the X-Gene derivative of the DWC GPIO controller
- Support for the Rohm BD9571MWV-M PMIC GPIO controller.
- Refactor the Gemini GPIO driver to a generic Faraday FTGPIO driver
and replace both the Gemini and the Moxa ART custom drivers with
this driver.
Driver improvements:
- A whole slew of drivers have their spinlocks chaned to raw
spinlocks as they provide irqchips, and thus we are progressing on
realtime compliance.
- Use devm_irq_alloc_descs() in a slew of drivers, getting managed
resources.
- Support for the embedded PWM controller inside the MVEBU driver.
- Debounce, open source and open drain support for the Aspeed driver.
- Misc smaller fixes like spelling and syntax and whatnot"
* tag 'gpio-v4.12-1' of git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-gpio: (77 commits)
gpio: f7188x: Add a missing break
gpio: omap: return error if requested debounce time is not possible
gpio: Add ROHM BD9571MWV-M PMIC GPIO driver
gpio: gpio-wcove: fix GPIO IRQ status mask
gpio: DT bindings, move tca9554 from pcf857x to pca953x
gpio: move tca9554 from pcf857x to pca953x
gpio: arizona: Correct check whether the pin is an input
gpio: Add XRA1403 DTS binding documentation
dt-bindings: add exar to vendor prefixes list
gpio: gpio-wcove: fix irq pending status bit width
gpio: dwapb: use dwapb_read instead of readl_relaxed
gpio: aspeed: Add open-source and open-drain support
gpio: aspeed: Add debounce support
gpio: aspeed: dt: Add optional clocks property
gpio: aspeed: dt: Fix description alignment in bindings document
gpio: mvebu: Add limited PWM support
gpio: Use unsigned int for interrupt numbers
gpio: f7188x: Add F71889A GPIO support.
gpio: core: Decouple open drain/source flag with active low/high
gpio: arizona: Correct handling for reading input GPIOs
...
omap_gpio_debounce() does not validate that the requested debounce
is within a range it can handle. Instead it lets the register value
wrap silently, and always returns success.
This can lead to all sorts of unexpected behavior, such as gpio_keys
asking for a too-long debounce, but getting a very short debounce in
practice.
Fix this by returning -EINVAL if the requested value does not fit into
the register field. If there is no debounce clock available at all,
return -ENOTSUPP.
Fixes: e85ec6c304 ("gpio: omap: fix omap2_set_gpio_debounce")
Cc: <stable@vger.kernel.org> # 4.3+
Signed-off-by: David Rivshin <drivshin@allworx.com>
Acked-by: Grygorii Strashko <grygorii.strashko@ti.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Add driver for the GPIO block in the ROHM BD9571MWV-W MFD PMIC.
This block is pretty trivial and supports setting GPIO direction
as Input/Output and in case of Output, supports setting value.
Signed-off-by: Marek Vasut <marek.vasut+renesas@gmail.com>
Cc: linux-gpio@vger.kernel.org
Cc: Geert Uytterhoeven <geert+renesas@glider.be>
Cc: Linus Walleij <linus.walleij@linaro.org>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
According to Whiskey Cove PMIC spec, bit 7 of GPIOIRQ0_REG belongs to
battery IO. So we should skip this bit when checking for GPIO IRQ pending
status. Otherwise, wcove_gpio_irq_handler() might go into the infinite
loop until IRQ "pending" status becomes 0. This patch fixes this issue.
Signed-off-by: Kuppuswamy Sathyanarayanan <sathyanarayanan.kuppuswamy@linux.intel.com>
Acked-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Acked-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Crystal Cove and Whiskey Cove are two different PMICs which are
installed on Intel Atom SoC based platforms.
Moreover there are two independent drivers that by some reason were
supposed (*) to get into one kernel module.
Fix the mess by clarifying Kconfig option for Crystal Cove and split
Whiskey Cove out of it.
(*) It looks like the configuration was never tested with
INTEL_SOC_PMIC=n. The line in Makefile is actually wrong.
Cc: "Rafael J. Wysocki" <rjw@rjwysocki.net> (supporter:ACPI)
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Acked-by: Zhang Rui <rui.zhang@intel.com>
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
The TCA9554 doesn't work with the pcf857x driver, trying to change the direction
gives a NAK bailout error.
TCA9554 is similar to the PCA9554, thus change the driver.
Signed-off-by: Anders Darander <anders@chargestorm.se>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
The logic to check if the pin is an input or output whilst testing if we
need to read the register value from the hardware or not is currently
inverted. Remove the erroneous not from the if statement.
Fixes: 11598d1740 ("gpio: arizona: Correct handling for reading input GPIOs")
Signed-off-by: Charles Keepax <ckeepax@opensource.wolfsonmicro.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Whiskey cove PMIC has three GPIO banks with total number of 13 GPIO
pins. But when checking for the pending status, for_each_set_bit() uses
bit width of 7 and hence it only checks the status for first 7 GPIO pins
missing to check/clear the status of rest of the GPIO pins. This patch
fixes this issue.
Signed-off-by: Kuppuswamy Sathyanarayanan <sathyanarayanan.kuppuswamy@linux.intel.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Commit 67809b974a ("GPIO: gpio-dwapb: Change readl&writel to
dwapb_read&dwapb_write") missed this readl_relaxed() usage, I'm not
sure the reason, maybe for performance reason? But if we do care
the performance, we could use the relaxed io in dwapb_read and
dwapb_write.
Signed-off-by: Jisheng Zhang <jszhang@marvell.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
As per the datasheet, manage the IO and value states to implement
open-source/open-drain, but do this by falling back to gpiolib's
emulation.
This commit simply makes the behaviour explicit for clarity, rather than
relying on the implicit return of -ENOTSUPP to trigger the emulation.
Signed-off-by: Andrew Jeffery <andrew@aj.id.au>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Each GPIO in the Aspeed GPIO controller can choose one of four input
debounce states: to disable debouncing for an input, or select from one
of three programmable debounce timer values. Each GPIO in a
four-bank-set is assigned one bit in each of two debounce configuration
registers dedicated to the set, and selects a debounce state by
configuring the two bits to select one of the four options.
The limitation on debounce timer values is managed by mapping offsets
onto a configured timer value and keeping count of the number of users
a timer has. Timer values are configured on a first-come-first-served
basis.
A small twist in the hardware design is that the debounce configuration
register numbering is reversed with respect to the binary representation
of the debounce timer of interest (i.e. debounce register 1 represents
bit 1, and debounce register 2 represents bit 0 of the timer numbering).
Tested on an AST2500EVB with additional inspection under QEMU's
romulus-bmc machine.
Signed-off-by: Andrew Jeffery <andrew@aj.id.au>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Armada 370/XP devices can 'blink' GPIO lines with a configurable on
and off period. This can be modelled as a PWM.
However, there are only two sets of PWM configuration registers for
all the GPIO lines. This driver simply allows a single GPIO line per
GPIO chip of 32 lines to be used as a PWM. Attempts to use more return
EBUSY.
Due to the interleaving of registers it is not simple to separate the
PWM driver from the GPIO driver. Thus the GPIO driver has been
extended with a PWM driver.
Signed-off-by: Andrew Lunn <andrew@lunn.ch>
URL: https://patchwork.ozlabs.org/patch/427287/
URL: https://patchwork.ozlabs.org/patch/427295/
[Ralph Sennhauser:
* Port forward
* Merge PWM portion into gpio-mvebu.c
* Switch to atomic PWM API
* Add new compatible string marvell,armada-370-xp-gpio
* Update and merge documentation patch
* Update MAINTAINERS]
Signed-off-by: Ralph Sennhauser <ralph.sennhauser@gmail.com>
Tested-by: Andrew Lunn <andrew@lunn.ch>
Acked-by: Thierry Reding <thierry.reding@gmail.com>
Acked-by: Rob Herring <robh@kernel.org>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
When the kernel is running in secure boot mode, we lock down the kernel to
prevent userspace from modifying the running kernel image. Whilst this
includes prohibiting access to things like /dev/mem, it must also prevent
access by means of configuring driver modules in such a way as to cause a
device to access or modify the kernel image.
To this end, annotate module_param* statements that refer to hardware
configuration and indicate for future reference what type of parameter they
specify. The parameter parser in the core sees this information and can
skip such parameters with an error message if the kernel is locked down.
The module initialisation then runs as normal, but just sees whatever the
default values for those parameters is.
Note that we do still need to do the module initialisation because some
drivers have viable defaults set in case parameters aren't specified and
some drivers support automatic configuration (e.g. PNP or PCI) in addition
to manually coded parameters.
This patch annotates drivers in drivers/gpio/.
Suggested-by: Alan Cox <gnomes@lxorguk.ukuu.org.uk>
Signed-off-by: David Howells <dhowells@redhat.com>
Acked-by: William Breathitt Gray <vilhelm.gray@gmail.com>
Acked-by: Linus Walleij <linus.walleij@linaro.org>
cc: Alexandre Courbot <gnurou@gmail.com>
cc: linux-gpio@vger.kernel.org
Interrupt numbers are never negative, zero serves as the special invalid
value.
Signed-off-by: Thierry Reding <treding@nvidia.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Add F71889A GPIO support.
Fintek F71889A is a SuperIO. It contains HWMON/GPIO/Serial Ports.
Datasheet:
http://www.alldatasheet.com/datasheet-pdf/pdf/459076/FINTEK/F71889A.html
Its virtually identical to the F71889F superio as far as gpios go.
One oddity is GPIO2 at index 0xD0; the datasheet only lists gpio's 7-5,
but it logically seems that it should continue down to 0. I'm not sure
if the driver can handle gpios that are shifted away from index 0 as it
currently stands.
Signed-off-by: Marty Plummer <netz.kernel@gmail.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Currently, the GPIO interface is said to Open Drain if it is Single
Ended and active LOW. Similarly, it is said as Open Source if it is
Single Ended and active HIGH.
The active HIGH/LOW is used in the interface for setting the pin
state to HIGH or LOW when enabling/disabling the interface.
In Open Drain interface, pin is set to HIGH by putting pin in
high impedance and LOW by driving to the LOW.
In Open Source interface, pin is set to HIGH by driving pin to
HIGH and set to LOW by putting pin in high impedance.
With above, the Open Drain/Source is unrelated to the active LOW/HIGH
in interface. There is interface where the enable/disable of interface
is ether active LOW or HIGH but it is Open Drain type.
Hence decouple the Open Drain with Single Ended + Active LOW and
Open Source with Single Ended + Active HIGH.
Adding different flag for the Open Drain/Open Source which is valid
only when Single ended flag is enabled.
Signed-off-by: Laxman Dewangan <ldewangan@nvidia.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
The GPIO register is cached since all the configuration resides within
it, however, this means for input GPIOs the driver will not return the
actual state but the last value written to the register cache.
To correct this in the case of reading an input GPIO resume the CODEC
and drop the cache for the input register to ensure an actual hardware
read takes place.
Signed-off-by: Charles Keepax <ckeepax@opensource.wolfsonmicro.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
If, while locating GPIOs by name, we get probe deferral, we should
immediately report it to caller rather than trying to fall back to parsing
unnamed GPIOs from _CRS block.
Cc: stable@vger.kernel.org
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Acked-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Acked-and-Tested-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
On Bay Trail / Cherry Trail systems with a LID switch, the LID switch is
often connect to a gpioint handled by an _IAE event handler.
Before this commit such systems would not wake up when opening the lid,
requiring the powerbutton to be pressed after opening the lid to wakeup.
Note that Bay Trail / Cherry Trail systems use suspend-to-idle, so
the interrupts are generated anyway on those lines on lid switch changes,
but they are treated by the IRQ subsystem as spurious while suspended if
not marked as wakeup IRQs.
This commit calls enable_irq_wake() for _IAE GpioInts with a valid
event handler which have their Wake flag set. This fixes such systems
not waking up when opening the lid.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Acked-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>
The 104-idi-48 gpio driver currently implements an irq_chip for handling
interrupts; due to how irq_chip handling is done, it's necessary for the
irq_chip methods to be invoked from hardirq context, even on a a
real-time kernel. Because the spinlock_t type becomes a "sleeping"
spinlock w/ RT kernels, it is not suitable to be used with irq_chips.
A quick audit of the operations under the lock reveal that they do only
minimal, bounded work, and are therefore safe to do under a raw spinlock.
Signed-off-by: Julia Cartwright <julia@ni.com>
Acked-by: William Breathitt Gray <vilhelm.gray@gmail.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
The pci-idio-16 gpio driver currently implements an irq_chip for handling
interrupts; due to how irq_chip handling is done, it's necessary for the
irq_chip methods to be invoked from hardirq context, even on a a
real-time kernel. Because the spinlock_t type becomes a "sleeping"
spinlock w/ RT kernels, it is not suitable to be used with irq_chips.
A quick audit of the operations under the lock reveal that they do only
minimal, bounded work, and are therefore safe to do under a raw spinlock.
Signed-off-by: Julia Cartwright <julia@ni.com>
Acked-by: William Breathitt Gray <vilhelm.gray@gmail.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
The 104-idio-16 gpio driver currently implements an irq_chip for handling
interrupts; due to how irq_chip handling is done, it's necessary for the
irq_chip methods to be invoked from hardirq context, even on a a
real-time kernel. Because the spinlock_t type becomes a "sleeping"
spinlock w/ RT kernels, it is not suitable to be used with irq_chips.
A quick audit of the operations under the lock reveal that they do only
minimal, bounded work, and are therefore safe to do under a raw spinlock.
Signed-off-by: Julia Cartwright <julia@ni.com>
Acked-by: William Breathitt Gray <vilhelm.gray@gmail.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Add support for mapping gpio-reg gpios to interrupts. This may be a
non-linear mapping - some gpios in the register may not even have
corresponding interrupts associated with them, so we need to pass an
array.
Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Add a simple, generic, single register fixed-direction GPIO driver.
This is able to support a single register with a mixture of inputs
and outputs.
This is different from gpio-mmio and gpio-74xx-mmio:
* gpio-mmio doesn't allow a fixed direction, it assumes there is always
a direction register.
* gpio-74xx-mmio only supports all-in or all-out setups
* gpio-74xx-mmio is DT only, this needs to support legacy too
* they don't double-read when getting the GPIO value, as required by
some implementations that this driver supports
* we need to always do 32-bit reads, which bgpio doesn't guarantee
* the current output state may not be readable from the hardware
register - reading may reflect input status but not output status.
Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Allow gpiolib to read back the current IO direction configuration by
implementing the .get_direction callback. This, in part, allows
debugfs to report the complete true hardware state rather than the
software state.
Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Use IO accessors to access the SA1100 registers rather than accessing
them directly.
Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Use sa11x0_gpio_set_wake() to set the PWER register, as provided by
Dmitry some time back.
Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
