Re: [PATCH] common: board_f: Fix crash in print_cpuinfo
Hi Christian, On Thu, 29 Sept 2022 at 08:24, Christian Kohlschütter wrote: > > > On 29. Sep 2022, at 04:36, Simon Glass wrote: > > > > Hi Christian, > > > > On Wed, 28 Sept 2022 at 18:20, Christian Kohlschütter > > 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 > >> --- > >> 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
Re: [PATCH] common: board_f: Fix crash in print_cpuinfo
> On 29. Sep 2022, at 04:36, Simon Glass wrote: > > Hi Christian, > > On Wed, 28 Sept 2022 at 18:20, Christian Kohlschütter > 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 >> --- >> 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.
Re: [PATCH] common: board_f: Fix crash in print_cpuinfo
Hi Christian, On Wed, 28 Sept 2022 at 18:20, Christian Kohlschütter 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 > --- > 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
