Avoids gpiolib assumptions on initial pin direction, allowing user to observe
power-on settings.
Signed-off-by: NVincent Pelletier <plr.vincent@gmail.com>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

NBANK() macro assumes that ngpios is a multiple of 8(BANK_SZ) and
hence results in 0 banks for PCA9536 which has just 4 gpios. This is
wrong as PCA9356 has 1 bank with 4 gpios. This results in uninitialized
PCA953X_INVERT register. Fix this by using DIV_ROUND_UP macro in
NBANK().

Cc: stable@vger.kernel.org
Signed-off-by: NVignesh R <vigneshr@ti.com>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

This patch adds support for the Western Digital's
MyBook Live memory-mapped GPIO controllers.

The GPIOs will be supported by the generic driver
for memory-mapped GPIO controllers.
Signed-off-by: NChristian Lamparter <chunkeey@googlemail.com>
Acked-by: NAlexandre Courbot <acourbot@nvidia.com>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

This patch adds support for defining memory-mapped GPIOs which
are compatible with the existing gpio-mmio interface. The generic
library provides support for many memory-mapped GPIO controllers
that are found in various on-board FPGA and ASIC solutions that
are used to control board's switches, LEDs, chip-selects,
Ethernet/USB PHY power, etc.

For setting GPIOs there are three configurations:
	1. single input/output register resource (named "dat"),
	2. set/clear pair (named "set" and "clr"),
	3. single output register resource and single input resource
	   ("set" and dat").

The configuration is detected by which resources are present.
For the single output register, this drives a 1 by setting a bit
and a zero by clearing a bit.  For the set clr pair, this drives
a 1 by setting a bit in the set register and clears it by setting
a bit in the clear register.

For setting the GPIO direction, there are three configurations:
	a. simple bidirectional GPIOs that requires no configuration.
	b. an output direction register (named "dirout")
	   where a 1 bit indicates the GPIO is an output.
	c. an input direction register (named "dirin")
	   where a 1 bit indicates the GPIO is an input.
Reviewed-by: NAndy Shevchenko <andy.shevchenko@gmail.com>
Signed-off-by: NÁlvaro Fernández Rojas <noltari@gmail.com>
Signed-off-by: NChristian Lamparter <chunkeey@googlemail.com>
Acked-by: NAlexandre Courbot <acourbot@nvidia.com>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

The Kconfig currently controlling compilation of this code is:

 config GPIO_LPC18XX
       bool "NXP LPC18XX/43XX GPIO support"

...meaning that it currently is not being built as a module by anyone.

When targeting orphaned modular code in non-modular drivers, this
came up.  Joachim indicated that the driver was actually meant to
be tristate but ended up bool by accident.  So here we make it
tristate instead of removing the modular code that was essentially
orphaned.

Cc: Joachim Eastwood <manabian@gmail.com>
Acked-by: NJoachim Eastwood <manabian@gmail.com>
Cc: Linus Walleij <linus.walleij@linaro.org>
Cc: Alexandre Courbot <gnurou@gmail.com>
Cc: linux-gpio@vger.kernel.org
Signed-off-by: NPaul Gortmaker <paul.gortmaker@windriver.com>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

Add ACPI support for GPIO controller on Broadcom Vulcan ARM64.
ACPI ID for this device is BRCM9006.
Signed-off-by: NKamlakant Patel <kamlakant.patel@broadcom.com>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

irq_alloc_descs need not be called in case of Vulcan, where we use
a dynamic IRQ range for GPIO interrupt numbers.

Update code not to call irq_alloc_descs and pass 0 as irq_base in
case of Vulcan.
Signed-off-by: NKamlakant Patel <kamlakant.patel@broadcom.com>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

Since board support for the CLPS711X platform was removed,
remove the board support from the driver.
Signed-off-by: NAlexander Shiyan <shc_work@mail.ru>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

This patch changes the compatibility string to match with the smallest
supported chip (EP7209). Since the DT-support for this CPU is not yet
announced, this change is safe.
Signed-off-by: NAlexander Shiyan <shc_work@mail.ru>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

This patch changes the compatibility string to match with the smallest
supported chip (EP7209). Since the DT-support for this CPU is not yet
announced, this change is safe.
Signed-off-by: NAlexander Shiyan <shc_work@mail.ru>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

Add function to set multiple GPIO of the same chip at the same time
and register it
Signed-off-by: NIban Rodriguez <irodriguez@cemitec.com>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

The commit 9b8e3ec3 ("gpio: pca953x: Use correct u16 value for register
word write") fixed regression in pca953x_write_regs(). At the same time the
solution introduced a sparse warning:

drivers/gpio/gpio-pca953x.c:168:39: warning: incorrect type in argument 3 (different base types)
drivers/gpio/gpio-pca953x.c:168:39:    expected unsigned short [unsigned] [usertype] value
drivers/gpio/gpio-pca953x.c:168:39:    got restricted __le16 [usertype] <noident>

Fix the code by enforcing the type of i2c_smbus_write_word_data() parameter.

Cc: Yong Li <sdliyong@gmail.com>
Cc: Phil Reid <preid@electromag.com.au>
Signed-off-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

There are few redundant assignments of ret variable which is updated anyway.
Remove them for good.

While here, correct indentation of the constant definition and remove one empty
line.
Signed-off-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

The reset values for all the PCF lines are high and hence on
shutdown we should drive all the lines high in order to
bring it to the reset state.

This is actually required since PCF doesn't have a reset
line and even after warm reset (by invoking "reboot" in
prompt) the PCF lines maintains it's previous programmed
state. This becomes a problem if the boards are designed to
work with the default initial state.

DRA7XX_evm uses PCF8575 and one of the PCF output lines
feeds to MMC/SD VDD and this line should be driven high in order
for the MMC/SD to be detected.  This line is modelled as
regulator and the hsmmc driver takes care of enabling and
disabling it. In the case of 'reboot', during shutdown path
as part of it's cleanup process the hsmmc driver disables
this regulator. This makes MMC *boot* not functional.

Fix it by driving all the pcf lines high.

This patch was sent long back
(https://patchwork.ozlabs.org/patch/420382/)
But there was a concern that contention might occur if the
PCF shutdown handler is invoked before the shutdown handler
of the PCF's consumers. In that case PCF shutdown handler can't
drive all the pcf lines high without knowing if the PCF
consumers are still active.

However commit 52cdbdd4 ("driver core: correct device's
shutdown order") will make sure shutdown handler of PCF's
consumers are invoked before invoking the shutdown
handler of PCF. So it should be safe to merge this now.
Signed-off-by: NKishon Vijay Abraham I <kishon@ti.com>
Signed-off-by: NSekhar Nori <nsekhar@ti.com>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

A platform_driver need not set an owner since it will be populated
by platform_driver_register().
Likewise for mcb_driver (gpio-menz127.c).
Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>
Acked-by: NCharles Keepax <ckeepax@opensource.wolfsonmicro.com>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

As the comment block of of_parse_phandle_with_fixed_args() says,
the caller is responsible to call of_node_put() on the returned
node when done.
Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

The MAX77620 have a GPIO pins which can act as open drain or
push pull mode. Implement support for controlling this from GPIO
descriptor tables or other hardware descriptions such as
device tree by implementing the .set_single_ended() callback.
Signed-off-by: NLaxman Dewangan <ldewangan@nvidia.com>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

The GPIO sub modules of MAX77620 offers to configure the GPIO
interrupt trigger level as RISING and FALLING edge.

Pass this information to regmap-irg when registering for GPIO
interrupts.
Signed-off-by: NLaxman Dewangan <ldewangan@nvidia.com>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

This implements the .get_direction() callback for the STMPE
expander GPIO.

Cc: Patrice Chotard <patrice.chotard@st.com>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

TI PCA9536 is 4-Bit I2C GPIO expander without interrupt support[1].
Add support for the same.

[1] TRM: http://www.ti.com/lit/ds/symlink/pca9536.pdfSigned-off-by: NVignesh R <vigneshr@ti.com>
Acked-by: NRob Herring <robh@kernel.org>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

MAXIM Semiconductor's PMIC, MAX77620/MAX20024 has 8 GPIO
pins. It also supports interrupts from these pins.

Add GPIO driver for these pins to control via GPIO APIs.
Signed-off-by: NLaxman Dewangan <ldewangan@nvidia.com>
Reviewed-by: NLinus Walleij <linus.walleij@linaro.org>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

When adding the gpiochip, the GPIO HW drivers' callback get_direction()
could get called in atomic context. Some of the GPIO HW drivers may
sleep when accessing the register.

Move the lock before initializing the descriptors.
Reported-by: NLaxman Dewangan <ldewangan@nvidia.com>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

In fdeb8e15
("gpio: reflect base and ngpio into gpio_device")
assumed that GPIO descriptors are either valid or error
pointers, but gpiod_get_[index_]optional() actually return
NULL descriptors and then all subsequent calls should just
bail out.

Cc: stable@vger.kernel.org
Cc: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
Cc: Florian Fainelli <f.fainelli@gmail.com>
Cc: Andrew Lunn <andrew@lunn.ch>
Fixes: fdeb8e15 ("gpio: reflect base and ngpio into gpio_device")
Reported-by: NUwe Kleine-König <u.kleine-koenig@pengutronix.de>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

If we're using the compatible ioctl() we need to handle the
argument pointer in a special way or there will be trouble.

Fixes: 3c702e99 ("gpio: add a userspace chardev ABI for GPIOs")
Reported-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>
Reviewed-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

As irqchip and gpiochip functions are orthogonal, the IRQ
set-up or something else can have changed the direction of
the GPIO line from what the GPIO descriptor knows when we
get into gpiochip_lock_as_irq(). Make sure to re-read the
direction setting if we have the .get_direction() callback
enabled for the chip.

Else we get problems like this:

iio iio:device2: interrupts on the rising edge
gpio gpiochip2: (8012e080.gpio): gpiochip_lock_as_irq:
  tried to flag a GPIO set as output for IRQ
gpio gpiochip2: (8012e080.gpio): unable to lock HW IRQ 0 for IRQ
genirq: Failed to request resources for l3g4200d-trigger
  (irq 111) on irqchip nmk1-32-63
iio iio:device2: failed to request trigger IRQ.
st-gyro-i2c: probe of 2-0068 failed with error -22

Fixes: 72d32000 ("gpio: set up initial state from .get_direction()")
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

The "to_irq" functionality is broken inside this driver since commit
76ba59f8 ("genirq: Add irq_domain-aware core IRQ handler").

The addition of the new lpc32xx irqchip driver in 4.7, fixed the
lpc32xx platform interrupt issue.

When switching to the new lpc32xx irqchip driver, a warning appear
in the lpc32xx gpio driver: warning: "NR_IRQS" redefined.

To remove this warning (temporary solution), this patch
disables the broken "to_irq" mapping functionality support.
Signed-off-by: NSylvain Lemieux <slemieux@tycoint.com>
Acked-by: NVladimir Zapolskiy <vz@mleia.com>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

Most users of IS_ERR_VALUE() in the kernel are wrong, as they
pass an 'int' into a function that takes an 'unsigned long'
argument. This happens to work because the type is sign-extended
on 64-bit architectures before it gets converted into an
unsigned type.

However, anything that passes an 'unsigned short' or 'unsigned int'
argument into IS_ERR_VALUE() is guaranteed to be broken, as are
8-bit integers and types that are wider than 'unsigned long'.

Andrzej Hajda has already fixed a lot of the worst abusers that
were causing actual bugs, but it would be nice to prevent any
users that are not passing 'unsigned long' arguments.

This patch changes all users of IS_ERR_VALUE() that I could find
on 32-bit ARM randconfig builds and x86 allmodconfig. For the
moment, this doesn't change the definition of IS_ERR_VALUE()
because there are probably still architecture specific users
elsewhere.

Almost all the warnings I got are for files that are better off
using 'if (err)' or 'if (err < 0)'.
The only legitimate user I could find that we get a warning for
is the (32-bit only) freescale fman driver, so I did not remove
the IS_ERR_VALUE() there but changed the type to 'unsigned long'.
For 9pfs, I just worked around one user whose calling conventions
are so obscure that I did not dare change the behavior.

I was using this definition for testing:

 #define IS_ERR_VALUE(x) ((unsigned long*)NULL == (typeof (x)*)NULL && \
       unlikely((unsigned long long)(x) >= (unsigned long long)(typeof(x))-MAX_ERRNO))

which ends up making all 16-bit or wider types work correctly with
the most plausible interpretation of what IS_ERR_VALUE() was supposed
to return according to its users, but also causes a compile-time
warning for any users that do not pass an 'unsigned long' argument.

I suggested this approach earlier this year, but back then we ended
up deciding to just fix the users that are obviously broken. After
the initial warning that caused me to get involved in the discussion
(fs/gfs2/dir.c) showed up again in the mainline kernel, Linus
asked me to send the whole thing again.

[ Updated the 9p parts as per Al Viro  - Linus ]
Signed-off-by: NArnd Bergmann <arnd@arndb.de>
Cc: Andrzej Hajda <a.hajda@samsung.com>
Cc: Andrew Morton <akpm@linux-foundation.org>
Link: https://lkml.org/lkml/2016/1/7/363
Link: https://lkml.org/lkml/2016/5/27/486
Acked-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> # For nvmem part
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

The Kconfig currently controlling compilation of this code is:

drivers/gpio/Kconfig:config GPIO_ZEVIO
drivers/gpio/Kconfig:   bool "LSI ZEVIO SoC memory mapped GPIOs"

...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_platform_driver() uses the same init level priority as
builtin_platform_driver() the init ordering remains unchanged with
this commit.

Also note that MODULE_DEVICE_TABLE is a no-op for non-modular code.

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: Fabian Vogt <fabian@ritter-vogt.de>
Cc: linux-gpio@vger.kernel.org
Signed-off-by: NPaul Gortmaker <paul.gortmaker@windriver.com>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

The Kconfig currently controlling compilation of this code is:

drivers/gpio/Kconfig:config GPIO_TIMBERDALE
drivers/gpio/Kconfig:   bool "Support for timberdale GPIO IP"

...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_platform_driver() uses the same init level priority as
builtin_platform_driver() the init ordering remains unchanged with
this commit.

We also delete the MODULE_LICENSE tag etc. since all that information
was (or is now) contained at the top of the file in the comments.

Cc: Linus Walleij <linus.walleij@linaro.org>
Cc: Alexandre Courbot <gnurou@gmail.com>
Cc: linux-gpio@vger.kernel.org
Signed-off-by: NPaul Gortmaker <paul.gortmaker@windriver.com>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

The Kconfig currently controlling compilation of this code is:

drivers/gpio/Kconfig:config GPIO_STMPE
drivers/gpio/Kconfig:   bool "STMPE GPIOs"

...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.

Curiously, this driver was using subsys_initcall since day one, so
we don't have the "normal" module_init replacement in this change
like we've done in other similar driver updates.

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: Rabin Vincent <rabin.vincent@stericsson.com>
Cc: linux-gpio@vger.kernel.org
Signed-off-by: NPaul Gortmaker <paul.gortmaker@windriver.com>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

The Kconfig currently controlling compilation of this code is:

drivers/gpio/Kconfig:config GPIO_SODAVILLE
drivers/gpio/Kconfig:   bool "Intel Sodaville GPIO 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_pci_driver() uses the same init level as the
builtin_pci_driver() does, there is no init ordering change
caused by this commit.

We don't replace module.h with init.h since the file already has that.

We also delete the MODULE_LICENSE tag etc. since all that information
was (or is now) contained at the top of the file in the comments.

Cc: Hans J. Koch <hjk@linutronix.de>
Cc: Linus Walleij <linus.walleij@linaro.org>
Cc: Alexandre Courbot <gnurou@gmail.com>
Cc: linux-gpio@vger.kernel.org
Signed-off-by: NPaul Gortmaker <paul.gortmaker@windriver.com>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

This patch enables DWAPB GPIO controller support on X-Gene
platforms in ACPI boot mode.
Signed-off-by: NDuc Dang <dhdang@apm.com>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

Make it possible to name the producer side of a GPIO line using
a "gpio-line-names" property array, modeled on the
"clock-output-names" property from the clock bindings.

This naming is especially useful for:

- Debugging: lines are named after function, not just opaque
  offset numbers.

- Exploration: systems where some or all GPIO lines are available
  to end users, such as prototyping, one-off's "makerspace usecases"
  users are helped by the names of the GPIO lines when tinkering.
  This usecase has been surfacing recently.

The gpio-line-names attribute is completely optional.

Example output from lsgpio on a patched Snowball tree:

GPIO chip: gpiochip6, "8000e180.gpio", 32 GPIO lines
        line  0: unnamed unused
        line  1: "AP_GPIO161" "extkb3" [kernel]
        line  2: "AP_GPIO162" "extkb4" [kernel]
        line  3: "ACCELEROMETER_INT1_RDY" unused [kernel]
        line  4: "ACCELEROMETER_INT2" unused
        line  5: "MAG_DRDY" unused [kernel]
        line  6: "GYRO_DRDY" unused [kernel]
        line  7: "RSTn_MLC" unused
        line  8: "RSTn_SLC" unused
        line  9: "GYRO_INT" unused
        line 10: "UART_WAKE" unused
        line 11: "GBF_RESET" unused
        line 12: unnamed unused

Cc: Grant Likely <grant.likely@linaro.org>
Cc: Amit Kucheria <amit.kucheria@linaro.org>
Cc: David Mandala <david.mandala@linaro.org>
Cc: Lee Campbell <leecam@google.com>
Cc: devicetree@vger.kernel.org
Acked-by: NRob Herring <robh@kernel.org>
Reviewed-by: NMichael Welling <mwelling@ieee.org>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

The WinSystems WS16C48 communicates via the ISA bus. As such, it is more
appropriate to use the ISA bus driver over the platform driver to
control the WinSystems WS16C48 GPIO driver.

This patch also adds support for multiple devices via the base and irq
module array parameters. Each element of the base array corresponds to a
discrete device; each element of the irq array corresponds to the
respective device addressed in the respective base array element.
Acked-by: NLinus Walleij <linus.walleij@linaro.org>
Cc: Alexandre Courbot <gnurou@gmail.com>
Signed-off-by: NWilliam Breathitt Gray <vilhelm.gray@gmail.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

The ACCES 104-IDIO-16 series communicates via the ISA bus. As such, it
is more appropriate to use the ISA bus driver over the platform driver
to control the ACCES 104-IDIO-16 GPIO driver.

This patch also adds support for multiple devices via the base and irq
module array parameters. Each element of the base array corresponds to a
discrete device; each element of the irq array corresponds to the
respective device addressed in the respective base array element.
Acked-by: NLinus Walleij <linus.walleij@linaro.org>
Cc: Alexandre Courbot <gnurou@gmail.com>
Signed-off-by: NWilliam Breathitt Gray <vilhelm.gray@gmail.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

The ACCES 104-IDI-48 series communicates via the ISA bus. As such, it
is more appropriate to use the ISA bus driver over the platform driver
to control the ACCES 104-IDI-48 GPIO driver.

This patch also adds support for multiple devices via the base and irq
module array parameters. Each element of the base array corresponds to a
discrete device; each element of the irq array corresponds to the
respective device addressed in the respective base array element.
Acked-by: NLinus Walleij <linus.walleij@linaro.org>
Cc: Alexandre Courbot <gnurou@gmail.com>
Signed-off-by: NWilliam Breathitt Gray <vilhelm.gray@gmail.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

The ACCES 104-DIO-48E series communicates via the ISA bus. As such, it
is more appropriate to use the ISA bus driver over the platform driver
to control the ACCES 104-DIO-48E GPIO driver.

This patch also adds support for multiple devices via the base and irq
module array parameters. Each element of the base array corresponds to a
discrete device; each element of the irq array corresponds to the
respective device addressed in the respective base array element.
Acked-by: NLinus Walleij <linus.walleij@linaro.org>
Cc: Alexandre Courbot <gnurou@gmail.com>
Signed-off-by: NWilliam Breathitt Gray <vilhelm.gray@gmail.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

If a translation returns zero, that means NO_IRQ, so we
should return an error since the function is documented to
return a negative code on error.
Reported-by: NGeert Uytterhoeven <geert@linux-m68k.org>
Acked-by: NGeert Uytterhoeven <geert@linux-m68k.org>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

This implements the .get_direction() callback for the xgene GPIO
controller.

Cc: Duc Dang <dhdang@apm.com>
Cc: Feng Kan <fkan@apm.com>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

This patch enables ACPI support for X-Gene GFC GPIO driver.
Signed-off-by: NDuc Dang <dhdang@apm.com>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>