Skip to content

zephyr: pm_runtime: use the correct type for CPU power state count #10860

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.

Sign up for GitHub

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

Merged
lgirdwood merged 1 commit into from
Jun 12, 2026
Merged

zephyr: pm_runtime: use the correct type for CPU power state count #10860

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
4 changes: 2 additions & 2 deletions zephyr/lib/pm_runtime.c
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -21,12 +21,12 @@ DECLARE_TR_CTX(power_tr, SOF_UUID(power_uuid), LOG_LEVEL_INFO);
#if defined(CONFIG_PM_POLICY_CUSTOM)
const struct pm_state_info *pm_policy_next_state(uint8_t cpu, int32_t ticks)
{
unsigned int num_cpu_states;
uint8_t num_cpu_states;
const struct pm_state_info *cpu_states;

num_cpu_states = pm_state_cpu_get_all(cpu, &cpu_states);

for (int i = num_cpu_states - 1; i >= 0; i--) {
for (int i = (int)num_cpu_states - 1; i >= 0; i--) {

@lyakh lyakh Jun 10, 2026

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

what exactly problem is this addressing? If num_cpu_states is returned as 0, then i is assigned -1, so this loop isn't run at all as it should. If pm_state_cpu_get_all() returns something like 254 the old code would run the loop 254 times, while the new one will convert that to -2 and not run at all (if my mental integer conversions are right). Neither of those cases seem particularly meaningful. If it returns 127, the behaviour would be the same... So what is this fixing?

@abonislawski abonislawski Jun 10, 2026

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Integer overflow.
In original code for 0 this will hit UINT_MAX and out-of-range unsigned→signed conversion (implementation-defined in C, pre-C23). This is well-defined in gcc and xtensa so there is no real impact/issue here, just a better code with proper matching return type from pm_state_cpu_get_all() like in reference zephyr pm policy.

@lyakh lyakh Jun 12, 2026

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

alright... So in theory, compilers, implementing older than C23 C standards (but I suppose they're still in active use, since the standard is apparently only 3 years old?) could convert int i = UINT_MAX to something different than -1... interesting. Would just changing the type of num_cpu_states to int fix this too? With no type-casting then?

const struct pm_state_info *state = &cpu_states[i];
uint32_t min_residency, exit_latency;

Expand Down
Loading