JIRA: https://issues.redhat.com/browse/RHEL-57766
commit 7e92061f1e9d1f6d3bfa6113719534f2c773b041
Author: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
Date: Wed Jun 12 20:48:21 2024 +0200
gpiolib: put gpio_suffixes in a single compilation unit
The gpio_suffixes array is defined in the gpiolib.h header. This means
the array is stored in .rodata of every compilation unit that includes
it. Put the definition for the array in gpiolib.c and export just the
symbol in the header. We need the size of the array so expose it too.
Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Link: https://lore.kernel.org/r/20240612184821.58053-1-brgl@bgdev.pl
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
Signed-off-by: Izabela Bakollari <ibakolla@redhat.com>
Bugzilla: https://bugzilla.redhat.com/2183344
commit 5062e4c14b752a21aa24d6500ace6e251fde1d7c
Author: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Date: Fri Mar 10 14:38:10 2023 +0100
gpiolib: acpi: use the fwnode in acpi_gpiochip_find()
While trying to set up an SSDT override for a USB-2-I2C chip [0],
I realized that the function acpi_gpiochip_find() was using the parent
of the gpio_chip to do the ACPI matching.
This works fine on my Ice Lake laptop because AFAICT, the DSDT presents
the PCI device INT3455 as the "Device (GPI0)", but is in fact handled
by the pinctrl driver in Linux.
The pinctrl driver then creates a gpio_chip device. This means that the
gc->parent device in that case is the GPI0 device from ACPI and everything
works.
However, in the hid-cp2112 case, the parent is the USB device, and the
gpio_chip is directly under that USB device. Which means that in this case
gc->parent points at the USB device, and so we can not do an ACPI match
towards the GPIO device.
I think it is safe to resolve the ACPI matching through the fwnode
because when we call gpiochip_add_data(), the first thing it does is
setting a proper gc->fwnode: if it is not there, it borrows the fwnode
of the parent.
So in my Ice Lake case, gc->fwnode is the one from the parent, meaning
that the ACPI handle we will get is the one from the GPI0 in the DSDT
(the pincrtl one). And in the hid-cp2112 case, we get the actual
fwnode from the gpiochip we created in the HID device, making it working.
Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Link: https://lore.kernel.org/linux-input/20230227140758.1575-1-kaehndan@gmail.com/T/#m592f18081ef3b95b618694a612ff864420c5aaf3 [0]
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Shaoqin Huang <shahuang@redhat.com>
Bugzilla: https://bugzilla.redhat.com/2183344
commit af3b462a8e07bc5529e19f60d04a225bfce659e1
Author: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Date: Mon Jan 30 18:13:45 2023 +0200
gpiolib: acpi: Move ACPI device NULL check to acpi_get_driver_gpio_data()
It's logical to check ACPI device for NULL inside
acpi_get_driver_gpio_data() instead of requiring that
in each caller.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Shaoqin Huang <shahuang@redhat.com>
Bugzilla: https://bugzilla.redhat.com/2183344
commit 380c7ba3923c6e471aff0f951a6cf42e8dec2c79
Author: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Date: Wed Feb 8 19:07:28 2023 +0200
gpiolib: Clean up headers
There is a few things done:
- include only the headers we are direct user of
- when pointer is in use, provide a forward declaration
- add missing headers
- group generic headers and subsystem headers
- sort each group alphabetically
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Shaoqin Huang <shahuang@redhat.com>
Bugzilla: https://bugzilla.redhat.com/2183344
commit 70d0fc4288dabd65025fde7774b4f9262afa9034
Author: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Date: Wed Dec 28 11:20:44 2022 +0200
gpiolib: Get rid of not used of_node member
All new drivers should use fwnode and / or parent to provide the
necessary information to the GPIO library.
Cc: Thierry Reding <treding@nvidia.com>
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
Signed-off-by: Shaoqin Huang <shahuang@redhat.com>
Bugzilla: https://bugzilla.redhat.com/2183344
commit 0e3b175f079247f0d40d2ab695999c309d3a7498
Author: Mario Limonciello <mario.limonciello@amd.com>
Date: Mon Jan 16 13:37:01 2023 -0600
gpiolib: acpi: Allow ignoring wake capability on pins that aren't in _AEI
Using the `ignore_wake` quirk or module parameter doesn't work for any pin
that has been specified in the _CRS instead of _AEI.
Extend the `acpi_gpio_irq_is_wake` check to cover both places.
Suggested-by: Raul Rangel <rrangel@chromium.org>
Link: https://gitlab.freedesktop.org/drm/amd/-/issues/1722#note_1722335
Signed-off-by: Mario Limonciello <mario.limonciello@amd.com>
Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
Signed-off-by: Shaoqin Huang <shahuang@redhat.com>
Bugzilla: https://bugzilla.redhat.com/2183344
commit 8eb1f71e7acca4f92cf9cf83030cbb8ec2524025
Author: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Date: Fri Nov 11 14:19:07 2022 -0800
gpiolib: consolidate GPIO lookups
Ensure that all paths to obtain/look up GPIOD from generic
consumer-visible APIs go through the new gpiod_find_and_request()
helper, so that we can easily extend it with support for new firmware
mechanisms.
The only exception is OF-specific [devm_]gpiod_get_from_of_node() API
that is still being used by a couple of drivers and will be removed as
soon as patches converting them to use generic fwnode/device APIs are
accepted.
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
Signed-off-by: Shaoqin Huang <shahuang@redhat.com>
Bugzilla: https://bugzilla.redhat.com/2183344
commit b7452d670fdef8974e18754342fe6f68e20c2567
Author: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Date: Tue Nov 15 11:20:47 2022 +0100
gpiolib: acpi: avoid leaking ACPI details into upper gpiolib layers
There is no need for the generic parts of GPIOLIB to be aware of
implementation details of ACPI-bases lookups.
Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
Signed-off-by: Shaoqin Huang <shahuang@redhat.com>
Bugzilla: https://bugzilla.redhat.com/2183344
commit 16ba046e86e93f42117efe7ca7a7940b83c60afc
Author: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Date: Fri Nov 11 14:19:05 2022 -0800
gpiolib: acpi: teach acpi_find_gpio() to handle data-only nodes
In preparation of switching all ACPI-based GPIO lookups to go through
acpi_find_gpio() we need to make sure it can handle data-only ACPI
nodes, same as existing acpi_node_get_gpiod().
Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
Signed-off-by: Shaoqin Huang <shahuang@redhat.com>
Bugzilla: https://bugzilla.redhat.com/2183344
commit 2b6bce80ae70b91134a5731d85076042ae90c300
Author: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Date: Fri Nov 11 14:19:04 2022 -0800
gpiolib: acpi: change acpi_find_gpio() to accept firmware node
In preparation of switching all ACPI-based GPIO lookups to go through
acpi_find_gpio() let's change it to accept device node as its argument
as we do not always have access to device structure.
Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
Signed-off-by: Shaoqin Huang <shahuang@redhat.com>
Bugzilla: https://bugzilla.redhat.com/2183344
Conflicts:
drivers/gpio/gpiolib-acpi.c
Minor context differences.
commit eac001bf4a5b7d857ec228cd18b4e3644a5ceeb9
Author: Xiang Yang <xiangyang3@huawei.com>
Date: Thu Oct 20 09:44:26 2022 +0800
gpiolib: acpi: Use METHOD_NAME__AEI macro for acpi_walk_resources
Using the METHOD_NAME__AEI macro instead of using "_AEI" directly.
Signed-off-by: Xiang Yang <xiangyang3@huawei.com>
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Shaoqin Huang <shahuang@redhat.com>
Bugzilla: https://bugzilla.redhat.com/2183344
commit 6b6af7bd5718f4e45a9b930533aec1158387d552
Author: Mario Limonciello <mario.limonciello@amd.com>
Date: Tue Aug 2 23:24:59 2022 -0500
gpiolib: acpi: Add support to ignore programming an interrupt
gpiolib-acpi already had support for ignoring a pin for wakeup, but
if an OEM configures a floating pin as an interrupt source then
stopping it from being a wakeup won't do much good to stop the
interrupt storm.
Add support for a module parameter and quirk infrastructure to
ignore interrupts as well.
Signed-off-by: Mario Limonciello <mario.limonciello@amd.com>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Shaoqin Huang <shahuang@redhat.com>
Bugzilla: https://bugzilla.redhat.com/2183344
commit 6fd03f0248281b690e168a5a5c22cb3c98b96326
Author: Nuno Sá <nuno.sa@analog.com>
Date: Wed Jul 13 15:14:20 2022 +0200
gpiolib: acpi: support bias pull disable
On top of looking at PULL_UP and PULL_DOWN flags, also look at
PULL_DISABLE and set the appropriate GPIO flag. The GPIO core will then
pass down this to controllers that support it.
Signed-off-by: Nuno Sá <nuno.sa@analog.com>
Acked-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Bartosz Golaszewski <brgl@bgdev.pl>
Signed-off-by: Shaoqin Huang <shahuang@redhat.com>
Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=2166610
Upstream Status: since v6.2
Tested: with the hid-tools test suite and some hardware
commit d63f11c02b8d3e54bdb65d8c309f73b7f474aec4
Author: Mario Limonciello <mario.limonciello@amd.com>
Date: Sat Jan 21 07:48:11 2023 -0600
gpiolib-acpi: Don't set GPIOs for wakeup in S3 mode
commit 1796f808e4bb ("HID: i2c-hid: acpi: Stop setting wakeup_capable")
adjusted the policy to enable wakeup by default if the ACPI tables
indicated that a device was wake capable.
It was reported however that this broke suspend on at least two System76
systems in S3 mode and two Lenovo Gen2a systems, but only with S3.
When the machines are set to s2idle, wakeup behaves properly.
Configuring the GPIOs for wakeup with S3 doesn't work properly, so only
set it when the system supports low power idle.
Fixes: 1796f808e4bb ("HID: i2c-hid: acpi: Stop setting wakeup_capable")
Fixes: b38f2d5d9615c ("i2c: acpi: Use ACPI wake capability bit to set wake_irq")
Link: https://gitlab.freedesktop.org/drm/amd/-/issues/2357
Link: https://bugzilla.redhat.com/show_bug.cgi?id=2162013
Reported-by: Nathan Smythe <ncsmythe@scruboak.org>
Tested-by: Nathan Smythe <ncsmythe@scruboak.org>
Suggested-by: Raul Rangel <rrangel@chromium.org>
Signed-off-by: Mario Limonciello <mario.limonciello@amd.com>
Acked-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=2166610
Upstream Status: since v6.1
Tested: with the hid-tools test suite and some hardware
commit 4c99256013fa4e0fe9733ca1bab2b5684ccc02a1
Author: Raul E Rangel <rrangel@chromium.org>
Date: Thu Sep 29 10:19:09 2022 -0600
gpiolib: acpi: Add wake_capable variants of acpi_dev_gpio_irq_get
The ACPI spec defines the SharedAndWake and ExclusiveAndWake share type
keywords. This is an indication that the GPIO IRQ can also be used as a
wake source. This change exposes the wake_capable bit so drivers can
correctly enable wake functionality instead of making an assumption.
Signed-off-by: Raul E Rangel <rrangel@chromium.org>
Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=2166610
Upstream Status: since v6.3.1
Tested: with the hid-tools test suite and some hardware
commit fddb9ede64b6506b7449b463207f4428f34379dc
Author: Werner Sembach <wse@tuxedocomputers.com>
Date: Wed Mar 22 13:15:47 2023 +0100
gpiolib: acpi: Add a ignore wakeup quirk for Clevo NL5xNU
commit 782eea0c89f7d071d6b56ecfa1b8b0c81164b9be upstream.
commit 1796f808e4bb ("HID: i2c-hid: acpi: Stop setting wakeup_capable")
changed the policy such that I2C touchpads may be able to wake up the
system by default if the system is configured as such.
However on Clevo NL5xNU there is a mistake in the ACPI tables that the
TP_ATTN# signal connected to GPIO 9 is configured as ActiveLow and level
triggered but connected to a pull up. As soon as the system suspends the
touchpad loses power and then the system wakes up.
To avoid this problem, introduce a quirk for this model that will prevent
the wakeup capability for being set for GPIO 9.
This patch is analoge to a very similar patch for NL5xRU, just the DMI
string changed.
Signed-off-by: Werner Sembach <wse@tuxedocomputers.com>
Cc: stable@vger.kernel.org
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=2166610
Upstream Status: since v6.2
Tested: with the hid-tools test suite and some hardware
commit a69982c37cd0586e6832268155349301b87f2e35
Author: Werner Sembach <wse@tuxedocomputers.com>
Date: Wed Feb 15 15:39:41 2023 +0100
gpiolib: acpi: Add a ignore wakeup quirk for Clevo NH5xAx
The commit 1796f808e4bb ("HID: i2c-hid: acpi: Stop setting wakeup_capable")
changed the policy such that I2C touchpads may be able to wake up the
system by default if the system is configured as such.
However for some devices there is a bug, that is causing the touchpad to
instantly wake up the device again once it gets deactivated. The root cause
is still under investigation (see Link tag).
To workaround this problem for the time being, introduce a quirk for this
model that will prevent the wakeup capability for being set for GPIO 16.
Fixes: 1796f808e4bb ("HID: i2c-hid: acpi: Stop setting wakeup_capable")
Link: https://lore.kernel.org/linux-acpi/20230210164636.628462-1-wse@tuxedocomputers.com/
Signed-off-by: Werner Sembach <wse@tuxedocomputers.com>
Cc: <stable@vger.kernel.org> # v6.1+
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=2166610
Upstream Status: since v6.2
Tested: with the hid-tools test suite and some hardware
commit 4cb786180dfb5258ff3111181b5e4ecb1d4a297b
Author: Mario Limonciello <mario.limonciello@amd.com>
Date: Mon Jan 16 13:37:02 2023 -0600
gpiolib: acpi: Add a ignore wakeup quirk for Clevo NL5xRU
commit 1796f808e4bb ("HID: i2c-hid: acpi: Stop setting wakeup_capable")
changed the policy such that I2C touchpads may be able to wake up the
system by default if the system is configured as such.
However on Clevo NL5xRU there is a mistake in the ACPI tables that the
TP_ATTN# signal connected to GPIO 9 is configured as ActiveLow and level
triggered but connected to a pull up. As soon as the system suspends the
touchpad loses power and then the system wakes up.
To avoid this problem, introduce a quirk for this model that will prevent
the wakeup capability for being set for GPIO 9.
Fixes: 1796f808e4bb ("HID: i2c-hid: acpi: Stop setting wakeup_capable")
Reported-by: Werner Sembach <wse@tuxedocomputers.com>
Link: https://gitlab.freedesktop.org/drm/amd/-/issues/1722#note_1720627
Co-developed-by: Werner Sembach <wse@tuxedocomputers.com>
Signed-off-by: Werner Sembach <wse@tuxedocomputers.com>
Signed-off-by: Mario Limonciello <mario.limonciello@amd.com>
Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
Conflicts:
drivers/gpio/gpiolib-acpi.c: minor conflict as 0ea76c401f92
is not backported (entry in the list)
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=2176554
Conflicts:
drivers/gpio/gpiolib-acpi.c - minor context differences
commit 5adc409340b1fc82bc1175e602d14ac82ac685e3
Author: Hans de Goede <hdegoede@redhat.com>
Date: Wed, 1 Mar 2023 11:04:34 +0100
x86 ACPI boards which ship with only Android as their factory image usually
have pretty broken ACPI tables, relying on everything being hardcoded in
the factory kernel image and often disabling parts of the ACPI enumeration
kernel code to avoid the broken tables causing issues.
Part of this broken ACPI code is that sometimes these boards have _AEI
ACPI GPIO event handlers which are broken.
So far this has been dealt with in the platform/x86/x86-android-tablets.c
module, which contains various workarounds for these devices, by it calling
acpi_gpiochip_free_interrupts() on gpiochip-s with troublesome handlers to
disable the handlers.
But in some cases this is too late, if the handlers are of the edge type
then gpiolib-acpi.c's code will already have run them at boot.
This can cause issues such as GPIOs ending up as owned by "ACPI:OpRegion",
making them unavailable for drivers which actually need them.
Boards with these broken ACPI tables are already listed in
drivers/acpi/x86/utils.c for e.g. acpi_quirk_skip_i2c_client_enumeration().
Extend the quirks mechanism for a new acpi_quirk_skip_gpio_event_handlers()
helper, this re-uses the DMI-ids rather then having to duplicate the same
DMI table in gpiolib-acpi.c .
Also add the new ACPI_QUIRK_SKIP_GPIO_EVENT_HANDLERS quirk to existing
boards with troublesome ACPI gpio event handlers, so that the current
acpi_gpiochip_free_interrupts() hack can be removed from
x86-android-tablets.c .
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Acked-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Signed-off-by: Rafael J. Wysocki <rjw@rjwysocki.net>
Signed-off-by: Mark Langsdorf <mlangsdo@redhat.com>
Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=2071835
Tested: This is one of a series of patch sets to enable Arm SystemReady IR
support in the kernel for NXP i.MX8 platforms. This set updates GPIO
support. It has been tested via simple boot tests and by using the
kernel GPIO tools to verify pins are being identified and can be used.
commit 0c2cae09a765b1c1d842eb9328982976ec735926
Author: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Date: Thu Mar 17 11:33:11 2022 +0200
gpiolib: acpi: Convert type for pin to be unsigned
A pin that comes from ACPI tables is of unsigned type. This also applies
to the internal APIs which use unsigned int to store the pin. Convert
type for pin to be unsigned in the places where it's not yet true.
While at it, add a stub for acpi_get_and_request_gpiod() for the sake
of consistency in the APIs.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
(cherry picked from commit 0c2cae09a765b1c1d842eb9328982976ec735926)
Signed-off-by: Al Stone <ahs3@redhat.com>
Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=2071835
Tested: This is one of a series of patch sets to enable Arm SystemReady IR
support in the kernel for NXP i.MX8 platforms. This set updates GPIO
support. It has been tested via simple boot tests and by using the
kernel GPIO tools to verify pins are being identified and can be used.
commit 213d266ebfb1621aab79cfe63388facc520a1381
Author: Linus Torvalds <torvalds@linux-foundation.org>
Date: Sat Mar 19 16:21:09 2022 -0700
gpiolib: acpi: use correct format characters
When compiling with -Wformat, clang emits the following warning:
gpiolib-acpi.c:393:4: warning: format specifies type 'unsigned char' but the argument has type 'int' [-Wformat]
pin);
^~~
So warning that '%hhX' is paired with an 'int' is all just completely
mindless and wrong. Sadly, I can see a different bogus warning reason
why people would want to use '%02hhX'.
Again, the *sane* thing from a human perspective is to use '%02X. But
if the compiler doesn't do any range analysis at all, it could decide
that "Oh, that print format could need up to 8 bytes of space in the
result". Using '%02hhX' would cut that down to two.
And since we use
char ev_name[5];
and currently use "_%c%02hhX" as the format string, even a compiler
that doesn't notice that "pin <= 255" test that guards this all will
go "OK, that's at most 4 bytes and the final NUL termination, so it's
fine".
While a compiler - like gcc - that only sees that the original source
of the 'pin' value is a 'unsigned short' array, and then doesn't take
the "pin <= 255" into account, will warn like this:
gpiolib-acpi.c: In function 'acpi_gpiochip_request_interrupt':
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",
^~~~
gpiolib-acpi.c:206:20: note: directive argument in the range [0, 65535]
because gcc isn't being very good at that argument range analysis either.
In other words, the original use of 'hhx' was bogus to begin with, and
due to *another* compiler warning being bad, and we had that bad code
being written back in 2016 to work around _that_ compiler warning
(commit e40a3ae1f794: "gpio: acpi: work around false-positive
-Wstring-overflow warning").
Sadly, two different bad compiler warnings together does not make for
one good one.
It just makes for even more pain.
End result: I think the simplest and cleanest option is simply the
proposed change which undoes that '%hhX' change for gcc, and replaces
it with just using a slightly bigger stack allocation. It's not like
a 5-byte allocation is in any way likely to have saved any actual stack,
since all the other variables in that function are 'int' or bigger.
False-positive compiler warnings really do make people write worse
code, and that's a problem. But on a scale of bad code, I feel that
extending the buffer trivially is better than adding a pointless cast
that literally makes no sense.
At least in this case the end result isn't unreadable or buggy. We've
had several cases of bad compiler warnings that caused changes that
were actually horrendously wrong.
Fixes: e40a3ae1f7 ("gpio: acpi: work around false-positive -Wstring-overflow warning")
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
(cherry picked from commit 213d266ebfb1621aab79cfe63388facc520a1381)
Signed-off-by: Al Stone <ahs3@redhat.com>
Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=2071835
Tested: This is one of a series of patch sets to enable Arm SystemReady IR
support in the kernel for NXP i.MX8 platforms. This set updates GPIO
support. It has been tested via simple boot tests and by using the
kernel GPIO tools to verify pins are being identified and can be used.
commit 660c619b9d7ccd28648ee3766cdbe94ec7b27402
Author: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Date: Mon Mar 7 13:56:23 2022 +0200
gpiolib: acpi: Convert ACPI value of debounce to microseconds
It appears that GPIO ACPI library uses ACPI debounce values directly.
However, the GPIO library APIs expect the debounce timeout to be in
microseconds.
Convert ACPI value of debounce to microseconds.
While at it, document this detail where it is appropriate.
BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=215664
Reported-by: Kai-Heng Feng <kai.heng.feng@canonical.com>
Fixes: 8dcb7a15a5 ("gpiolib: acpi: Take into account debounce settings")
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Tested-by: Kai-Heng Feng <kai.heng.feng@canonical.com>
Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: Bartosz Golaszewski <brgl@bgdev.pl>
(cherry picked from commit 660c619b9d7ccd28648ee3766cdbe94ec7b27402)
Signed-off-by: Al Stone <ahs3@redhat.com>
Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=2071835
Tested: This is one of a series of patch sets to enable Arm SystemReady IR
support in the kernel for NXP i.MX8 platforms. This set updates GPIO
support. It has been tested via simple boot tests and by using the
kernel GPIO tools to verify pins are being identified and can be used.
commit 4a08d63c243ae8525c40016ce57b50df515fafaf
Author: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Date: Thu Dec 23 12:38:08 2021 +0200
gpiolib: acpi: make fwnode take precedence in struct gpio_chip
If the driver sets the fwnode in struct gpio_chip, let it take
precedence over the parent's fwnode.
This is a follow up to the commit 9126a738edc1 ("gpiolib: of: make
fwnode take precedence in struct gpio_chip").
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: Bartosz Golaszewski <brgl@bgdev.pl>
(cherry picked from commit 4a08d63c243ae8525c40016ce57b50df515fafaf)
Signed-off-by: Al Stone <ahs3@redhat.com>
Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=2071835
Tested: This is one of a series of patch sets to enable Arm SystemReady IR
support in the kernel for NXP i.MX8 platforms. This set updates GPIO
support. It has been tested via simple boot tests and by using the
kernel GPIO tools to verify pins are being identified and can be used.
commit be3dc15ffe644d1b8bfae4a05eae3dc413a7c5e7
Author: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Date: Tue Nov 23 12:18:37 2021 +0200
gpiolib: acpi: Unify debug and other messages format
When ACPI device pointer available use it, otherwise take parent of GPIO chip.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
(cherry picked from commit be3dc15ffe644d1b8bfae4a05eae3dc413a7c5e7)
Signed-off-by: Al Stone <ahs3@redhat.com>
Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=2071835
Tested: This is one of a series of patch sets to enable Arm SystemReady IR
support in the kernel for NXP i.MX8 platforms. This set updates GPIO
support. It has been tested via simple boot tests and by using the
kernel GPIO tools to verify pins are being identified and can be used.
commit bdfd6ab8fdccd8b138837efff66f4a1911496378
Author: Hans de Goede <hdegoede@redhat.com>
Date: Thu Nov 25 21:30:10 2021 +0100
gpiolib: acpi: Do not set the IRQ type if the IRQ is already in use
If the IRQ is already in use, then acpi_dev_gpio_irq_get_by() really
should not change the type underneath the current owner.
I specifically hit an issue with this an a Chuwi Hi8 Super (CWI509) Bay
Trail tablet, when the Boot OS selection in the BIOS is set to Android.
In this case _STA for a MAX17047 ACPI I2C device wrongly returns 0xf and
the _CRS resources for this device include a GpioInt pointing to a GPIO
already in use by an _AEI handler, with a different type then specified
in the _CRS for the MAX17047 device. Leading to the acpi_dev_gpio_irq_get()
call done by the i2c-core-acpi.c code changing the type breaking the
_AEI handler.
Now this clearly is a bug in the DSDT of this tablet (in Android mode),
but in general calling irq_set_irq_type() on an IRQ which already is
in use seems like a bad idea.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
(cherry picked from commit bdfd6ab8fdccd8b138837efff66f4a1911496378)
Signed-off-by: Al Stone <ahs3@redhat.com>
Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=2071835
Tested: This is one of a series of patch sets to enable Arm SystemReady IR
support in the kernel for NXP i.MX8 platforms. This set updates GPIO
support. It has been tested via simple boot tests and by using the
kernel GPIO tools to verify pins are being identified and can be used.
commit 2ff64a84bbb3ea0281899766d9a944fd18db7013
Author: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Date: Wed Nov 10 15:47:43 2021 +0200
gpiolib: acpi: shrink devm_acpi_dev_add_driver_gpios()
If all we want to manage is a single pointer, there's no need to
manually allocate and add a new devres. We can simply use
devm_add_action_or_reset() and shrink the code by a good bit.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com>
(cherry picked from commit 2ff64a84bbb3ea0281899766d9a944fd18db7013)
Signed-off-by: Al Stone <ahs3@redhat.com>
Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=2071835
Tested: This is one of a series of patch sets to enable Arm SystemReady IR
support in the kernel for NXP i.MX8 platforms. This set updates GPIO
support. It has been tested via simple boot tests and by using the
kernel GPIO tools to verify pins are being identified and can be used.
commit 507805b83ff108473dba9d4909e41abd50cf07f5
Author: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Date: Wed Nov 10 15:47:42 2021 +0200
gpiolib: acpi: Remove never used devm_acpi_dev_remove_driver_gpios()
Remove never used devm_acpi_dev_remove_driver_gpios().
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com>
(cherry picked from commit 507805b83ff108473dba9d4909e41abd50cf07f5)
Signed-off-by: Al Stone <ahs3@redhat.com>
Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=2071835
Tested: This is one of a series of patch sets to enable Arm SystemReady IR
support in the kernel for NXP i.MX8 platforms. This set updates GPIO
support. It has been tested via simple boot tests and by using the
kernel GPIO tools to verify pins are being identified and can be used.
commit adb5151fa82ca8cc511c7d6bf80842281c09ea42
Author: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Date: Thu Oct 14 16:47:56 2021 +0300
gpiolib: acpi: Replace custom code with device_match_acpi_handle()
Since driver core provides a generic device_match_acpi_handle()
we may replace the custom code with it.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Reviewed-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Link: https://lore.kernel.org/r/20211014134756.39092-3-andriy.shevchenko@linux.intel.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit adb5151fa82ca8cc511c7d6bf80842281c09ea42)
Signed-off-by: Al Stone <ahs3@redhat.com>
Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=2071835
Tested: This is one of a series of patch sets to enable Arm SystemReady IR
support in the kernel for NXP i.MX8 platforms. This set updates GPIO
support. It has been tested via simple boot tests and by using the
kernel GPIO tools to verify pins are being identified and can be used.
commit cef0d022f55364d69017daeb9443bd31510ad6a2
Author: Hans de Goede <hdegoede@redhat.com>
Date: Mon Aug 16 12:41:19 2021 +0200
gpiolib: acpi: Make set-debounce-timeout failures non fatal
Commit 8dcb7a15a5 ("gpiolib: acpi: Take into account debounce settings")
made the gpiolib-acpi code call gpio_set_debounce_timeout() when requesting
GPIOs.
This in itself is fine, but it also made gpio_set_debounce_timeout()
errors fatal, causing the requesting of the GPIO to fail. This is causing
regressions. E.g. on a HP ElitePad 1000 G2 various _AEI specified GPIO
ACPI event sources specify a debouncy timeout of 20 ms, but the
pinctrl-baytrail.c only supports certain fixed values, the closest
ones being 12 or 24 ms and pinctrl-baytrail.c responds with -EINVAL
when specified a value which is not one of the fixed values.
This is causing the acpi_request_own_gpiod() call to fail for 3
ACPI event sources on the HP ElitePad 1000 G2, which in turn is causing
e.g. the battery charging vs discharging status to never get updated,
even though a charger has been plugged-in or unplugged.
Make gpio_set_debounce_timeout() errors non fatal, warning about the
failure instead, to fix this regression.
Note we should probably also fix various pinctrl drivers to just
pick the first bigger discrete value rather then returning -EINVAL but
this will need to be done on a per driver basis, where as this fix
at least gets us back to where things were before and thus restores
functionality on devices where this was lost due to
gpio_set_debounce_timeout() errors.
Fixes: 8dcb7a15a5 ("gpiolib: acpi: Take into account debounce settings")
Depends-on: 2e2b496ceb ("gpiolib: acpi: Extract acpi_request_own_gpiod() helper")
Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Acked-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Bartosz Golaszewski <brgl@bgdev.pl>
(cherry picked from commit cef0d022f55364d69017daeb9443bd31510ad6a2)
Signed-off-by: Al Stone <ahs3@redhat.com>
The acpi_walk_dep_device_list() function is not as generic as its
name implies, serving only to decrement the dependency count for each
dependent device of the input.
Extend it to accept a callback which can be applied to all the
dependencies in acpi_dep_list.
Replace all existing calls to the function with calls to a wrapper,
passing a callback that applies the same dependency reduction.
Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Acked-by: Maximilian Luz <luzmaximilian@gmail.com> # for platform/surface parts
Signed-off-by: Daniel Scally <djrscally@gmail.com>
[ rjw: Changelog edits ]
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Add a function to verify that a given ACPI resource represents a GpioIo()
type of resource, and return it if so.
Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Daniel Scally <djrscally@gmail.com>
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
We need to be able to translate GPIO resources in an ACPI device's _CRS
into GPIO descriptor array. Those are represented in _CRS as a pathname
to a GPIO device plus the pin's index number: the acpi_get_gpiod()
function is perfect for that purpose.
As it's currently only used internally within the GPIO layer, provide and
export a wrapper function that additionally holds a reference to the GPIO
device.
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Signed-off-by: Daniel Scally <djrscally@gmail.com>
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Like some other Bay and Cherry Trail SoC based devices the Dell Venue
10 Pro 5055 has an embedded-controller which uses ACPI GPIO events to
report events instead of using the standard ACPI EC interface for this.
The EC interrupt is only used to report battery-level changes and
it keeps doing this while the system is suspended, causing the system
to not stay suspended.
Add an ignore-wake quirk for the GPIO pin used by the EC to fix the
spurious wakeups from suspend.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Acked-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
In the ACPI case we may use the firmware node in the similar way
as it's done for OF case. We may use that fwnode for other purposes
in the future.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
Currently only search by index is supported. However, in some cases
we might need to pass the quirks to the acpi_dev_gpio_irq_get().
For this, split out acpi_dev_gpio_irq_get_by() and replace
acpi_dev_gpio_irq_get() by calling above with NULL for name parameter.
Fixes: ba8c90c618 ("gpio: pca953x: Override IRQ for one of the expanders on Galileo Gen 2")
Depends-on: 0ea683931a ("gpio: dwapb: Convert driver to using the GPIO-lib-based IRQ-chip")
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Acked-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Acked-by: Linus Walleij <linus.walleij@linaro.org>
On some systems the ACPI tables has wrong pin number and instead of
having a relative one it provides an absolute one in the global GPIO
number space.
Add ACPI_GPIO_QUIRK_ABSOLUTE_NUMBER quirk to cope with such cases.
Fixes: ba8c90c618 ("gpio: pca953x: Override IRQ for one of the expanders on Galileo Gen 2")
Depends-on: 0ea683931a ("gpio: dwapb: Convert driver to using the GPIO-lib-based IRQ-chip")
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Acked-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Acked-by: Linus Walleij <linus.walleij@linaro.org>
fixed the following coccicheck:
./drivers/gpio/gpiolib-acpi.c:176:7-27: ERROR: Threaded IRQ with no
primary handler requested without IRQF_ONESHOT
Make sure threaded IRQs without a primary handler are always request
with IRQF_ONESHOT
Reported-by: Abaci Robot <abaci@linux.alibaba.com>
Signed-off-by: Yang Li <yang.lee@linux.alibaba.com>
Acked-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
- several refactoring patches of the core gpiolib code
- add support for NXP PCAL9554B/C to gpio-pca953x
- allow probing mockup devices from device tree
- refactoring and improvements to gpio-rcar
- improvements to locking in gpio-tegra
- code shrink in gpiolib devres
- get the irq offset from device tree in gpio-sifive
- major refactoring of gpio-exar
- convert gpio-mvebu pwm access to regmap
- create a new submenu for virtual GPIO drivers
- fix clang fall-through warnings treewide
- minor driver refactoring and tweaks sprinkled all over
-----BEGIN PGP SIGNATURE-----
iQIzBAABCAAdFiEEFp3rbAvDxGAT0sefEacuoBRx13IFAl/QnM8ACgkQEacuoBRx
13LkDw/+NKHc32hKgMJmSsLLFHgZ8XB+7Y775G5Ejxj+4Z0hVY9LdqL0zSYwrzCg
D2dKwrKMtM83T8vf0bVbPdZ/9uuqrljvocGYt2CFmDqQa3sSlJkyDiSak2HAqjK/
p9cgDQaUIlDrg2xh/1kSqELQoONmp4m82i++bItIwxIqAwPWfjSHVD7EQznDu0QD
MJ7eYSuVlpeBhMwfyGCYSuUFhd4wN+nTkLTYw3nNlU4PHCKpdgYd7SBCJjSsLAhM
8FOQ+PBspS6t8lPIEa4Mt+TOWUbbboGUBy40GPNU8QcUjbzj3TwPIBJu/0SIdSOy
fBrk+GRjWtJ9shSlz0WQ19mG+qMjIiw4xLY1Jh3Tr4b75bQ3a4pk50aPWNE6bbHV
NP1wZer/s06f1TQFKjfuDVFsOoRLyrTuOzlW0COAHoqFOdgimZi36xtjaS3AL3lE
POBiBxFo9VaQ0enD99QMBt3940IP3ekRmlqRxeR1t8C0gE5np8IMZ5Dti8Fh4eCN
hUQTDDuWQadluOdhMdLCBh5cA3VfZY8xksAMBzAYnSUHzM2D8TcKVjfJeegCEuZd
kapAV3nLUv1/ZU36okFpMaHaKBL+xGDv8gtV2ro7rptkm6khNPQ3hxKvRbCRCG+S
fO6IKThwozZEL/uVvsZLRKvN47g89oAGYYfasqq49932WChVKf8=
=RmnM
-----END PGP SIGNATURE-----
Merge tag 'gpio-updates-for-v5.11' of git://git.kernel.org/pub/scm/linux/kernel/git/brgl/linux into devel
gpio updates for v5.11-rc1
- several refactoring patches of the core gpiolib code
- add support for NXP PCAL9554B/C to gpio-pca953x
- allow probing mockup devices from device tree
- refactoring and improvements to gpio-rcar
- improvements to locking in gpio-tegra
- code shrink in gpiolib devres
- get the irq offset from device tree in gpio-sifive
- major refactoring of gpio-exar
- convert gpio-mvebu pwm access to regmap
- create a new submenu for virtual GPIO drivers
- fix clang fall-through warnings treewide
- minor driver refactoring and tweaks sprinkled all over
In preparation to enable -Wimplicit-fallthrough for Clang, fix a warning
by explicitly adding a break statement instead of letting the code fall
through to the next case.
Link: https://github.com/KSPP/linux/issues/115
Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
We may use BIT() macro to increase readability in
acpi_gpio_adr_space_handler().
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com>
As specified by ACPI the pin index is 16-bit unsigned integer.
Define the variable, which holds it, accordingly.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com>
It appears that we are using similar code excerpts for ACPI OpRegion
and event handling. Deduplicate those excerpts by extracting a new
acpi_request_own_gpiod() helper.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com>
GpioInt() implies input configuration of the pin. Add this to
the acpi_gpio_to_gpiod_flags() and make usable for GpioInt().
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com>
GpioIo() resources don't contain an initial value for the output pin.
Therefore instead of deducting its value solely based on bias field
we should deduce that value from the polarity and the bias fields.
Typical scenario is, when pin is defined in the table and its polarity,
specified in _DSD or via platform code, is defined as active low,
in the following call chain:
-> acpi_populate_gpio_lookup()
-> acpi_gpio_to_gpiod_flags()
it will return GPIOD_OUT_HIGH if bias is set no matter if polarity
is GPIO_ACTIVE_LOW, so it will return the current level instead of
the logical level.
Cc: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Vasile-Laurentiu Stanimir <vasile-laurentiu.stanimir@windriver.com>
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Move acpi_gpio_to_gpiod_flags() upper in the code to allow further refactoring.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Mika noticed that some code is run under mutex when it doesn't require
the lock, like an error code assignment.
Move non-critical code outside of critical section.
Suggested-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Cc: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com>
We didn't take into account the debounce settings supplied by ACPI.
This change is targeting the mentioned gap.
Reported-by: Coiby Xu <coiby.xu@gmail.com>
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Use named item instead of plain integer for enum gpiod_flags
to make it clear that even 0 has its own meaning.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com>
In some cases the GpioInt() resource is coming with bias settings
which may affect system functioning. Respect bias settings for
GpioInt() resource by calling acpi_gpio_update_gpiod_*flags() API
in acpi_dev_gpio_irq_get().
Reported-by: Jamie McClymont <jamie@kwiius.com>
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Izabela Bakollari
Shaoqin Huang
Benjamin Tissoires
Mark Langsdorf
Al Stone
Hans de Goede
Daniel Scally
Andy Shevchenko
Yang Li
Linus Walleij
Gustavo A. R. Silva
Vasile-Laurentiu Stanimir