kernel/linux.git/drivers/pinctrl/pinctrl-amd.c, branch linux-6.12.y

pinctrl: amd: Clear GPIO debounce for suspend

2025-07-17T16:37:04+00:00

[ Upstream commit 8ff4fb276e2384a87ae7f65f3c28e1e139dbb3fe ] soc-button-array hardcodes a debounce value by means of gpio_keys which uses pinctrl-amd as a backend to program debounce for a GPIO. This hardcoded value doesn't match what the firmware intended to be programmed in _AEI. The hardcoded debounce leads to problems waking from suspend. There isn't appetite to conditionalize the behavior in soc-button-array or gpio-keys so clear it when the system suspends to avoid problems with being able to resume. Cc: Dmitry Torokhov Cc: Hans de Goede Fixes: 5c4fa2a6da7fb ("Input: soc_button_array - debounce the buttons") Link: https://lore.kernel.org/linux-input/mkgtrb5gt7miyg6kvqdlbu4nj3elym6ijudobpdi26gp4xxay5@rsa6ytrjvj2q/ Link: https://lore.kernel.org/linux-input/20250625215813.3477840-1-superm1@kernel.org/ Signed-off-by: Mario Limonciello Reviewed-by: Hans de Goede Link: https://lore.kernel.org/20250627150155.3311574-1-superm1@kernel.org Signed-off-by: Linus Walleij Signed-off-by: Sasha Levin

pinctrl: amd: Take suspend type into consideration which pins are non-wake

2025-02-08T08:57:33+00:00

[ Upstream commit f31f33dbb3bab572bad9fe7b849ab0dcbe6fd279 ] Some laptops have pins which are a wake source for S0i3/S3 but which aren't a wake source for S4/S5 and which cause issues when left unmasked during hibernation (S4). For example HP EliteBook 855 G7 has pin #24 that causes instant wakeup (hibernation failure) if left unmasked (it is a wake source only for S0i3/S3). GPIO pin #24 on this platform is likely dedicated to WWAN XMM7360 modem since this pin triggers wake notify to WWAN modem's parent PCIe port. Fix this by considering a pin a wake source only if it is marked as one for the current suspend type (S0i3/S3 vs S4/S5). Since Z-wake pins only make sense at runtime these were excluded from both of suspend categories, so pins with only the Z-wake flag set are effectively treated as non-wake pins. Fixes: 2fff0b5e1a6b ("pinctrl: amd: Mask non-wake source pins with interrupt enabled at suspend") Signed-off-by: Maciej S. Szmigiero Reviewed-by: Mario Limonciello Link: https://lore.kernel.org/d4b2d076366fdd08a0c1cd9b7ecd91dc95e07269.1736184752.git.mail@maciej.szmigiero.name Signed-off-by: Linus Walleij Signed-off-by: Sasha Levin

genirq: Introduce IRQF_COND_ONESHOT and use it in pinctrl-amd

2024-03-25T22:45:21+00:00

There is a problem when a driver requests a shared interrupt line to run a threaded handler on it without IRQF_ONESHOT set if that flag has been set already for the IRQ in question by somebody else. Namely, the request fails which usually leads to a probe failure even though the driver might have worked just fine with IRQF_ONESHOT, but it does not want to use it by default. Currently, the only way to handle this is to try to request the IRQ without IRQF_ONESHOT, but with IRQF_PROBE_SHARED set and if this fails, try again with IRQF_ONESHOT set. However, this is a bit cumbersome and not very clean. When commit 7a36b901a6eb ("ACPI: OSL: Use a threaded interrupt handler for SCI") switched the ACPI subsystem over to using a threaded interrupt handler for the SCI, it had to use IRQF_ONESHOT for it because that's required due to the way the SCI handler works (it needs to walk all of the enabled GPEs before the interrupt line can be unmasked). The SCI interrupt line is not shared with other users very often due to the SCI handling overhead, but on sone systems it is shared and when the other user of it attempts to install a threaded handler, a flags mismatch related to IRQF_ONESHOT may occur. As it turned out, that happened to the pinctrl-amd driver and so commit 4451e8e8415e ("pinctrl: amd: Add IRQF_ONESHOT to the interrupt request") attempted to address the issue by adding IRQF_ONESHOT to the interrupt flags in that driver, but this is now causing an IRQF_ONESHOT-related mismatch to occur on another system which cannot boot as a result of it. Clearly, pinctrl-amd can work with IRQF_ONESHOT if need be, but it should not set that flag by default, so it needs a way to indicate that to the interrupt subsystem. To that end, introdcuce a new interrupt flag, IRQF_COND_ONESHOT, which will only have effect when the IRQ line is shared and IRQF_ONESHOT has been set for it already, in which case it will be promoted to the latter. This is sufficient for drivers sharing the interrupt line with the SCI as it is requested by the ACPI subsystem before any drivers are probed, so they will always see IRQF_ONESHOT set for the interrupt in question. Fixes: 4451e8e8415e ("pinctrl: amd: Add IRQF_ONESHOT to the interrupt request") Reported-by: Francisco Ayala Le Brun Signed-off-by: Rafael J. Wysocki Signed-off-by: Thomas Gleixner Reviewed-by: Linus Walleij Cc: 6.8+ # 6.8+ Closes: https://lore.kernel.org/lkml/CAN-StX1HqWqi+YW=t+V52-38Mfp5fAz7YHx4aH-CQjgyNiKx3g@mail.gmail.com/ Link: https://lore.kernel.org/r/12417336.O9o76ZdvQC@kreacher

