[BUG i.MX] warning: the int symbol CORE_COUNT has a non-int default MP_NUM_CPUS

[dbaluta]

Describe the bug

When compiling the firmware for i.MX8 platforms we get the following warning:

(warning: the int symbol CORE_COUNT (defined at src/platform/Kconfig:307) has a non-int default MP_NUM_CPUS (undefined))

To Reproduce

$ ./scripts/xtensa-build-all.sh imx8m

Reproduction Rate

Always

Expected behavior
Compiling the i.MX8 firmware should not produce a warning.

Impact
It is annoying.

Environment

1. Branch name and commit hash of the 2 repositories: sof (firmware/topology) and linux (kernel driver).
   • Kernel: dont'care
   • SOF: main
2. Name of the topology file
   • Topology: don't care
3. Name of the platform(s) on which the bug is observed.
   • Platform: i.MX8/i.MX8X/i.MX8M

[paulstelian97]

I have done a little bit of digging, the warning comes from the fact that kconfiglib does not check the "if" conditions on defaults when validating. When actually generating the configuration a correct .config file is created anyway, as this validation is a separate pass.

sof/scripts/kconfig/kconfiglib.py

Line 3420 in b9623d0

self._warn("the {0} symbol {1} has a non-{0} default {2}"

is the origin of the warning message. A simple visual inspection of the code around that line reveals that no such checking of the "if" condition of any defaults is done. Further, I have searched for the original Kconfiglib implementation, and it also manifests this issue.

I have not verified how the Linux kernel (C based) implementation of Kconfig behaves yet, so I don't know if it's a bug or an intended feature of Kconfiglib.

I have reproduced it on i.MX8QM as well.

CC @iuliana-prodan

[paulstelian97]

I'm seeing two different solutions. A simpler one makes for a wordier Kconfig, and a more complicated one to be done inside kconfiglib.py itself to skip checks for defaults that are false. I'll probably propose the simple fix but keep this issue open once that is merged.

[lgirdwood]

@paulstelian97 is there any Zephyr Kconfig symbol we can reuse and deprecate any duplication we have ?

[paulstelian97]

@paulstelian97 is there any Zephyr Kconfig symbol we can reuse and deprecate any duplication we have ?

We can probably define MP_NUM_CPUS manually in our xtos builds as well, which makes the conditional default be unnecessary, and have MAX_CORE_COUNT be an alias for that. Or define MAX_CORE_COUNT in terms of MP_NUM_CPUS on Zephyr and manually otherwise (but with care, otherwise we just move this issue somewhere else)

[paulstelian97]

A proposed solution (partial) is pull request #6614. It needs more work but it's a start and it's already sufficient to remove the warning.

[marc-hb]

This is not specific to IMX, I have seen this warning on all Intel platforms since forever.

[marc-hb]

inside kconfiglib.py

BTW I suspect ours is out of date compared to the Zephyr one.

[paulstelian97]

inside kconfiglib.py

BTW I suspect ours is out of date compared to the Zephyr one.

While I haven't checked the Zephyr one, I have looked at an upstream one and it still seems to have the code structured the same way, which leads to still having the issue. Do you know of Zephyr having its own patches on top of kconfiglib.py?

[marc-hb]

I forgot kconfiglib.py had its own git repo, sorry for the confusion. In the past kconfiglib.py was designed by and for Zephyr so the Zephyr copy would have always been fairly up to date and with very few "downstream" changes if any. Then the developer left and the project became orphaned (ulfalizer/Kconfiglib#121). So not sure about now, should be easy to check with the usual diff, git log etc.

EDIT: there's a new volunteer to maintain kconfiglib: ulfalizer/Kconfiglib#121

I see some recent changes in https://github.com/zephyrproject-rtos/zephyr/commits/main/scripts/kconfig but not many.

[paulstelian97]

The actual code interesting to us looks basically identical so the Zephyr kconfiglib should also manifest the issue (at least that's what I'd expect, but it can be checked I guess)