Hi Christian,
On Thu, 29 Sept 2022 at 08:24, Christian Kohlschütter christian@kohlschutter.com wrote:
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?
It really depends on when people send patches for it. You could send something to help here.
I'm specifically asking because the new feature may help improve the coverage of smbios information available downstream.
OK
Regards, Simon