From: Yao Zi <me@ziyao.cc>
To: Michal Simek <michal.simek@amd.com>, u-boot@lists.denx.de, git@amd.com
Cc: Leo <ycliang@andestech.com>, Rick Chen <rick@andestech.com>,
Tom Rini <trini@konsulko.com>
Subject: Re: [PATCH] riscv: Skip riscv_cpu_setup() when CPU driver is disabled
Date: Mon, 4 May 2026 20:16:40 +0000 [thread overview]
Message-ID: <afj-qK8yzyGwn1bi@pie> (raw)
In-Reply-To: <45470f5f-f0f6-47f4-b87e-4c4c5d0cc9b8@amd.com>
On Mon, May 04, 2026 at 11:00:17AM +0200, Michal Simek wrote:
>
>
> On 5/1/26 10:54, Yao Zi wrote:
> > On Thu, Apr 30, 2026 at 01:57:51PM +0200, 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.
> > >
> > > 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>
> > > ---
> > >
> > > 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;
> >
> > Should we return zero here, or -ENOENT like the original behavior when
> > no UCLASS_CPU device is found?
My bad, the original return value when CONFIG_CPU is disabled should be
-ENODEV instead of -ENOENT. But in case that CONFIG_CPU is disabled,
-EOPNOTSUPP might be a better outcome. I don't have a strong opinion on
this.
> if you put there error value then when CONFIG_CPU is disable you get boot
> hang which is likely what you don't want to see right?
>
> initcall_run_f(): initcall initf_dm() failed
> ### ERROR ### Please RESET the board ###
This should be the original behavior, i.e. U-Boot built with
CONFIG_CPU=n and CONFIG_EVENT=y is broken without this patch, too,
right?
int riscv_cpu_setup(void)
{
int ret = -ENODEV, ext_count, i;
const char *isa, **exts;
struct udevice *dev;
uclass_find_first_device(UCLASS_CPU, &dev);
if (!dev) {
debug("unable to find the RISC-V cpu device\n");
return ret;
}
...
}
EVENT_SPY_SIMPLE(EVT_DM_POST_INIT_F, riscv_cpu_setup);
When CONFIG_CPU is disabled, the call to uclass_find_first_device()
would always find no device, and riscv_cpu_setup() would return with
-ENODEV, causing the call to event_notify_null() in dm_init_and_scan()
to fail. We could fix this by guarding the instantiation of
EVENT_SPY_SIMPLE() within #if CONFIG_IS_ENABLED(CPU).
I consider returning with error a useful behavior, since there are raw
calls to this function (board/[starfive,thead]/*/spl.c), in which cases
a correct return value suggests something goes wrong, thus might help
debugging, for example, if someone turns off CONFIG_CPU but doesn't
expect the side effects.
Anyway, whether you agree on the return value or not, it should be
mentioned in the commit message that U-Boot built with CONFIG_CPU=n and
COFNIG_EVENT=y is broken without the patch.
> Thanks,
> Michal
Best regards,
Yao Zi
prev parent reply other threads:[~2026-05-04 20:17 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-04-30 11:57 [PATCH] riscv: Skip riscv_cpu_setup() when CPU driver is disabled Michal Simek
2026-05-01 8:54 ` Yao Zi
2026-05-04 9:00 ` Michal Simek
2026-05-04 20:16 ` Yao Zi [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=afj-qK8yzyGwn1bi@pie \
--to=me@ziyao.cc \
--cc=git@amd.com \
--cc=michal.simek@amd.com \
--cc=rick@andestech.com \
--cc=trini@konsulko.com \
--cc=u-boot@lists.denx.de \
--cc=ycliang@andestech.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.