On 29. Sep 2022, at 04:36, Simon Glass sjg@chromium.org wrote:
Hi Christian,
On Wed, 28 Sept 2022 at 18:20, Christian Kohlschütter christian@kohlschutter.com wrote:
With CONFIG_DISPLAY_CPUINFO=y and CONFIG_CPU=y, the initcall sequence may fail (and therefore hang the boot process) with an -ENODEV (err=-19) error code.
This is caused by either cpu_get_current_dev/cpu_get_desc failing to return CPU information.
If no CPU information can be obtained, fall-back to the non-Driver Model implementation of print_cpuinfo.
Signed-off-by: Christian Kohlschütter christian@kohlschutter.com
common/board_f.c | 14 +++++++++----- include/init.h | 3 +-- 2 files changed, 10 insertions(+), 7 deletions(-)
No, we don't want to do this. If you have CPU enabled then the device must return the info. The non-DM code will go away one day. It is not intended as a fallback.
Regards, Simon
Thanks for the clarification, Simon. That's what I thought (it's not really documented with CONFIG_CPU but I get the idea).
It looks like the new CONFIG_CPU feature isn't really supported for ARM boards, and the existing print_cpuinfo shows additional information that may not be captured with the new setup, such as "reset cause", etc. What are the plans/timeline for implementing the new feature?
I'm specifically asking because the new feature may help improve the coverage of smbios information available downstream.