-
Notifications
You must be signed in to change notification settings - Fork 349
Pretend unused slots presence in dictionaries from extended manifest #3691
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
Conversation
src/init/ext_manifest.c
Outdated
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 wondering here if we can use a linker variable here for CONFIG_ELEM_COUNT as a way to automate this as it may be error prone for developers i.e. something cmake can pass into the linker pre-processor and have the linker set this based on the FW binary build ???
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.
@ktrzcinx agreed with Liam, we can try to use some trick with enum like
| sizeof(struct config_elem) * CONFIG_ELEM_CNT, | |
| sizeof(struct config_elem) * (EXT_MAN_CONFIG_LAST_ELEM - 1), |
You do not need to update the EXT_MAN_CONFIG_LAST_ELEM or CONFIG_ELEM_CNT if we add a new type
xiulipan
left a comment
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 think we can keep EXT_MAN_*_LAST_ELEM and calculated the CNT with (LAST_ELEM - 1)
No need to update the CNT anymore if we add new enum.
src/init/ext_manifest.c
Outdated
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.
@ktrzcinx agreed with Liam, we can try to use some trick with enum like
| sizeof(struct config_elem) * CONFIG_ELEM_CNT, | |
| sizeof(struct config_elem) * (EXT_MAN_CONFIG_LAST_ELEM - 1), |
You do not need to update the EXT_MAN_CONFIG_LAST_ELEM or CONFIG_ELEM_CNT if we add a new type
…ig_data This value shouldn't be included in any ABI header, because it may vary between firmware configurations. This change makes header file more similar to version provided by kernel. Signed-off-by: Karol Trzcinski <karolx.trzcinski@linux.intel.com>
…ifest This value should be included to output image with proper value instead of including only for some configurations. It will reduce dictionary element counting complexity. Signed-off-by: Karol Trzcinski <karolx.trzcinski@linux.intel.com>
…_config_data This value shouldn't be included in any ABI header, because it may vary between firmware configurations. This change makes header file more similar to version provided by kernel. Signed-off-by: Karol Trzcinski <karolx.trzcinski@linux.intel.com>
24c7796 to
7e9fd5d
Compare
xiulipan
left a comment
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.
LGTM not. I am OK to have a more clear define for the COUNT.
|
@ktrzcinx can you check internal CI, looks like tests are failing ? |
|
@lgirdwood @ktrzcinx I re-check our discussion in #3527 |
|
@lgirdwood @ktrzcinx Good to go, simple on-device test did not show issue with GCC FW binary. |
|
@lgirdwood in internal CI single test is failing with message |
|
@zrombel good to merge, this error is unrelated ? |
|
It seemed unrelated. I run tests one again to be sure and now it's all green. Good to merge. |
Solution extracted from discussion from #3527