Re: [PATCH v2] riscv: Skip riscv_cpu_setup() when CPU driver is disabled

[Michal Simek <michal.simek@amd.com>]

Hi Tim,

actually not sure why this was off the list. Let me add it.


On 7/2/26 13:26, Michal Simek wrote:
> 
> 
> On 7/2/26 10:57, Tim Ouyang wrote:
>> On Mon, Jun 29, 2026 at 11:00:40AM +0200, Michal Simek wrote:
>>> On 5/11/26 10:31, Michal Simek wrote:
>>>> Building on commit c64fc632a86a ("riscv: cpu: Use CONFIG_IS_ENABLED(CPU)
>>>> instead of plain ifdef"), add an early return in riscv_cpu_setup() when
>>>> CONFIG_CPU is not enabled. This allows platforms to save code space in
>>>> SPL by disabling CONFIG_SPL_CPU.
>>>>
>>>> Without this patch, building U-Boot with CONFIG_CPU=n and CONFIG_EVENT=y
>>>> is broken: riscv_cpu_setup() is registered as an EVT_DM_POST_INIT_F event
>>>> spy, and when the CPU uclass is unavailable uclass_find_first_device()
>>>> returns no device, so the function returns -ENODEV. That in turn makes
>>>> event_notify_null() in dm_init_and_scan() fail and triggers a boot hang
>>>> ("initcall initf_dm() failed"). Returning 0 early avoids that failure.
>>>>
>>>> The compiler's dead-code elimination combined with --gc-sections
>>>> removes the unreachable code and all associated static data,
>>>> achieving significant size reduction without preprocessor guards:
>>>>
>>>>     spl/u-boot-spl:all -4332 spl/u-boot-spl:rodata -2872
>>>>     spl/u-boot-spl:text -1460
>>>>
>>>> Signed-off-by: Michal Simek <michal.simek@amd.com>
>>>> Reviewed-by: Yao Zi <me@ziyao.cc>
>>>> ---
>>>>
>>>> Changes in v2:
>>>> - extend commit message
>>>>
>>>>    arch/riscv/cpu/cpu.c | 3 +++
>>>>    1 file changed, 3 insertions(+)
>>>>
>>>> diff --git a/arch/riscv/cpu/cpu.c b/arch/riscv/cpu/cpu.c
>>>> index bbadd0c9a469..3bec7c7cb6d0 100644
>>>> --- a/arch/riscv/cpu/cpu.c
>>>> +++ b/arch/riscv/cpu/cpu.c
>>>> @@ -638,6 +638,9 @@ int riscv_cpu_setup(void)
>>>>        const char *isa, **exts;
>>>>        struct udevice *dev;
>>>>
>>>> +     if (!CONFIG_IS_ENABLED(CPU))
>>>> +             return 0;
>>>> +
>>>>        uclass_find_first_device(UCLASS_CPU, &dev);
>>>>        if (!dev) {
>>>>                debug("unable to find the RISC-V cpu device\n");
>>>
>>> Can you please take it directly to next branch?
>>>
>>> Thanks,
>>> Michal
>>
>> Hi Michal,
>>
>> The new RISC-V maintainer here. It seems your patch does not fix the
>> issue. I tested it with the following steps:
>> - mkdir -p $OUTPUT/test
>> - make qemu-riscv64_spl_defconfig O=$OUTPUT/test CROSS_COMPILE=riscv64-linux-
>> - make menuconfig O=$OUTPUT/test CROSS_COMPILE=riscv64-linux-
>>    Disable CONFIG_CPU manually
>> - make O=$OUTPUT/test CROSS_COMPILE=riscv64-linux-
>>
>> The build fails with:
>> riscv64-linux-ld: common/board_f.o: in function `initcall_run_f':
>> /work/u-boot-riscv/common/board_f.c:921:(.text.board_init_f+0x166): undefined 
>> reference to `print_cpuinfo'
>> riscv64-linux-ld: drivers/timer/riscv_aclint_timer.o: in function 
>> `riscv_aclint_timer_probe':
>> /work/u-boot-riscv/drivers/timer/riscv_aclint_timer.c:77: 
>> (.text.riscv_aclint_timer_probe+0x24): undefined reference to 
>> `timer_timebase_fallback'
>> make[1]: *** [/work/u-boot-riscv/Makefile:2112: u-boot] Error 1
>>
>> Please correct me if I missed something.
> 
> It is not valid configuration because dependencies are not properly described in 
> Kconfig.
> drivers/timer/riscv_aclint_timer.c
> calls timer_timebase_fallback() which is defined in drivers/timer/timer-uclass.c
> as
>   90 #if CONFIG_IS_ENABLED(CPU)
>   91 int timer_timebase_fallback(struct udevice *dev)
>   92 {
> 
> It means for this risc-v configuration in Kconfig when aclint_timer is selected 
> it has to depends on CONFIG_CPU/CONFIG_SPL_CPU or should select it by default.
> 
> Microblaze-V is not using this timer that's why no problem to disable it.
> 
> 
> And the second issue around print_cpuinfo. When you disable CPU likely you need 
> to also disable CONFIG_DISPLAY_CPUINFO. CONFIG_CPU is uclass but if you grep it 
> I wouldn't be surprised that there are still platform which are able to print 
> information about cpu without enabling cpu uclass. That's why there is not 
> dependency between CONFIG_DISPLAY_CPUINFO and CONFIG_CPU.

Any reaction?

Thanks,
Michal