-
Notifications
You must be signed in to change notification settings - Fork 6.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
drivers: STM32 dualcore concurrent register access protection with HSEM #24862
drivers: STM32 dualcore concurrent register access protection with HSEM #24862
Conversation
All checks are passing now. Tip: The bot edits this comment instead of posting a new one, so you can check the comment's history to see earlier messages. |
3bb5ece
to
02e63af
Compare
02e63af
to
a45e947
Compare
a45e947
to
b7431a6
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Multiple functions have an exit path while the lock is still held. These should be fixed.
Also it appears that there are nested lock calls; I don't know the hardware to say whether this is safe.
a0c2f13
to
56f51c7
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
One clear problem newly identified, and an overall impression that the solution needs to be reconsidered to take into account protecting the lock status from mutation by interrupts. The latter is outside my area of expertise.
56f51c7
to
bb063fc
Compare
bb063fc
to
6102ba1
Compare
6102ba1
to
85b40a7
Compare
I made a rebase of this PR. |
85b40a7
to
ed06b8f
Compare
631a94f
to
a928170
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just commentary: I don't have expertise to judge the technical merit of this SOC-specific solution.
I've removed my NAK under the assumption that the mis-ordered lock sequences have been fixed, and each lock is paired with an unlock (no early exits/inappropriate nested locking). From a cursory look only at the diffs github provides this seems to be true, but I have not looked at the unmodified areas of the code to confirm it.
I find it confusing that z_stm32_hsem_lock
is paired with z_stm32_hsem_release
. Pairing lock
with unlock
, or request
with release
, would make be more consistent with existing usage (request/release only if the lock is recursive, but I think it isn't). Since this is STM32-specific API I don't insist on this.
a928170
to
50a581d
Compare
I replaced |
Sanitychek failure: ' Sanitycheck / qemu_arc_hs:tests/portability/cmsis_rtos_v1/portability.cmsis_rtos_v1 / tests/portability/cmsis_rtos_v1/portability.cmsis_rtos_v1' |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
just a minor comment, else LGTM
50a581d
to
6c6e445
Compare
In case of dualcore, STM32H7, STM32W and STM32MP1, protect concurrent register write access with HSEM. Done for following drivers: clock_control, counter, flash, gpio, interrupt_controller Signed-off-by: Alexandre Bourdiol <[email protected]>
6c6e445
to
8a51ebf
Compare
Due to HSEM implementation zephyrproject-rtos#24862, USB CLK48 lock implementation zephyrproject-rtos#25850 should be reworked. And by the way, implement the same in entropy which is using the same clock. Signed-off-by: Alexandre Bourdiol <[email protected]>
Due to HSEM implementation #24862, USB CLK48 lock implementation #25850 should be reworked. And by the way, implement the same in entropy which is using the same clock. Signed-off-by: Alexandre Bourdiol <[email protected]>
In case of dualcore, STM32H7, STM32W and STM32MP1,
protect concurrent register write access with HSEM.
Done for following drivers:
clock_control, counter, flash, gpio, interrupt_controller
Signed-off-by: Alexandre Bourdiol [email protected]