-
Notifications
You must be signed in to change notification settings - Fork 6.5k
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
arch: arm: Add z_arch_irq_current_prio function #17301
arch: arm: Add z_arch_irq_current_prio function #17301
Conversation
93883a8
to
f6cc41a
Compare
f6cc41a
to
8d560ab
Compare
What is the use case of this ARM-only aPI? |
See #17293 Function should not be called from interrupt priority higher than clock control because it may lead to deadlock since clock state will never be updated if status is read in a loop waiting for clock on and clock interrupt cannot be handled (since it has lower priority). It maybe extended to other platforms as well if there is a use case. |
Right, I need to think how this works with trustzone, there are some tricky parts there |
8d560ab
to
9950efb
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.
I'd rather you called this z_arm_irq_current_prio() since unlike the other z_arch_* APIs there is no generic kernel API that calls it and this is only implemented on ARM.
Agree on the naming. Further, if the only use of this is an assert to catch priority inversion bugs, can't you do that via static analysis? For example, just make sure clock_control is at the highest available priority. |
9950efb
to
553397b
Compare
Done
I wouldn't like to force that to the user, especially that this does not help if context is on the same highest, priority level. |
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 to contribute to the "api" discussion - would it be better to name this as bool irq_can_preempt(irq_line)
or something like that? This looks more close to what you want to have for your use-case, right?
@ioannisg you mean that function would check if current context can be preempted by given interrupt? |
Yes, that's what I meant. |
553397b
to
3cbfa04
Compare
@ioannisg changed as you suggested to |
All checks are passing now. Review history of this comment for details about previous failed status. |
3cbfa04
to
aea435e
Compare
|
||
bool z_arm_irq_can_preempt(u32_t irq_line) | ||
{ | ||
return z_arm_irq_current_prio() > NVIC_GetPriority((IRQn_Type)irq_line); |
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.
Is this really what we want, here? What if the irq_line is, in fact, not enabled, and the priority is a trash value? Can this actually happen?
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.
current use case is using it in the driver which handles irq_line
. I wouldn't involve enabling checking into that. What to return if interrupt is disabled? false
would be correct because disabled interrupt cannot be preempt current context but that is not what we wanted to check.
By default priority in nvic is set to 0 (highest). I can add a note that only priority is checked and not the state of the interrupt.
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.
This all depends on what API we want to provide, see the discussion below. So, if the irq_line is not enabled, this function should return false; that's my opinion. And of course, we document this nicely. Since we named it as _can_preempt(), we need to see if it can really preempt..
@@ -153,8 +153,19 @@ extern void z_irq_spurious(void *unused); | |||
extern void _isr_wrapper(void); | |||
#endif | |||
|
|||
/** |
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.
What we really need to decide for the API, is;
- can be called by interrupts?
- should it be thread-safe or don't care?
- could it be generalized for all ARCHEs?
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.
can be called by interrupts?
yes
should it be thread-safe or don't care?
I would say don't care. Are we afraid that interrupt priority level will change after that call? How likely is that?
could it be generalized for all ARCHEs?
when use case comes some will do that. I wouldn't like to see PR pending on other platforms implementation when current use case is for peripheral driver on arm cortex.
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.
I agree that this should be called by interrupts. We shall document that.
Also, it is fine if this is an arm-only API: we call the function z_arm_xxx and we can use a z_arch_ static inline function in include/arch/arm.
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.
I would say don't care. Are we afraid that interrupt priority level will change after that call? How likely is that?
Now, this is problematic. If we make an API that checks if we can be preempted, we need to make sure this works in a deterministic way. I thought about it, and I don't want this to be fuzzy. We need to make this thread-safe, right?
Added function for checking if current context can be preempted by given interrupt. Signed-off-by: Krzysztof Chruscinski <[email protected]>
Extended arm_irq_vector_table test to verify z_arm_irq_can_preempt function. Signed-off-by: Krzysztof Chruscinski <[email protected]>
Added a simulation replacement for NVIC_GetPriority() + Added a function (like for ARM) to check if current context can be preempted by given interrupt. Signed-off-by: Alberto Escolar Piedras <[email protected]>
aea435e
to
7dedcee
Compare
@andyross could you please review this? |
Will you continue working on this @nordic-krch or should we close the PR? |
will close it for now. Maybe feature need will come back. |
Added function and extended test to cover new api.