pinctrl: amd: Add IRQF_ONESHOT to the interrupt request

2024-01-31T09:06:07+00:00

On some systems the interrupt is shared between GPIO controller and ACPI SCI. When the interrupt is shared with the ACPI SCI the flags need to be identical. This should fix the GPIO controller failing to work after commit 7a36b901a6eb ("ACPI: OSL: Use a threaded interrupt handler for SCI"). ``` [ 0.417335] genirq: Flags mismatch irq 9. 00000088 (pinctrl_amd) vs. 00002080 (acpi) [ 0.420073] amd_gpio: probe of AMDI0030:00 failed with error -16 ``` Cc: Rafael J. Wysocki Reported-by: Christian Heusel Closes: https://bugzilla.kernel.org/show_bug.cgi?id=218407 Fixes: 7a36b901a6eb ("ACPI: OSL: Use a threaded interrupt handler for SCI") Link: https://lore.kernel.org/linux-acpi/CAJZ5v0iRqUXeuKmC_+dAJtDBLWQ3x15n4gRH48y7MEaLoXF+UA@mail.gmail.com/T/#mc5506014141b61e472b24e095889535a04458083 Signed-off-by: Mario Limonciello Acked-by: Rafael J. Wysocki Tested-by: Christian Heusel Link: https://lore.kernel.org/r/20240123180818.3994-1-mario.limonciello@amd.com Signed-off-by: Linus Walleij

pinctrl: amd: Mask non-wake source pins with interrupt enabled at suspend

2023-12-04T14:46:02+00:00

If a pin isn't marked as a wake source processing any interrupts is just going to destroy battery life. The APU may wake up from a hardware sleep state to process the interrupt but not return control to the OS. Mask interrupt for all non-wake source pins at suspend. They'll be re-enabled at resume. Reported-and-tested-by: Marcus Aram Reported-and-tested-by: Mark Herbert Link: https://gitlab.freedesktop.org/drm/amd/-/issues/2812 Signed-off-by: Mario Limonciello Link: https://lore.kernel.org/r/20231203032431.30277-3-mario.limonciello@amd.com Signed-off-by: Linus Walleij

pinctrl: amd: Convert to platform remove callback returning void

2023-10-10T13:38:42+00:00

The .remove() callback for a platform driver returns an int which makes many driver authors wrongly assume it's possible to do error handling by returning an error code. However the value returned is ignored (apart from emitting a warning) and this typically results in resource leaks. To improve here there is a quest to make the remove callback return void. In the first step of this quest all drivers are converted to .remove_new(), which already returns void. Eventually after all drivers are converted, .remove_new() will be renamed to .remove(). Trivially convert this driver from always returning zero in the remove callback to the void returning variant. Signed-off-by: Uwe Kleine-König Link: https://lore.kernel.org/r/20231009083856.222030-9-u.kleine-koenig@pengutronix.de Signed-off-by: Linus Walleij

Merge tag 'pinctrl-v6.6-1' of git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-pinctrl

2023-08-31T02:36:19+00:00

