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 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.