libusbclient/stm32n6: fix interrupt handler races

[jakubsmolaga]

TASK: PP-403

Description

This change fixes potential read-modify-write races inside the low frequency interrupt handler

Motivation and Context

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)
• Chore (refactoring, style fixes, git/CI config, submodule management, no code logic changes)

How Has This Been Tested?

• Already covered by automatic testing.
• New test added: (add PR link here).
• Tested by hand on: armv8m-stm32n6.

Checklist:

• My change requires a change to the documentation.
• I have updated the documentation accordingly.
• I have added tests to cover my changes.
• All new and existing linter checks and tests passed.
• My changes generate no new compilation warnings for any of the targets.

Special treatment

• This PR needs additional PRs to work (list the PRs, preferably in merge-order).
• I will merge this PR by myself when appropriate.

[github-actions]

Unit Test Results

10 463 tests  ±0   9 801 ✅ ±0   52m 32s ⏱️ -17s
   629 suites ±0     662 💤 ±0 
     1 files   ±0       0 ❌ ±0 

Results for commit e3e4844. ± Comparison against base commit 9888dbe.

[gemini-code-assist]

Code Review

This pull request introduces atomic operations for interrupt handling in the STM32N6 USB client driver. Key changes include converting pending_event, irqPendingDIEPINT, and irqPendingDOEPINT to _Atomic types and using atomic_exchange to safely retrieve and clear pending flags in a single operation. As a result, ctrl_lifiq_handler has been updated to accept the interrupt status by value, and manual bit-clearing logic within the interrupt handlers has been removed to simplify the code and improve thread safety. I have no feedback to provide.

[agkaminski]

LGTM

[jmaksymowicz]

Maybe use the atomic_uint type from stdatomic.h instead? It's best to avoid using attributes that start with with underscores directly.

[jakubsmolaga]

I just wanted to clearly communicate the intention that "this must be a 32bit unsigned integer", since it reflects the value of hw registers. Obviously atomic_uint will be the exact same type since unsigned int is 32bit on pretty much every sensible platform but I just wasn't sure if the intention is clear enough that way.

From my understanding the main problem with using _Atomic is that it breaks compatibility with C++ since C++ uses std::atomic<T> instead of _Atomic. I'm not sure how much of an issue that is for us.

Anyway, I'm ok with changing it but I just wanted to express my thoughts and hear what you have to say before committing the change blindly.