[PATCH] common: board_f: Fix crash in print_cpuinfo

[Simon Glass]

Hi Christian,

On Thu, 29 Sept 2022 at 08:24, Christian Kohlschütter
<christian at kohlschutter.com> wrote:
>
> > On 29. Sep 2022, at 04:36, Simon Glass <sjg at chromium.org> wrote:
> >
> > Hi Christian,
> >
> > On Wed, 28 Sept 2022 at 18:20, Christian Kohlschütter
> > <christian at 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 at 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