Pull pin control updates from Linus Walleij: "We have some patches to DTS[I] files in arm and arm64 as well, that were merged here as DT headers were being changed. The most interesting stuff is the Intel Tangier chip support and AMLogic C3 in my opinion. No core changes this time. Drivers: - Intel Tangier SoC pin control support - AMLogic C3 SoC pin control support - Texas Instruments AM654 SoC pin control support - Qualcomm SM8350 and SM6115 LPASS (Low Power Audio Sub-System) pin control support - Qualcomm PMX75 and PM7550BA (Power Management) pin control support - Qualcomm PMC8180 and PMC8180C (Power Management) pin control support - DROP the Oxnas driver as there is not enough of community interest to keep carrying this ARM(11) port Enhancements: - Bias control in the MT7986 pin control driver - Misc device tree binding enhancements such as the Broadcom 11351 being converted to YAML - New macro: DEFINE_NOIRQ_DEV_PM_OPS() put to use - Clean up some SPDX headers - Handle non-unique devicetree subnode names in two Renesas drivers" * tag 'pinctrl-v6.6-1' of git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-pinctrl: (80 commits) pinctrl: mlxbf3: Remove gpio_disable_free() pinctrl: use capital "OR" for multiple licenses in SPDX dt-bindings: pinctrl: renesas,rza2: Use 'additionalProperties' for child nodes pinctrl: cherryview: fix address_space_handler() argument pinctrl: intel: consolidate ACPI dependency pinctrl: tegra: Switch to use DEFINE_NOIRQ_DEV_PM_OPS() helper pinctrl: renesas: Switch to use DEFINE_NOIRQ_DEV_PM_OPS() helper pinctrl: mvebu: Switch to use DEFINE_NOIRQ_DEV_PM_OPS() helper pinctrl: at91: Switch to use DEFINE_NOIRQ_DEV_PM_OPS() helper pinctrl: cherryview: Switch to use DEFINE_NOIRQ_DEV_PM_OPS() helper pm: Introduce DEFINE_NOIRQ_DEV_PM_OPS() helper pinctrl: mediatek: assign functions to configure pin bias on MT7986 pinctrl: mediatek: fix pull_type data for MT7981 dt-bindings: pinctrl: aspeed: Allow only defined pin mux node properties dt-bindings: pinctrl: Drop 'phandle' properties pinctrl: lynxpoint: Make use of pm_ptr() pinctrl: baytrail: Make use of pm_ptr() pinctrl: intel: Switch to use exported namespace pinctrl: lynxpoint: reuse common functions from pinctrl-intel pinctrl: cherryview: reuse common functions from pinctrl-intel ...

pinctrl: amd: Mask wake bits on probe again

2023-08-21T10:28:28+00:00

Shubhra reports that their laptop is heating up over s2idle. Even though it's getting into the deepest state, it appears to be having spurious wakeup events. While debugging a tangential issue with the RTC Carsten reports that recent 6.1.y based kernel face a similar problem. Looking at acpidump and GPIO register comparisons these spurious wakeup events are from the GPIO associated with the I2C touchpad on both laptops and occur even when the touchpad is not marked as a wake source by the kernel. This means that the boot firmware has programmed these bits and because Linux didn't touch them lead to spurious wakeup events from that GPIO. To fix this issue, restore most of the code that previously would clear all the bits associated with wakeup sources. This will allow the kernel to only program the wake up sources that are necessary. This is similar to what was done previously; but only the wake bits are cleared by default instead of interrupts and wake bits. If any other problems are reported then it may make sense to clear interrupts again too. Cc: Sachi King Cc: stable@vger.kernel.org Cc: Thorsten Leemhuis Fixes: 65f6c7c91cb2 ("pinctrl: amd: Revert "pinctrl: amd: disable and mask interrupts on probe"") Reported-by: Shubhra Prakash Nandi Closes: https://bugzilla.kernel.org/show_bug.cgi?id=217754 Reported-by: Carsten Hatger Link: https://bugzilla.kernel.org/show_bug.cgi?id=217626#c28 Signed-off-by: Mario Limonciello Link: https://lore.kernel.org/r/20230818144850.1439-1-mario.limonciello@amd.com Signed-off-by: Linus Walleij

pinctrl: amd: Don't show `Invalid config param` errors

2023-07-23T19:41:06+00:00

On some systems amd_pinconf_set() is called with parameters 0x8 (PIN_CONFIG_DRIVE_PUSH_PULL) or 0x14 (PIN_CONFIG_PERSIST_STATE) which are not supported by pinctrl-amd. Don't show an err message when called with an invalid parameter, downgrade this to debug instead. Cc: stable@vger.kernel.org # 6.1 Fixes: 635a750d958e1 ("pinctrl: amd: Use amd_pinconf_set() for all config options") Signed-off-by: Mario Limonciello Link: https://lore.kernel.org/r/20230717201652.17168-1-mario.limonciello@amd.com Signed-off-by: Linus Walleij

pinctrl: amd: Unify debounce handling into amd_pinconf_set()

2023-07-12T22:04:49+00:00

Debounce handling is done in two different entry points in the driver. Unify this to make sure that it's always handled the same. Tested-by: Jan Visser Signed-off-by: Mario Limonciello Link: https://lore.kernel.org/r/20230705133005.577-5-mario.limonciello@amd.com Signed-off-by: Linus Walleij