An error occurred fetching the project authors.
- 18 Apr, 2024 2 commits
-
-
Andy Shevchenko authored
When line locked as IRQ it has no label assigned. Assign the meaningful value to it. Ex. (for the PCA9355 and MAX3111e chips connected to the system): === Before === PCA953x: interrupt MAX3111e: interrupt === After === PCA953x: NIO1 GpioInt(0) MAX3111e: URT0 GpioInt(0) Acked-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
-
Andy Shevchenko authored
It's ambiguous to have a device-related index in the GPIO interrupt label as most of the devices will have it the same or very similar. Extend label with fwnode name for better granularity. It significantly reduces the scope of searching among devices. Ex. (for the PCA9355 and MAX3111e chips connected to the system): === Before === PCA953x: GpioInt() 0 MAX3111e: GpioInt() 0 === After === PCA953x: NIO1 GpioInt(0) MAX3111e: URT0 GpioInt(0) Acked-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
-
- 15 Apr, 2024 4 commits
-
-
Andy Shevchenko authored
Pass the con_id instead of property so that callers won't repeat the GPIO suffixes to try. Acked-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
-
Andy Shevchenko authored
New coming user may need to check for _CRS fallback slightly differently. Move the current check out of the helper function to allow that user to use it. Acked-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
-
Andy Shevchenko authored
Now that we don't perform anything on the GPIO descriptor, we may simplify the error path in newly introduced helper. Do it so. Acked-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
-
Andy Shevchenko authored
We want to reuse it later on in the code. In particular, it helps to clean up the users of acpi_dev_gpio_irq_wake_get_by(). Acked-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
-
- 11 Apr, 2024 2 commits
-
-
Andy Shevchenko authored
It's better to parse the code when the usual pattern is being used, i.e. checking for error condition first. There is no functional or code generation change (tested in LLVM). Acked-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
-
Andy Shevchenko authored
The acpi_get_gpiod_by_index() never is called with adev being NULL. Remove the redundant check. Acked-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
-
- 01 Mar, 2024 1 commit
-
-
Andy Shevchenko authored
Make acpi_gpio_count() take firmware node as a parameter in order to be aligned with other functions and decouple from unused device pointer. The latter helps to create a common fwnode_gpio_count() in the future. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
-
- 12 Feb, 2024 1 commit
-
-
Krzysztof Kozlowski authored
The match function used in gpio_device_find() should not modify the contents of passed opaque pointer, because such modification would not be necessary for actual matching and it could lead to quite unreadable, spaghetti code. Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> [Bartosz: fix coding style in header] Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
-
- 22 Jan, 2024 1 commit
-
-
Mario Limonciello authored
Spurious wakeups are reported on the GPD G1619-04 which can be absolved by programming the GPIO to ignore wakeups. Cc: stable@vger.kernel.org Reported-and-tested-by: George Melikov <mail@gmelikov.ru> Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/3073Signed-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>
-
- 20 Oct, 2023 1 commit
-
-
Andy Shevchenko authored
When refactoring the acpi_get_gpiod_from_data() the change missed cleaning up the variable on stack. Add missing memset(). Reported-by: Ferry Toth <ftoth@exalondelft.nl> Fixes: 16ba046e ("gpiolib: acpi: teach acpi_find_gpio() to handle data-only nodes") Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Reviewed-by: Dmitry Torokhov <dmitry.torokhov@gmail.com> Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
-
- 09 Oct, 2023 1 commit
-
-
Bartosz Golaszewski authored
With no more users, we can remove acpi_get_and_request_gpiod(). Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org> Reviewed-by: From: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com>
-
- 04 Oct, 2023 1 commit
-
-
Bartosz Golaszewski authored
We're porting all users of gpiochip_find() to using gpio_device_find(). Update the ACPI GPIO code. Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com>
-
- 11 Sep, 2023 2 commits
-
-
Hans de Goede authored
On the Peaq C1010 2-in-1 INT33FC:00 pin 3 is connected to a "dolby" button. At the ACPI level an _AEI event-handler is connected which sets an ACPI variable to 1 on both edges. This variable can be polled + cleared to 0 using WMI. Since the variable is set on both edges the WMI interface is pretty useless even when polling. So instead of writing a custom WMI driver for this the x86-android-tablets code instantiates a gpio-keys platform device for the "dolby" button. Add an ignore_interrupt quirk for INT33FC:00 pin 3 on the Peaq C1010, so that it is not seen as busy when the gpio-keys driver requests it. Note this replaces a hack in x86-android-tablets where it would call acpi_gpiochip_free_interrupts() on the INT33FC:00 GPIO controller. acpi_gpiochip_free_interrupts() is considered private (internal) gpiolib API so x86-android-tablets should stop using it. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com> Acked-by: Linus Walleij <linus.walleij@linaro.org> Acked-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org> Link: https://lore.kernel.org/r/20230909141816.58358-3-hdegoede@redhat.com
-
Hans de Goede authored
In some cases where a broken AEI is present for a GPIO and the GPIO is listed in the ignore_interrupt list to avoid the broken event handler, the kernel may want to use the GPIO for another purpose. Before this change trying to use such a GPIO for another purpose would fail, because the ignore_interrupt list was only checked after the acpi_request_own_gpiod() call, causing the GPIO to already be claimed even though it is listed in the ignore_interrupt list. Fix this by moving the ignore_interrupt list to above the acpi_request_own_gpiod() call. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com> Acked-by: Linus Walleij <linus.walleij@linaro.org> Acked-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org> Link: https://lore.kernel.org/r/20230909141816.58358-2-hdegoede@redhat.com
-
- 10 Jul, 2023 1 commit
-
-
Andy Shevchenko authored
GPIO library should rely only on the GPIO device's fwnode. Hence, replace GPIO chip fwnode usage by respective handle of the GPIO device. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Tested-by: Benjamin Tissoires <bentiss@kernel.org> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
-
- 23 Mar, 2023 3 commits
-
-
Werner Sembach authored
commit 1796f808 ("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>
-
Andy Shevchenko authored
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>
-
Benjamin Tissoires authored
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>
-
- 07 Mar, 2023 1 commit
-
-
Hans de Goede authored
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>
-
- 06 Mar, 2023 1 commit
-
-
Andy Shevchenko authored
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>
-
- 15 Feb, 2023 1 commit
-
-
Werner Sembach authored
The commit 1796f808 ("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: 1796f808 ("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>
-
- 30 Jan, 2023 1 commit
-
-
Andy Shevchenko authored
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>
-
- 23 Jan, 2023 1 commit
-
-
Mario Limonciello authored
commit 1796f808 ("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: 1796f808 ("HID: i2c-hid: acpi: Stop setting wakeup_capable") Fixes: b38f2d5d ("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=2162013Reported-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>
-
- 18 Jan, 2023 2 commits
-
-
Mario Limonciello authored
commit 1796f808 ("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: 1796f808 ("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_1720627Co-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>
-
Mario Limonciello authored
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_1722335Signed-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>
-
- 15 Nov, 2022 4 commits
-
-
Dmitry Torokhov authored
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>
-
Dmitry Torokhov authored
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>
-
Dmitry Torokhov authored
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>
-
Dmitry Torokhov authored
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>
-
- 25 Oct, 2022 1 commit
-
-
Xiang Yang authored
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>
-
- 04 Oct, 2022 1 commit
-
-
Raul E Rangel authored
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>
-
- 05 Sep, 2022 2 commits
-
-
Mario Limonciello authored
Asus UM325UAZ has GPIO 18 programmed as both an interrupt and a wake source, but confirmed with internal team on this design this pin is floating and shouldn't have been programmed. This causes lots of spurious IRQs on the system and horrendous battery life. Add a quirk to ignore attempts to program this pin on this system. Reported-by: Pavel Krc <reg.krn@pkrc.net> Link: https://bugzilla.kernel.org/show_bug.cgi?id=216208Reviewed-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Mario Limonciello <mario.limonciello@amd.com> Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
-
Mario Limonciello authored
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>
-
- 19 Jul, 2022 1 commit
-
-
Nuno Sá authored
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>
-
- 08 Apr, 2022 2 commits
-
-
Andy Shevchenko authored
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>
-
Linus Torvalds authored
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 e40a3ae1: "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: e40a3ae1 ("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>
-
- 07 Mar, 2022 1 commit
-
-
Andy Shevchenko authored
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=215664Reported-by: Kai-Heng Feng <kai.heng.feng@canonical.com> Fixes: 8dcb7a15 ("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>
-
- 03 Jan, 2022 1 commit
-
-
Andy Shevchenko authored
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>
-