stm32: Detach GPIO IRQ callbacks upon clearing "setevent"#19520
Open
Javinator9889 wants to merge 2 commits into
Open
stm32: Detach GPIO IRQ callbacks upon clearing "setevent"#19520Javinator9889 wants to merge 2 commits into
Javinator9889 wants to merge 2 commits into
Conversation
Javinator9889
requested review from
jerpelea,
raiden00pl and
xiaoxiang781216
as code owners
July 24, 2026 10:31
Javinator9889
force-pushed
the
bugfix/stm32_detach_callbacks_upon_gpio_clearing
branch
from
July 24, 2026 10:31
d6efcec to
be784d2
Compare
github-actions
Bot
added
Arch: arm
When the interrupts get disabled, the callback(s) are still attached. That structure is never cleared, causing several calls to attach/detach to eventually fail as the callback queue gets full. When the error occurs, the registration fails with error 12 (ENOMEM). By detaching the IRQ and clearing the callbacks, this error doesn't happen again Signed-off-by: Javier Alonso <javieralonso@geotab.com>
Javinator9889
force-pushed
the
bugfix/stm32_detach_callbacks_upon_gpio_clearing
branch
from
July 24, 2026 10:39
be784d2 to
577bf5a
Compare
github-actions
Bot
added
Size: S
|
xiaoxiang781216
previously approved these changes
Jul 24, 2026
raiden00pl
reviewed
Jul 24, 2026
|
|
||
| if (i == nshared) | ||
| { | ||
| /* remove any leftover callback */ |
Member
There was a problem hiding this comment.
could you port this change to all STM32 ports? it can be simple copy-paste, all STM32 use the same driver for EXTI GPIO.
- src/common/stm32/stm32_exti_gpio_m3m4_v1v2.c
- src/stm32f7/stm32_exti_gpio.c
- src/stm32h7/stm32_exti_gpio.c
- src/stm32l4/stm32l4_exti_gpio.c
- src/stm32l5/stm32l5_exti_gpio.c
- src/stm32u5/stm32_exti_gpio.c
- src/stm32wb/stm32wb_exti_gpio.c
- src/stm32wl5/stm32wl5_exti_gpio.c
Contributor
Author
There was a problem hiding this comment.
Sure thing, let me populate the change to those files as well :)
I just populated it on the STM32G0 because it's the one I have to test. I guess others will work just fine as the change is self contained
The fix was ported from the STM32G0 to all the STM32 platforms, as the code is mostly the same hence presents the same failure Signed-off-by: Javier Alonso <javieralonso@geotab.com>
Javinator9889
force-pushed
the
bugfix/stm32_detach_callbacks_upon_gpio_clearing
branch
from
July 24, 2026 12:13
ed0134f to
33d7af4
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
When the interrupts get disabled, the callback(s) are still attached. That structure is never cleared, causing several calls to attach/detach to eventually fail as the callback queue gets full.
When the error occurs, the registration fails with error 12 (ENOMEM). By detaching the IRQ and clearing the callbacks, this error doesn't happen again
Impact
Calling
stm32_gpioseteventseveral times enabling and disabling the event ends up fulling the callback's queue, causing future calls to fail withENOMEMwithout recovering from the error.Testing
This has been tested thoroughly by attaching/detaching the events several times in a row. The behavior is now deterministic and one can add and remove GPIO events as much as wanted