Fix memory leak and sleep-while-atomic in gpiochip_remove.

The memory leak was introduced by afa82fab ("gpio / ACPI: Move event
handling registration to gpiolib irqchip helpers") that moved the
release of acpi interrupt resources to gpiochip_irqchip_remove, but by
then the resources are no longer accessible as the acpi_gpio_chip has
already been freed by acpi_gpiochip_remove.

Note that this also fixes a few potential sleep-while-atomics, which has
been around since 14250520 ("gpio: add IRQ chip helpers in gpiolib")
when the call to gpiochip_irqchip_remove while holding a spinlock was
added (a couple of irq-domain paths can end up grabbing mutexes).

Fixes: afa82fab ("gpio / ACPI: Move event handling registration to
gpiolib irqchip helpers")
Fixes: 14250520 ("gpio: add IRQ chip helpers in gpiolib")
Cc: stable <stable@vger.kernel.org>
Signed-off-by: NJohan Hovold <johan@kernel.org>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

Clean up gpiochip_add error handling.
Signed-off-by: NJohan Hovold <johan@kernel.org>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

Fix potential corruption of gpio-chip list due to failure to remove the
chip from the list before returning in gpiochip_add error path.

The chip could be long gone when the global list is next traversed,
something which could lead to a null-pointer dereference. In the best
case (chip not deallocated) we are just leaking the gpio range.

Fixes: 14e85c0e ("gpio: remove gpio_descs global array")
Signed-off-by: NJohan Hovold <johan@kernel.org>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

Memory allocated and references taken by of_gpiochip_add and
acpi_gpiochip_add were never released on errors in gpiochip_add (e.g.
failure to find free gpio range).

Fixes: 391c970c ("of/gpio: add default of_xlate function if device
has a node pointer")
Fixes: 664e3e5a ("gpio / ACPI: register to ACPI events
automatically")
Cc: stable <stable@vger.kernel.org>
Signed-off-by: NJohan Hovold <johan@kernel.org>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

The CrystalCove GPIO chip has can_sleep set so its demultiplexed irqs
will have IRQ_NESTED_THREAD flag set, thus we should use the nested
version handle_nested_irq in CrystalCove's irq handler instead of
handle_generic_irq, or the following warning will be hit and the
functionality is lost:

[ 4089.639554] Hardware name: ASUSTeK COMPUTER INC. T100TA/T100TA, BIOS T100TA.313 08/13/2014
[ 4089.639564]  00000002 00000000 c24fbdf4 c16e0257 c24fbe38 c24fbe28 c105390c c18ec480
[ 4089.639596]  c24fbe54 00000048 c18f8e3b 00000295 c10a60fc 00000295 c10a60fc f4464540
[ 4089.639626]  f446459c c278ad40 c24fbe40 c1053974 00000009 c24fbe38 c18ec480 c24fbe54
[ 4089.639656] Call Trace:
[ 4089.639685]  [<c16e0257>] dump_stack+0x41/0x52
[ 4089.639707]  [<c105390c>] warn_slowpath_common+0x8c/0xc0
[ 4089.639727]  [<c10a60fc>] ? irq_nested_primary_handler+0x2c/0x30
[ 4089.639744]  [<c10a60fc>] ? irq_nested_primary_handler+0x2c/0x30
[ 4089.639763]  [<c1053974>] warn_slowpath_fmt+0x34/0x40
[ 4089.639781]  [<c10a60fc>] irq_nested_primary_handler+0x2c/0x30
[ 4089.639800]  [<c10a5c56>] handle_irq_event_percpu+0x76/0x190
[ 4089.639818]  [<c1461570>] ? regmap_format_10_14_write+0x30/0x30
[ 4089.639836]  [<c1464f4c>] ? _regmap_bus_raw_write+0x4c/0x70
[ 4089.639854]  [<c10a5da1>] handle_irq_event+0x31/0x50
[ 4089.639872]  [<c10a83eb>] handle_simple_irq+0x4b/0x70
[ 4089.639889]  [<c10a5384>] generic_handle_irq+0x24/0x40
[ 4089.639908]  [<c1366d87>] crystalcove_gpio_irq_handler+0xa7/0xc0
[ 4089.639927]  [<c10a85a7>] handle_nested_irq+0x77/0x190
[ 4089.639947]  [<c1469801>] regmap_irq_thread+0x1b1/0x360
[ 4089.639966]  [<c10a6ae8>] irq_thread_fn+0x18/0x30
[ 4089.639983]  [<c10a6906>] irq_thread+0xf6/0x110
[ 4089.640001]  [<c10a6ad0>] ? irq_finalize_oneshot.part.30+0x1b0/0x1b0
[ 4089.640019]  [<c10a6b50>] ? irq_forced_thread_fn+0x50/0x50
[ 4089.640037]  [<c10a6810>] ? irq_thread_check_affinity+0xc0/0xc0
[ 4089.640054]  [<c106f389>] kthread+0xa9/0xc0
[ 4089.640074]  [<c16e6401>] ret_from_kernel_thread+0x21/0x30
[ 4089.640091]  [<c106f2e0>] ? kthread_create_on_node+0x110/0x110
[ 4089.640105] ---[ end trace dca7946ad31eba7d ]---

Buglink: https://bugzilla.kernel.org/show_bug.cgi?id=90521Reported-and-tested-by: NBrian Loften <bloften80@gmail.com>
Cc: Stable <stable@vger.kernel.org>
Signed-off-by: NAaron Lu <aaron.lu@intel.com>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

The driver depends on the chip.of_node being present to compile,
which is the case on some target platforms but not others.
Instead, rely on chip.dev->of_node to be used, as struct device
always has an of_node in place.

Cc: Alexander Stein <alexander.stein@systec-electronic.com>
Suggested-by: NLinus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

After commit b2b49ccb (PM: Kconfig: Set PM_RUNTIME if PM_SLEEP is
selected) PM_RUNTIME is always set if PM is set, so #ifdef blocks
depending on CONFIG_PM_RUNTIME may now be changed to depend on
CONFIG_PM.

Replace CONFIG_PM_RUNTIME with CONFIG_PM in drivers/gpio/gpio-omap.c.
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
Acked-by: NAlexandre Courbot <acourbot@nvidia.com>
Acked-by: NJavier Martinez Canillas <javier@dowhile0.org>
Reviewed-by: NLinus Walleij <linus.walleij@linaro.org>

The SET_PM_RUNTIME_PM_OPS() and SET_RUNTIME_PM_OPS() macros are
identical except that one of them is not empty for CONFIG_PM set,
while the other one is not empty for CONFIG_PM_RUNTIME set,
respectively.

However, after commit b2b49ccb (PM: Kconfig: Set PM_RUNTIME if
PM_SLEEP is selected) PM_RUNTIME is always set if PM is set, so one
of these macros is now redundant.

For this reason, replace SET_PM_RUNTIME_PM_OPS() with
SET_RUNTIME_PM_OPS() everywhere and redefine the SET_PM_RUNTIME_PM_OPS
symbol as SET_RUNTIME_PM_OPS in case new code is starting to use the
macro being removed here.
Reviewed-by: NUlf Hansson <ulf.hansson@linaro.org>
Acked-by: NKevin Hilman <khilman@linaro.org>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

Gpio-ranges property is useful to represent which GPIOs correspond
to which pins on which pin controllers. But there may be some gpios
without pinctrl operation. So check whether gpio-ranges property
exists in device node first.
Signed-off-by: NYunlei He <heyunlei@huawei.com>
Signed-off-by: NXinwei Kong <kong.kongxinwei@hisilicon.com>
Signed-off-by: NHaojian Zhuang <haojian.zhuang@linaro.org>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

Default is active low, but if property is specified in DT set INTPOL flag.
Signed-off-by: NAlexander Stein <alexander.stein@systec-electronic.com>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

Commit 14e85c0e ("gpio: remove gpio_descs global array") changed
gpio_to_desc()'s behavior to return NULL not only for GPIOs numbers
not in the valid range, but also for all GPIOs whose controller has not
been probed yet. Although this behavior is more correct (nothing hints
that these GPIO numbers will be populated later), this affects
gpio_request() and gpio_request_one() which call gpiod_request() with a
NULL descriptor, causing it to return -EINVAL instead of the expected
-EPROBE_DEFER for a non-probed GPIO.

gpiod_request() is only called with a descriptor obtained from
gpio_to_desc() from these two functions, so address the issue there.

Other ways to obtain GPIOs rely on well-defined mappings and can thus
return -EPROBE_DEFER only for relevant GPIOs, and are thus not affected
by this issue.
Reported-by: NGeert Uytterhoeven <geert@linux-m68k.org>
Signed-off-by: NAlexandre Courbot <acourbot@nvidia.com>
Tested-by: NGeert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

Although gpiod_get_direction() can be considered side-effect free for
consumers, its internals involve setting or clearing bits in the
affected GPIO descriptor, for which we need to force-cast the const
descriptor variable to non-const. This could lead to incorrect behavior
if the compiler decides to optimize here, so remove this const
attribute. The intent is to make gpiod_get_direction() private anyway,
so it does not really matter.
Reported-by: NUwe Kleine-König <u.kleine-koenig@pengutronix.de>
Signed-off-by: NAlexandre Courbot <acourbot@nvidia.com>
Acked-by: NUwe Kleine-König <u.kleine-koenig@pengutronix.de>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

Replace the ARCH_NR_GPIOS-sized static array of GPIO descriptors by
dynamically-allocated arrays for each GPIO chip.

This change makes gpio_to_desc() perform in O(n) (where n is the number
of GPIO chips registered) instead of O(1), however since n is rarely
bigger than 1 or 2 no noticeable performance issue is expected.
Besides this provides more incentive for GPIO consumers to move to the
gpiod interface. One could use a O(log(n)) structure to link the GPIO
chips together, but considering the low limit of n the hypothetical
performance benefit is probably not worth the added complexity.

This patch uses kcalloc() in gpiochip_add(), which removes the ability
to add a chip before kcalloc() can operate. I am not aware of such
cases, but if someone bisects up to this patch then I will be proven
wrong...
Signed-off-by: NAlexandre Courbot <acourbot@nvidia.com>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

gpiolib's gpiod_get_direction() function returns the EINVAL error
if .get_direction callback is not defined.
The patch implements the callback for mxs chip which is useful
for debugging.

Inspired by arch/arm/mach-at91/gpio.c

On the moment the patch is required to get the patch
"serial: mxs-auart: enable PPS support" working.
It is planned to introduce new mctrl_gpio helpers to avoid
gpiod_get_direction() function.
Signed-off-by: NJanusz Uzycki <j.uzycki@elproma.com.pl>
Acked-by: NAlexandre Courbot <acourbot@nvidia.com>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

Use dynamic allocation of GPIOs instead of looking at the gpio%u alias
in DT.
Signed-off-by: NGeert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

It doesn't make much sense to make some (possible expensive) calls to
gpio_is_valid() first, and to ignore the result if the base number is
negative. Check for a positive base number first.
Signed-off-by: NGeert Uytterhoeven <geert+renesas@glider.be>
Reviewed-by: NAlexandre Courbot <acourbot@nvidia.com>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

Currently this implementation only supports one IRQ for (all) SPI devices
using the same chip select.
Signed-off-by: NAlexander Stein <alexander.stein@systec-electronic.com>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

Request a shared interrupt when requesting a mcp23s08 GPIO interrupt.
Signed-off-by: NAlexander Stein <alexander.stein@systec-electronic.com>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

If devm_request_threaded_irq fails for some reason we call
mcp23s08_irq_teardown afterwards.
Do not free the unrequested interrupt in this case. free_irq can also be
omitted for the error free case because we use devm_request_threaded_irq.
Signed-off-by: NAlexander Stein <alexander.stein@systec-electronic.com>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

The device tree probing for R-Car M2-N (r8a7793) and R-Car E2 (r8a7794)
is added.
Signed-off-by: NHisashi Nakamura <hisashi.nakamura.ak@renesas.com>
Signed-off-by: NYoshihiro Kaneko <ykaneko0929@gmail.com>
Acked-by: NGeert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

Add a set_multiple function to the MPC8xxx GPIO chip driver and thereby allow
for actual performance improvements when setting multiple outputs
simultaneously. In my case the time needed to configure an FPGA goes down from
48 s to 20 s.

Change log:
  v6: - rebase on current linux-gpio devel branch
  v5: - no change
  v4: - change interface of the set_multiple driver function to use
        unsigned long as type for the bit fields
      - use generic bitops (which also use unsigned long for bit fields)
  v3: - change commit message
  v2: - add this patch (v1 included only changes to gpiolib)
Signed-off-by: NRojhalat Ibrahim <imr@rtschenk.de>
Reviewed-by: NAlexandre Courbot <acourbot@nvidia.com>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

Introduce new functions gpiod_set_array & gpiod_set_raw_array to the consumer
interface which allow setting multiple outputs with just one function call.
Also add an optional set_multiple function to the driver interface. Without an
implementation of that function in the chip driver outputs are set
sequentially.

Implementing the set_multiple function in a chip driver allows for:
- Improved performance for certain use cases. The original motivation for this
  was the task of configuring an FPGA. In that specific case, where 9 GPIO
  lines have to be set many times, configuration time goes down from 48 s to
  20 s when using the new function.
- Simultaneous glitch-free setting of multiple pins on any kind of parallel
  bus attached to GPIOs provided they all reside on the same chip and bank.

Limitations:
  Performance is only improved for normal high-low outputs. Open drain and
  open source outputs are always set separately from each other. Those kinds
  of outputs could probably be accelerated in a similar way if we could
  forgo the error checking when setting GPIO directions.

Change log:
  v6: - rebase on current linux-gpio devel branch
  v5: - check can_sleep property per chip
      - remove superfluous checks
      - supplement documentation
  v4: - add gpiod_set_array function for setting logical values
      - change interface of the set_multiple driver function to use
        unsigned long as type for the bit fields
      - use generic bitops (which also use unsigned long for bit fields)
      - do not use ARCH_NR_GPIOS any more
  v3: - add documentation
      - change commit message
  v2: - use descriptor interface
      - allow arbitrary groups of GPIOs spanning multiple chips
Signed-off-by: NRojhalat Ibrahim <imr@rtschenk.de>
Reviewed-by: NAlexandre Courbot <acourbot@nvidia.com>
Reviewed-by: NMark Brown <broonie@linaro.org>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

irq_of_parse_and_map() returns 0 on error, so testing for negative
result never works.
Signed-off-by: NDmitry Torokhov <dtor@chromium.org>
Acked-by: NJames Hogan <james.hogan@imgtec.com>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

The TC3589x driver is now a device tree-only driver, so we want
only dynamic IRQs and GPIO numbers from the tc3589x, no static
assignments.
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

This patch adds GPIO and IRQ support for the Diolan DLN-2 GPIO module.

Information about the USB protocol interface can be found in the
Programmer's Reference Manual [1], see section 2.9 for the GPIO
module commands and responses.

[1] https://www.diolan.com/downloads/dln-api-manual.pdfSigned-off-by: NDaniel Baluta <daniel.baluta@intel.com>
Signed-off-by: NOctavian Purdila <octavian.purdila@intel.com>
Acked-by: NLinus Walleij <linus.walleij@linaro.org>
Reviewed-by: NJohan Hovold <johan@kernel.org>
Signed-off-by: NLee Jones <lee.jones@linaro.org>

The size_prop argument of the recently added function
acpi_dev_get_property_reference() is not used by the only current
caller of that function and is very unlikely to be used at any time
going forward.

Namely, for a property whose value is a list of items each containing
a references to a device object possibly accompanied by some integers,
the number of items in the list can always be computed as the number
of elements of type ACPI_TYPE_LOCAL_REFERENCE in the property package.
Thus it should never be necessary to provide an additional "cells"
property with a value equal to the number of items in that list.  It
also should never be necessary to provide a "cells" property specifying
how many integers are supposed to be following each reference.

For this reason, drop the size_prop argument from
acpi_dev_get_property_reference() and update its caller accordingly.

Link: http://marc.info/?l=linux-kernel&m=141511255610556&w=2Suggested-by: NGrant Likely <grant.likely@linaro.org>
Acked-by: NGrant Likely <grant.likely@linaro.org>
Acked-by: NMika Westerberg <mika.westerberg@linux.intel.com>
Tested-by: NMika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

Provide a way for device drivers using GPIOs described by ACPI
GpioIo resources in _CRS to tell the GPIO subsystem what names
(connection IDs) to associate with specific GPIO pins defined
in there.

To do that, a driver needs to define a mapping table as a
NULL-terminated array of struct acpi_gpio_mapping objects
that each contain a name, a pointer to an array of line data
(struct acpi_gpio_params) objects and the size of that array.

Each struct acpi_gpio_params object consists of three fields,
crs_entry_index, line_index, active_low, representing the index of
the target GpioIo()/GpioInt() resource in _CRS starting from zero,
the index of the target line in that resource starting from zero,
and the active-low flag for that line, respectively.

Next, the mapping table needs to be passed as the second
argument to acpi_dev_add_driver_gpios() that will register it with
the ACPI device object pointed to by its first argument.  That
should be done in the driver's .probe() routine.

On removal, the driver should unregister its GPIO mapping table
by calling acpi_dev_remove_driver_gpios() on the ACPI device
object where that table was previously registered.

Included are fixes from Mika Westerberg.
Acked-by: NAlexandre Courbot <acourbot@nvidia.com>
Reviewed-by: NLinus Walleij <linus.walleij@linaro.org>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

Some drivers need to deal with only firmware representation of its
GPIOs. An example would be a GPIO button array driver where each button
is described as a separate firmware node in device tree. Typically these
child nodes do not have physical representation in the Linux device
model.

In order to help device drivers to handle such firmware child nodes we
add dev[m]_get_named_gpiod_from_child() that takes a child firmware
node pointer as its second argument (the first one is the parent device
itself), finds the GPIO using whatever is the underlying firmware
method, and requests the GPIO properly.
Signed-off-by: NMika Westerberg <mika.westerberg@linux.intel.com>
Acked-by: NAlexandre Courbot <acourbot@nvidia.com>
Acked-by: NGrant Likely <grant.likely@linaro.org>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

This is actually a single device with two sets of identical registers,
which just happen to start from a different offset. Instead of having
separate GPIO chips created we consolidate them to be single GPIO chip.

In addition having a single GPIO chip allows us to handle ACPI GPIO
translation in the core in a more generic way, since the two GPIO chips
share the same parent ACPI device.
Signed-off-by: NMika Westerberg <mika.westerberg@linux.intel.com>
Acked-by: NLinus Walleij <linus.walleij@linaro.org>
Acked-by: NGrant Likely <grant.likely@linaro.org>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

With release of ACPI 5.1 and _DSD method we can finally name GPIOs (and
other things as well) returned by _CRS. Previously we were only able to
use integer index to find the corresponding GPIO, which is pretty error
prone if the order changes.

With _DSD we can now query GPIOs using name instead of an integer index,
like the below example shows:

  // Bluetooth device with reset and shutdown GPIOs
  Device (BTH)
  {
      Name (_HID, ...)

      Name (_CRS, ResourceTemplate ()
      {
          GpioIo (Exclusive, PullUp, 0, 0, IoRestrictionInputOnly,
                  "\\_SB.GPO0", 0, ResourceConsumer) {15}
          GpioIo (Exclusive, PullUp, 0, 0, IoRestrictionInputOnly,
                  "\\_SB.GPO0", 0, ResourceConsumer) {27, 31}
      })

      Name (_DSD, Package ()
      {
          ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"),
          Package ()
	  {
              Package () {"reset-gpio", Package() {^BTH, 1, 1, 0 }},
              Package () {"shutdown-gpio", Package() {^BTH, 0, 0, 0 }},
          }
      })
  }

The format of the supported GPIO property is:

  Package () { "name", Package () { ref, index, pin, active_low }}

  ref - The device that has _CRS containing GpioIo()/GpioInt() resources,
        typically this is the device itself (BTH in our case).
  index - Index of the GpioIo()/GpioInt() resource in _CRS starting from zero.
  pin - Pin in the GpioIo()/GpioInt() resource. Typically this is zero.
  active_low - If 1 the GPIO is marked as active_low.

Since ACPI GpioIo() resource does not have field saying whether it is
active low or high, the "active_low" argument can be used here. Setting
it to 1 marks the GPIO as active low.

In our Bluetooth example the "reset-gpio" refers to the second GpioIo()
resource, second pin in that resource with the GPIO number of 31.

This patch implements necessary support to gpiolib for extracting GPIOs
using _DSD device properties.
Signed-off-by: NMika Westerberg <mika.westerberg@linux.intel.com>
Acked-by: NLinus Walleij <linus.walleij@linaro.org>
Acked-by: NGrant Likely <grant.likely@linaro.org>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

The GPIO resources (GpioIo/GpioInt) used in ACPI contain a GPIO number
which is relative to the hardware GPIO controller. Typically this number
can be translated directly to Linux GPIO number because the mapping is
pretty much 1:1.

However, when the GPIO driver is using pins exported by a pin controller
driver via set of GPIO ranges, the mapping might not be 1:1 anymore and
direct translation does not work.

In such cases we need to translate the ACPI GPIO number to be suitable for
the GPIO controller driver in question by checking all the pin controller
GPIO ranges under the given device and using those to get the proper GPIO
number.
Signed-off-by: NMika Westerberg <mika.westerberg@linux.intel.com>
Acked-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

This commit adds the implementation of ->suspend() and ->resume()
platform_driver hooks in order to save and restore the state of the
GPIO configuration. In order to achieve that, additional fields are
added to the mvebu_gpio_chip structure.
Signed-off-by: NThomas Petazzoni <thomas.petazzoni@free-electrons.com>
Acked-by: NAlexandre Courbot <acourbot@nvidia.com>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

Sanity check on resource happening with devm_ioremap_resource().
Signed-off-by: NVarka Bhadram <varkab@cdac.in>
Acked-by: NAlexandre Courbot <acourbot@nvidia.com>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

irq_set_irq_wake() treats its second argument as a boolean. It is much
easier to read code when constant booleans are either 0 or 1!

This particular line of code distracted me somewhat when I was doing a bit of
work in a code browser since it (spuriously) got me worried that I had
misunderstood how irq_set_irq_wake() worked.
Signed-off-by: NDaniel Thompson <daniel.thompson@linaro.org>
Reviewed-by: NAlexandre Courbot <acourbot@nvidia.com>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

irq_set_irq_wake() treats its second argument as a boolean. It is much
easier to read code when constant booleans are either 0 or 1!

This particular line of code distracted me somewhat when I was doing a bit of
work in a code browser since it (spuriously) got me worried that I had
misunderstood how irq_set_irq_wake() worked.
Signed-off-by: NDaniel Thompson <daniel.thompson@linaro.org>
Cc: Linus Walleij <linus.walleij@linaro.org>
Cc: Alexandre Courbot <gnurou@gmail.com>
Reviewed-by: NAlexandre Courbot <acourbot@nvidia.com>
[jkosina@suse.cz: alter subject to be more descriptive]
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

This patch fix company name's spelling typo in module descriptions
and a Kconfig.
Signed-off-by: NMasanari Iida <standby24x7@gmail.com>
Acked-by: NRandy Dunlap <rdunlap@infradead.org>
Acked-by: NChris Snook <chris.snook@gmail.com>
Acked-by: NLinus Walleij <linus.walleij@linaro.org>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

This function actually operates on a gpio_chip, so its prefix should
reflect that fact for consistency with other functions defined in
gpio/driver.h.
Signed-off-by: NAlexandre Courbot <acourbot@nvidia.com>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

Sanity check on resource happening with devm_ioremap_resource().
Signed-off-by: NVarka Bhadram <varkab@cdac.in>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

Sanity check on resource happening with devm_ioremap_resource().
Signed-off-by: NVarka Bhadram <varkab@cdac.in>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

Call irq_domain_remove when gpiochip_add fails to release irq_domain
resources.
Signed-off-by: NPramod Gurav <pramod.gurav@smartplayin.com>
Acked-by: NAlexandre Courbot <acourbot@nvidia.com>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>