From: Yao Zi <me@ziyao.cc>
To: Simon Glass <sjg@chromium.org>, me@ziyao.cc
Cc: Tom Rini <trini@konsulko.com>,
Jiaxun Yang <jiaxun.yang@flygoat.com>,
Heinrich Schuchardt <xypron.glpk@gmx.de>,
Ilias Apalodimas <ilias.apalodimas@linaro.org>,
u-boot@lists.denx.de
Subject: Re: [PATCH v2 01/16] lib: fdtdec: Handle multiple memory nodes
Date: Thu, 2 Jul 2026 20:39:07 +0000 [thread overview]
Message-ID: <akbGWWq3kQZERfOD@pie> (raw)
In-Reply-To: <CAFLszThfvoqgsTwZcmmR7+feYM80wUhH0n6=RdBPW47+Nv=YAw@mail.gmail.com>
On Thu, Jul 02, 2026 at 11:22:14AM +0100, Simon Glass wrote:
> Hi Jiaxun,
>
> On 2026-07-01T11:17:53, Yao Zi <me@ziyao.cc> wrote:
> > lib: fdtdec: Handle multiple memory nodes
> >
> > Current code only tries to fetch the first memory node found in
> > fdt tree and determine memory banks from multiple reg properties.
> >
> > Specification allows multiple memory nodes in devicetree, rework
> > fdtdec_setup_mem_size_base_lowest and fdtdec_setup_memory_banksize
> > to iterate over all memory nodes.
> >
> > Signed-off-by: Jiaxun Yang <jiaxun.yang@flygoat.com>
> > Signed-off-by: Yao Zi <me@ziyao.cc>
> >
> > include/asm-generic/global_data.h | 2 +-
> > lib/fdtdec.c | 129 ++++++++++++++++++++++----------------
> > 2 files changed, 76 insertions(+), 55 deletions(-)
>
> > diff --git a/lib/fdtdec.c b/lib/fdtdec.c
> > @@ -1115,90 +1116,110 @@ ofnode fdtdec_get_next_memory_node(ofnode mem)
> > +too_may_memory_banks:
> > + log_warning("%s: Too many memory banks\n", __func__);
> > + return -EINVAL;
> > +}
>
> Typo - too_may_memory_banks should be too_many_memory_banks. While
> you are here, please drop the goto... bank is bounded, so a single
> check after the loops (or bank < CONFIG_NR_DRAM_BANKS in the inner
> while) gives a single return path.
Thanks for the advice. I don't think it's okay to have only a check
after the loops, in which case we might iterate over the boundary of
gd->dram[]; and if we use bank < CONFIG_NR_DRAM_BANKS for the condition
of the inner loop, another additional check is still necessary after
the loops because we want to give out the message and a correct return
value indicating the error, right?
Alternatively, I think we could drop the goto statement and instead
return immediately in the inner loop if CONFIG_NR_DRAM_BANKS is not
sufficient, is it okay for you?
> > diff --git a/lib/fdtdec.c b/lib/fdtdec.c
> > @@ -1115,90 +1116,110 @@ ofnode fdtdec_get_next_memory_node(ofnode mem)
> > + log_debug("%s: DRAM Bank #%d %s.%d: start = 0x%llx, size = 0x%llx\n",
> > + __func__, bank, ofnode_get_name(mem), reg,
> > + (unsigned long long)gd->dram[bank].start,
> > + (unsigned long long)gd->dram[bank].size);
>
> The current code uses %pap with &gd->dram[bank].start, which is the
> idiomatic way to print phys_addr_t/phys_size_t iand should avoid
> needing casts. Can you keep %pap here (and in the message below)?
Sure, this makes sense. When rebasing, I noted the change in current
master, but had only remembered to update the log_debug() message in
fdtdec_setup_mem_size_base_lowest() to use %pap.
> > diff --git a/lib/fdtdec.c b/lib/fdtdec.c
> > @@ -1115,90 +1116,110 @@ ofnode fdtdec_get_next_memory_node(ofnode mem)
> > + while (true) {
> > + struct resource res;
> > + phys_size_t base, size;
> > + int reg = 0;
>
> You should really use phys_addr_t for base
Ok.
> Regards,
> Simon
Best regards,
Yao Zi
next prev parent reply other threads:[~2026-07-02 20:39 UTC|newest]
Thread overview: 56+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-01 11:17 [PATCH v2 00/16] LoongArch initial support Yao Zi
2026-07-01 11:17 ` [PATCH v2 01/16] lib: fdtdec: Handle multiple memory nodes Yao Zi
2026-07-02 10:22 ` Simon Glass
2026-07-02 20:39 ` Yao Zi [this message]
2026-07-01 11:17 ` [PATCH v2 02/16] linux/io.h: Use map_physmem to implement ioremap Yao Zi
2026-07-02 10:21 ` Simon Glass
2026-07-01 11:17 ` [PATCH v2 03/16] image: Take entry point as an output of setup_booti Yao Zi
2026-07-01 17:39 ` Tom Rini
2026-07-02 20:39 ` Yao Zi
2026-07-02 20:55 ` Tom Rini
2026-07-02 21:10 ` Yao Zi
2026-07-02 9:46 ` Simon Glass
2026-07-01 11:17 ` [PATCH v2 04/16] elf: Define LoongArch bits Yao Zi
2026-07-02 10:24 ` Simon Glass
2026-07-01 11:17 ` [PATCH v2 05/16] image: Define IH_ARCH_LOONGARCH Yao Zi
2026-07-02 9:44 ` Simon Glass
2026-07-01 11:17 ` [PATCH v2 06/16] LoongArch: skeleton and headers Yao Zi
2026-07-01 17:47 ` Tom Rini
2026-07-02 20:40 ` Yao Zi
2026-07-02 20:57 ` Tom Rini
2026-07-02 10:28 ` Simon Glass
2026-07-02 21:22 ` Yao Zi
2026-07-01 11:17 ` [PATCH v2 07/16] LoongArch: lib: General routines Yao Zi
2026-07-01 17:49 ` Tom Rini
2026-07-02 9:24 ` Jiaxun Yang
2026-07-02 10:54 ` Simon Glass
2026-07-02 14:07 ` Tom Rini
2026-07-02 20:56 ` Yao Zi
2026-07-02 20:58 ` Tom Rini
2026-07-02 10:28 ` Simon Glass
2026-07-02 21:46 ` Yao Zi
2026-07-01 11:18 ` [PATCH v2 08/16] LoongArch: CPU assembly routines Yao Zi
2026-07-02 10:25 ` Simon Glass
2026-07-03 20:12 ` Yao Zi
2026-07-04 11:22 ` Jiaxun Yang
2026-07-01 11:18 ` [PATCH v2 09/16] LoongArch: Exception handling Yao Zi
2026-07-02 10:25 ` Simon Glass
2026-07-01 11:18 ` [PATCH v2 10/16] LoongArch: Boot Image bits Yao Zi
2026-07-01 17:53 ` Tom Rini
2026-07-02 10:26 ` Simon Glass
2026-07-01 11:18 ` [PATCH v2 11/16] LoongArch: Generic CPU type Yao Zi
2026-07-01 17:55 ` Tom Rini
2026-07-02 10:26 ` Simon Glass
2026-07-01 11:18 ` [PATCH v2 12/16] cpu: Add loongarch_cpu driver Yao Zi
2026-07-02 10:26 ` Simon Glass
2026-07-01 11:18 ` [PATCH v2 13/16] timer: Add loongarch_timer driver Yao Zi
2026-07-02 10:27 ` Simon Glass
2026-07-01 11:18 ` [PATCH v2 14/16] board: emulation: Add qemu-loongarch Yao Zi
2026-07-02 10:27 ` Simon Glass
2026-07-01 11:18 ` [PATCH v2 15/16] efi: LoongArch: Define LoongArch bits everywhere Yao Zi
2026-07-02 10:27 ` Simon Glass
2026-07-01 11:18 ` [PATCH v2 16/16] efi: LoongArch: Implement everything Yao Zi
2026-07-02 10:29 ` Simon Glass
2026-07-01 15:53 ` [PATCH v2 00/16] LoongArch initial support Jiaxun Yang
2026-07-01 17:59 ` Tom Rini
2026-07-02 10:31 ` [v2,00/16] " Simon Glass
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=akbGWWq3kQZERfOD@pie \
--to=me@ziyao.cc \
--cc=ilias.apalodimas@linaro.org \
--cc=jiaxun.yang@flygoat.com \
--cc=sjg@chromium.org \
--cc=trini@konsulko.com \
--cc=u-boot@lists.denx.de \
--cc=xypron.glpk@gmx.de \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox