gcc-7 notices that the pin_table is an array of 16-bit numbers,
but fails to take the following range check into account:

drivers/gpio/gpiolib-acpi.c: In function 'acpi_gpiochip_request_interrupt':
drivers/gpio/gpiolib-acpi.c:206:24: warning: '%02X' directive writing between 2 and 4 bytes into a region of size 3 [-Wformat-overflow=]
   sprintf(ev_name, "_%c%02X",
                        ^~~~
drivers/gpio/gpiolib-acpi.c:206:20: note: directive argument in the range [0, 65535]
   sprintf(ev_name, "_%c%02X",
                    ^~~~~~~~~
drivers/gpio/gpiolib-acpi.c:206:3: note: 'sprintf' output between 5 and 7 bytes into a destination of size 5
   sprintf(ev_name, "_%c%02X",
   ^~~~~~~~~~~~~~~~~~~~~~~~~~~
    agpio->triggering == ACPI_EDGE_SENSITIVE ? 'E' : 'L',
    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    pin);
    ~~~~

As suggested by Andy, this changes the format string to have a fixed length.
Since modifying the range check did not help, I also opened a bug against
gcc, see link below.

Fixes: 0d1c28a4 ("gpiolib-acpi: Add ACPI5 event model support to gpio.")
Cc: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Link: https://patchwork.kernel.org/patch/9840801/
Link: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82123Signed-off-by: NArnd Bergmann <arnd@arndb.de>
Acked-by: NMika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

Fix up a parameter description to match the code and fix markup for a
constant to prettify output.
Signed-off-by: NThierry Reding <treding@nvidia.com>
Acked-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>
Acked-by: NMika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.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: NHans de Goede <hdegoede@redhat.com>
Acked-by: NMika Westerberg <mika.westerberg@linux.intel.com>
Acked-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: NLinus 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: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>
Reviewed-by: NMika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

This allows ACPI GPIO code to modify flags based on
ACPI GpioIo() / GpioInt() resources.
Signed-off-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>
Tested-by: NJarkko Nikula <jarkko.nikula@linux.intel.com>
Reviewed-by: NMika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: NLinus 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: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>
Tested-by: NJarkko Nikula <jarkko.nikula@linux.intel.com>
Reviewed-by: NMika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: NLinus 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: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>
Tested-by: NJarkko Nikula <jarkko.nikula@linux.intel.com>
Reviewed-by: NMika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

The commit 10cf4899 ("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 4ef03d32 ("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: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>
Tested-by: NJarkko Nikula <jarkko.nikula@linux.intel.com>
Reviewed-by: NMika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: NLinus 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: NDmitry Torokhov <dmitry.torokhov@gmail.com>
Signed-off-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>
Tested-by: NJarkko Nikula <jarkko.nikula@linux.intel.com>
Reviewed-by: NMika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: NLinus 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: NDmitry Torokhov <dmitry.torokhov@gmail.com>
Signed-off-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>
Tested-by: NJarkko Nikula <jarkko.nikula@linux.intel.com>
Reviewed-by: NMika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: NLinus 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: NDmitry Torokhov <dmitry.torokhov@gmail.com>
Acked-by: NMika Westerberg <mika.westerberg@linux.intel.com>
Acked-and-Tested-by: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NLinus 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: NHans de Goede <hdegoede@redhat.com>
Acked-by: NMika Westerberg <mika.westerberg@linux.intel.com>
Reviewed-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

When acpi_dev_gpio_irq_get gets called with an index of say 2, it should
not care if acpi_get_gpiod for index 0 or 1 returns -EPROBE_DEFER.

This allows drivers which request a gpioint with index > 0 to function
if there is no gpiochip driver (loaded) for gpioints with a lower index.
Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>
Acked-by: NMika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

It's unusual to have error checking like (ret <= 0) in cases when
counting GPIO resources. In case when it's mandatory we propagate the
error (-ENOENT), otherwise we don't use the result.

This makes consistent behaviour across all possible variants called in
gpiod_count().
Signed-off-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>
Acked-by: NMika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

Introduce device managed variant of acpi_dev_add_driver_gpios() and its
counterpart acpi_dev_remove_driver_gpios().

The functions in most cases are used in driver's ->probe() and
->remove() callbacks, that's why it's useful to have managed variant of
them.
Signed-off-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>
Acked-by: NRafael J. Wysocki <rjw@rjwysocki.net>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

It seems the code had been changed, but description left untouched.

Update description of the struct acpi_gpio_info and relative comments
accordingly.

Fixes: commit 52044723 ("ACPI / gpio: Add irq_type when a GPIO is used as an interrupt")
Cc: Christophe RICARD <christophe.ricard@gmail.com>
Signed-off-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>
Acked-by: NMika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

The newly added acpi_gpiochip_scan_gpios function produces a few harmless
warnings:

drivers/gpio/gpiolib-acpi.c: In function ‘acpi_gpiochip_add’:
drivers/gpio/gpiolib-acpi.c:925:7: error: ‘dflags’ may be used uninitialized in this function [-Werror=maybe-uninitialized]
drivers/gpio/gpiolib-acpi.c:925:9: error: ‘lflags’ may be used uninitialized in this function [-Werror=maybe-uninitialized]

The problem is that he compiler cannot know that a negative return value
from fwnode_property_read_u32_array() or acpi_gpiochip_pin_to_gpio_offset()
implies that the IS_ERR(gpio_desc) is true, as the value could in theory
be below -MAX_ERRNO.

The function already initializes its output values to zero, and moving
that intialization a little higher up ensures that we can never have
uninitialized data in the caller.

Fixes: c80f1ba7 ("ACPI / gpio: Add hogging support")
Signed-off-by: NArnd Bergmann <arnd@arndb.de>
Acked-by: NMika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

Fixes the following sparse warning:

drivers/gpio/gpiolib-acpi.c:863:18: warning:
 symbol 'acpi_gpiochip_parse_own_gpio' was not declared. Should it be static?
Signed-off-by: NWei Yongjun <weiyongjun1@huawei.com>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

fwnode_handle_put() should be used when terminating
device_for_each_child_node() iteration with break or
return to prevent stale device node references from
being left behind.

This is detected by Coccinelle semantic patch.
Signed-off-by: NWei Yongjun <weiyongjun1@huawei.com>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

Now that we have the new helper function that sets nice names for GPIO
lines based on "gpio-line-names" device property, we can take advantage of
this in acpi_gpiochip_add().
Signed-off-by: NMika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

GPIO hogging means that the GPIO controller can "hog" and configure certain
GPIOs without need for a driver or userspace to do that. This is useful in
open-connected boards where BIOS cannot possibly know beforehand which
devices will be connected to the board.

This adds GPIO hogging mechanism to ACPI analogous to Device Tree.
Signed-off-by: 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>

Make it possible to have an empty GPIOs in a GPIO list for device. For
example a SPI master may use both GPIOs and native pins as chip selects and
we need to be able to distinguish between the two.

This makes it mandatory to have exactly 3 arguments for GPIOs and then
converts gpiolib to use of __acpi_node_get_property_reference() instead. In
addition we make acpi_gpio_package_count() to handle holes as well (this
matches the DT version).
Signed-off-by: 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>

acpi_dev_gpio_irq_get() currently ignores the error returned
by acpi_get_gpiod_by_index() and overwrites it with -ENOENT.

Problem is this error can be -EPROBE_DEFER, which just blows
up some drivers when the module ordering is not correct.

Cc: stable@vger.kernel.org
Signed-off-by: NDavid Arcari <darcari@redhat.com>
Signed-off-by: NBenjamin Tissoires <benjamin.tissoires@redhat.com>
Acked-by: NMika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

The generic GPIO library directly implement code for acpi_find_gpio()
which is only used with CONFIG_ACPI. This was probably done because
OF did the same thing, but I removed that so remove this too.

Rename the internal acpi_find_gpio() in gpiolib-acpi.c to
acpi_populate_gpio_lookup() which seems to be more appropriate anyway
so as to avoid a namespace clash with the same function.

Make the stub return -ENOENT rather than -ENOSYS (as that is for
syscalls!).

For some reason the sunxi pin control driver was including the private
gpiolib header, it works just fine without it so remove that oneliner.

Cc: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Acked-by: NMika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

On Acer One 10, the ACPI battery driver can not be probed because
it depends on the GPIO controller as well as the I2C controller to work,
        Device (BATC)
        {
            Name (_HID, EisaId ("PNP0C0A") /* Control Method Battery */)
            ...
            Name (_DEP, Package (0x03)  // _DEP: Dependencies
            {
                I2C1,
                GPO2,
                GPO0
            })
            ...
        }

The I2C dependency also exists on other platforms and has been fixed by commit
40e7fcb1 ("ACPI: Add _DEP support to fix battery issue on Asus T100TA"),
this patch resolves the GPIO dependency for Acer One 10.

Link:https://bugzilla.kernel.org/show_bug.cgi?id=115191Tested-by: NStace A. Zacharov <stace75@gmail.com>
Signed-off-by: NZhang Rui <rui.zhang@intel.com>
Acked-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>

Calling gpiod_get() from a module and then unloading the module leads to an
oops due to acpi_can_fallback_to_crs() storing the pointer to the passed
'con_id' string onto acpi_crs_lookup_list. The next guy to come along will then
try to access the string but the memory may now be gone with the module.
Make a copy of the passed string instead, and store the copy on the list.

BUG: unable to handle kernel paging request at ffffffffa03e7855
IP: [<ffffffff81338322>] strcmp+0x12/0x30
PGD 2a07067 PUD 2a08063 PMD 74720067 PTE 0
Oops: 0000 [#1] PREEMPT SMP
Modules linked in: i915(+) drm_kms_helper drm intel_gtt snd_hda_codec snd_hda_core i2c_algo_bit syscopya
rea sysfillrect sysimgblt fb_sys_fops agpgart snd_soc_sst_bytcr_rt5640 coretemp hwmon intel_rapl intel_soc_dts_thermal
punit_atom_debug snd_soc_rt5640 snd_soc_rl6231 serio snd_intel_sst_acpi snd_intel_sst_core video snd_soc_sst_mfld_platf
orm snd_soc_sst_match backlight int3402_thermal processor_thermal_device int3403_thermal int3400_thermal acpi_thermal_r
el snd_soc_core intel_soc_dts_iosf int340x_thermal_zone snd_compress i2c_hid hid snd_pcm snd_timer snd soundcore evdev
sch_fq_codel efivarfs ipv6 autofs4 [last unloaded: drm]
CPU: 2 PID: 3064 Comm: modprobe Tainted: G     U  W       4.6.0-rc3-ffrd-ipvr+ #302
Hardware name: Intel Corp. VALLEYVIEW C0 PLATFORM/BYT-T FFD8, BIOS BLAKFF81.X64.0088.R10.1403240443 FFD8
_X64_R_2014_13_1_00 03/24/2014
task: ffff8800701cd200 ti: ffff880070034000 task.ti: ffff880070034000
RIP: 0010:[<ffffffff81338322>]  [<ffffffff81338322>] strcmp+0x12/0x30
RSP: 0000:ffff880070037748  EFLAGS: 00010286
RAX: 0000000080000000 RBX: ffff88007a342800 RCX: 0000000000000006
RDX: 0000000000000006 RSI: ffffffffa054f856 RDI: ffffffffa03e7856
RBP: ffff880070037748 R08: 0000000000000000 R09: 0000000000000001
R10: 0000000000000000 R11: 0000000000000000 R12: ffffffffa054f855
R13: ffff88007281cae0 R14: 0000000000000010 R15: ffffffffffffffea
FS:  00007faa51447700(0000) GS:ffff880079300000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: ffffffffa03e7855 CR3: 0000000041eba000 CR4: 00000000001006e0
Stack:
 ffff880070037770 ffffffff8136ad28 ffffffffa054f855 0000000000000000
 ffff88007a0a2098 ffff8800700377e8 ffffffff8136852e ffff88007a342800
 00000007700377a0 ffff8800700377a0 ffffffff81412442 70672d6c656e6170
Call Trace:
 [<ffffffff8136ad28>] acpi_can_fallback_to_crs+0x88/0x100
 [<ffffffff8136852e>] gpiod_get_index+0x25e/0x310
 [<ffffffff81412442>] ? mipi_dsi_attach+0x22/0x30
 [<ffffffff813685f2>] gpiod_get+0x12/0x20
 [<ffffffffa04fcf41>] intel_dsi_init+0x421/0x480 [i915]
 [<ffffffffa04d3783>] intel_modeset_init+0x853/0x16b0 [i915]
 [<ffffffffa0504864>] ? intel_setup_gmbus+0x214/0x260 [i915]
 [<ffffffffa0510158>] i915_driver_load+0xdc8/0x19b0 [i915]
 [<ffffffff8160fb53>] ? _raw_spin_unlock_irqrestore+0x43/0x70
 [<ffffffffa026b13b>] drm_dev_register+0xab/0xc0 [drm]
 [<ffffffffa026d7b3>] drm_get_pci_dev+0x93/0x1f0 [drm]
 [<ffffffff8160fb53>] ? _raw_spin_unlock_irqrestore+0x43/0x70
 [<ffffffffa043f1f4>] i915_pci_probe+0x34/0x50 [i915]
 [<ffffffff81379751>] pci_device_probe+0x91/0x100
 [<ffffffff8141a75a>] driver_probe_device+0x20a/0x2d0
 [<ffffffff8141a8be>] __driver_attach+0x9e/0xb0
 [<ffffffff8141a820>] ? driver_probe_device+0x2d0/0x2d0
 [<ffffffff81418439>] bus_for_each_dev+0x69/0xa0
 [<ffffffff8141a04e>] driver_attach+0x1e/0x20
 [<ffffffff81419c20>] bus_add_driver+0x1c0/0x240
 [<ffffffff8141b6d0>] driver_register+0x60/0xe0
 [<ffffffff81377d20>] __pci_register_driver+0x60/0x70
 [<ffffffffa026d9f4>] drm_pci_init+0xe4/0x110 [drm]
 [<ffffffff810ce04e>] ? trace_hardirqs_on+0xe/0x10
 [<ffffffffa02f1000>] ? 0xffffffffa02f1000
 [<ffffffffa02f1094>] i915_init+0x94/0x9b [i915]
 [<ffffffff810003bb>] do_one_initcall+0x8b/0x1c0
 [<ffffffff810eb616>] ? rcu_read_lock_sched_held+0x86/0x90
 [<ffffffff811de6d6>] ? kmem_cache_alloc_trace+0x1f6/0x270
 [<ffffffff81183826>] do_init_module+0x60/0x1dc
 [<ffffffff81115a8d>] load_module+0x1d0d/0x2390
 [<ffffffff811120b0>] ? __symbol_put+0x70/0x70
 [<ffffffff811f41b2>] ? kernel_read_file+0x92/0x120
 [<ffffffff811162f4>] SYSC_finit_module+0xa4/0xb0
 [<ffffffff8111631e>] SyS_finit_module+0xe/0x10
 [<ffffffff81001ff3>] do_syscall_64+0x63/0x350
 [<ffffffff816103da>] entry_SYSCALL64_slow_path+0x25/0x25
Code: f7 48 8d 76 01 48 8d 52 01 0f b6 4e ff 84 c9 88 4a ff 75 ed 5d c3 0f 1f 00 55 48 89 e5 eb 04 84 c0
 74 18 48 8d 7f 01 48 8d 76 01 <0f> b6 47 ff 3a 46 ff 74 eb 19 c0 83 c8 01 5d c3 31 c0 5d c3 66
RIP  [<ffffffff81338322>] strcmp+0x12/0x30
 RSP <ffff880070037748>
CR2: ffffffffa03e7855

v2: Make the copied con_id const

Cc: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Cc: Mika Westerberg <mika.westerberg@linux.intel.com>
Cc: Alexandre Courbot <gnurou@gmail.com>
Cc: stable@vger.kernel.org
Fixes: 10cf4899 ("gpiolib: tighten up ACPI legacy gpio lookups")
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Acked-by: NMika Westerberg <mika.westerberg@linux.intel.com>
Reviewed-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

Instead of keeping this reference to the pin ranges in the
client driver-supplied gpio_chip, move it to the internal
gpio_device as the drivers have no need to inspect this.
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

When a GPIO is used as an interrupt in ACPI, the irq_type was not
available for device driver.

Make available polarity and triggering information in acpi_find_gpio by
renaming acpi_gpio_info field active_low  to polarity and adding triggering
field (edge/level).

For sanity, in gpiolib.c replace info.active_low by
"info.polarity == GPIO_ACTIVE_LOW".

Set the irq_type if necessary in acpi_dev_gpio_irq_get.
Signed-off-by: NChristophe Ricard <christophe-h.ricard@st.com>
Acked-by: NMika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

We should not fall back to the legacy unnamed gpio lookup style if the
driver requests gpios with different names, because we'll give out the same
gpio twice. Let's keep track of the names that were used for the device and
only do the fallback for the first name used.
Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>
Acked-by: NMika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

We should not fall back to the legacy unnamed gpio lookup style if the
driver requests gpios with different names, because we'll give out the same
gpio twice. Let's keep track of the names that were used for the device and
only do the fallback for the first name used.
Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>
Acked-by: NMika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

The name .dev in a struct is normally reserved for a struct device
that is let us say a superclass to the thing described by the struct.
struct gpio_chip stands out by confusingly using a struct device *dev
to point to the parent device (such as a platform_device) that
represents the hardware. As we want to give gpio_chip:s real devices,
this is not working. We need to rename this member to parent.

This was done by two coccinelle scripts, I guess it is possible to
combine them into one, but I don't know such stuff. They look like
this:

@@
struct gpio_chip *var;
@@
-var->dev
+var->parent

and:

@@
struct gpio_chip var;
@@
-var.dev
+var.parent

and:

@@
struct bgpio_chip *var;
@@
-var->gc.dev
+var->gc.parent

Plus a few instances of bgpio that I couldn't figure out how
to teach Coccinelle to rewrite.

This patch hits all over the place, but I *strongly* prefer this
solution to any piecemal approaches that just exercise patch
mechanics all over the place. It mainly hits drivers/gpio and
drivers/pinctrl which is my own backyard anyway.

Cc: Haavard Skinnemoen <hskinnemoen@gmail.com>
Cc: Rafał Miłecki <zajec5@gmail.com>
Cc: Richard Purdie <rpurdie@rpsys.net>
Cc: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
Cc: Alek Du <alek.du@intel.com>
Cc: Jaroslav Kysela <perex@perex.cz>
Cc: Takashi Iwai <tiwai@suse.com>
Acked-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>
Acked-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Acked-by: NLee Jones <lee.jones@linaro.org>
Acked-by: NJiri Kosina <jkosina@suse.cz>
Acked-by: NHans-Christian Egtvedt <egtvedt@samfundet.no>
Acked-by: NJacek Anaszewski <j.anaszewski@samsung.com>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

In Microsoft Surface3 the GPIO detecting lid state is shared between GPIO
event and operation region. Below is simplied version of the DSDT from
Surface3 including relevant parts:

    Scope (GPO0)
    {
        Name (_AEI, ResourceTemplate ()
        {
            GpioInt (Edge, ActiveBoth, Shared, PullNone, 0x0000,
                "\\_SB.GPO0", 0x00, ResourceConsumer, ,
                )
                {   // Pin list
                    0x004C
                }
        })

        OperationRegion (GPOR, GeneralPurposeIo, Zero, One)
        Field (GPOR, ByteAcc, NoLock, Preserve)
        {
            Connection (
                GpioIo (Shared, PullNone, 0x0000, 0x0000,
                    IoRestrictionNone, "\\_SB.GPO0", 0x00,
                    ResourceConsumer,,)
                    {   // Pin list
                        0x004C
                    }
            ),
            HELD,   1
        }

        Method (_E4C, 0, Serialized)  // _Exx: Edge-Triggered GPE
        {
            If ((HELD == One))
            {
                ^^LID.LIDB = One
            }
            Else
            {
                ^^LID.LIDB = Zero
                Notify (LID, 0x80) // Status Change
            }

            Notify (^^PCI0.SPI1.NTRG, One) // Device Check
        }
    }

When GPIO 0x4c changes we call ASL method _E4C which tries to read HELD
field (the same GPIO). This triggers following error on the console:

    ACPI Error: Method parse/execution failed [\_SB.GPO0._E4C]
        (Node ffff88013f4b4438), AE_ERROR (20150930/psparse-542)

The error happens because ACPI GPIO operation region handler
(acpi_gpio_adr_space_handler()) tries to acquire the very same GPIO which
returns an error (-EBUSY) because the GPIO is already reserved for the GPIO
event.

Fix this so that we "borrow" the event GPIO if we find the GPIO belongs to
an event. Allow this only for GPIOs that are read.

To be able to go through acpi_gpio->events list for operation region access
we need to make sure the list is properly initialized whenever GPIO chip is
registered.

Link: https://bugzilla.kernel.org/show_bug.cgi?id=106571Signed-off-by: NMika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

Make device_get_next_child_node() work with ACPI data-only subnodes
introduced previously.

Namely, replace acpi_get_next_child() with acpi_get_next_subnode()
that can handle (and return) child device objects as well as child
data-only subnodes of the given device and modify the ACPI part
of the GPIO subsystem to handle data-only subnodes returned by it.

To that end, introduce acpi_node_get_gpiod() taking a struct
fwnode_handle pointer as the first argument.  That argument may
point to an ACPI device object as well as to a data-only subnode
and the function should do the right thing (ie. look for the matching
GPIO descriptor correctly) in either case.

Next, modify fwnode_get_named_gpiod() to use acpi_node_get_gpiod()
instead of acpi_get_gpiod_by_index() which automatically causes
devm_get_gpiod_from_child() to work with ACPI data-only subnodes
that may be returned by device_get_next_child_node() which in turn
is required by the users of that function (the gpio_keys_polled
and gpio-leds drivers).
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
Tested-by: NMika Westerberg <mika.westerberg@linux.intel.com>
Acked-by: NLinus Walleij <linus.walleij@linaro.org>

Split acpi_get_gpiod_by_index() into three smaller routines to
allow the subsequent change of the generic firmware node properties
code to be more strarightforward.
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
Tested-by: NMika Westerberg <mika.westerberg@linux.intel.com>
Acked-by: NLinus Walleij <linus.walleij@linaro.org>

Looks like the word "contiguous" is often mistyped.
Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>
Signed-off-by: NJiri Kosina <jkosina@suse.com>

If a driver requests a GPIO described in its _CRS but the GPIO host
controller (gpiochip) driver providing the GPIO has not been loaded yet
acpi_get_gpiod() returns -ENODEV which causes the calling driver to fail.

If the gpiochip driver is loaded afterwards the driver requesting the GPIO
will not notice this.

Better approach is to return -EPROBE_DEFER in such case. Then when the
gpiochip driver appears the driver requesting the GPIO will be probed
again. This also aligns ACPI GPIO lookup code closer to DT as it does
pretty much the same when no gpiochip driver was found.
Reported-by: NTobias Diedrich <tobiasdiedrich@gmail.com>
Signed-off-by: NMika Westerberg <mika.westerberg@linux.intel.com>
Acked-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: NTobias Diedrich <ranma+kernel@tdiedrich.de>
Reviewed-by: Amos Kong <kongjianjun@gmail.com>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

acpi_gpiochip_request(free)_interrupts can be used for modules,
so export them. This also fixs a compile error when xgene-sb
configured as kernel module.

Fixes: 733cf014 "gpio: xgene: add ACPI support for APM X-Gene GPIO standby driver"
Reviewed-by: NMark Brown <broonie@kernel.org>
Signed-off-by: NHanjun Guo <hanjun.guo@linaro.org>

ACPI specification knows two types of GPIOs: GpioIo and GpioInt. The latter
is used to describe that a given device interrupt line is connected to a
specific GPIO pin. Typical ACPI _CRS entry for such device looks like
below:

    Name (_CRS, ResourceTemplate ()
    {
        I2cSerialBus (0x004A, ControllerInitiated, 0x00061A80,
                      AddressingMode7Bit, "\\_SB.PCI0.I2C6",
                      0x00, ResourceConsumer)
        GpioIo (Exclusive, PullDefault, 0x0000, 0x0000,
                IoRestrictionOutputOnly, "\\_SB.GPO0",
                0x00, ResourceConsumer)
        {
            0x004B
        }
        GpioInt (Level, ActiveLow, Shared, PullDefault, 0x0000,
                 "\\_SB.GPO0", 0x00, ResourceConsumer)
        {
            0x004C
        }
    })

Currently drivers need to request a GPIO corresponding to the right GpioInt
and then translate that to Linux IRQ number. This adds unnecessary lines of
boiler-plate code.

We can ease this a bit by introducing acpi_dev_gpio_irq_get() analogous to
of_irq_get(). This function translates given GpioInt resource under the
device in question to the suitable Linux IRQ 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>

The signed error will be wrongly used as valid gpio offset
Reported-by: NDavid Binderman <dcb314@hotmail.com>
Signed-off-by: NAlan Cox <alan@linux.intel.com>
Signed-off-by: NQipeng Zha <qipeng.zha@intel.com>
Acked-by: NMika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

In acpi_gpiochip_request_interrupts() the handle local
variable already contains the value that we want to pass
to acpi_walk_resources(), so it is better to use that
variable instead of evaluating ACPI_HANDLE() once more
for the same device.
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
Acked-by: NMika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>