Re: [PATCH] riscv: Populate boot CPU topology on UP kernels

[Conor Dooley]

On Tue, Oct 20, 2026 at 10:26:26PM +0800, Chen Pei wrote:
> On Tue, Oct 20, 2026 at 01:24:00PM +0100, Sudeep Holla wrote:
> > Commit 4b3dc9679cf7 ("arm64: force CONFIG_SMP=y and remove redundant #ifdefs")
> > removed UP support and made SMP default enabled.

Ah yes, I forgot about this..

> Thanks. RISC-V still allows UP: CONFIG_SMP is a plain bool with no
> default, yet arch/riscv/Kconfig selects GENERIC_ARCH_TOPOLOGY
> unconditionally while the only callers of init_cpu_topology() and
> store_cpu_topology() sit in smpboot.c, which is built only for
> CONFIG_SMP. That mismatch is what this patch closes.
> 
> Gating that select on SMP instead does not work. UP would then fall back
> to the cpumask_of(cpu) defaults in include/linux/topology.h and report
> the same sysfs, but vmlinux no longer links: arch_freq_scale,
> capacity_freq_ref, topology_scale_freq_tick and topology_set_freq_scale
> all become undefined references.
> 
> arch/riscv/include/asm/topology.h binds the arch_scale_freq_* and
> arch_set_freq_scale hooks to symbols that only drivers/base/arch_topology.c
> provides, and those defines suppress the generic fallbacks in
> kernel/sched/sched.h and include/linux/sched/topology.h. Making the
> gating work needs extra conditionals at several Kconfig and Makefile
> gates, and gives up freq and capacity invariance on UP, which is a much
> larger change than the twelve lines here.
> 
> Conor, and RISC-V maintainers: would you rather force CONFIG_SMP=y on
> RISC-V as well and drop UP altogether, or keep UP buildable and take
> this fix? I would keep the current approach unless you prefer the
> former.

I think we probably should drop CONFIG_SMP=N, but this patch would be
needed as a fix regardless since making SMP mandatory would be for 7.5
or later whereas fixing this is 7.4-rc content and should probably be
backported to stable.

FWIW, the patch looks reasonable to me, I was just wondering why arm64
didn't need it.
Reviewed-by: Conor Dooley <conor.dooley@xxxxxxxxxxxxx>

Thanks,
Conor.

Attachment: signature.asc
Description: PGP signature