Hi Tom,
On 12/17/25 4:04 PM, Tom Rini wrote:
On Wed, Dec 17, 2025 at 03:51:03PM +0100, Quentin Schulz wrote:
Hi Tom,
On 12/17/25 3:17 PM, Tom Rini wrote:
On Wed, Dec 17, 2025 at 03:01:10PM +0100, Quentin Schulz wrote:
From: Quentin Schulz <[email protected]>
CMD_NET_LWIP has never existed so it cannot be right. I'm guessing the
intent was to allow print_eth() to be called when NET_LWIP is defined
(NET means "legacy networking stack" as opposed to NET_LWIP which is the
newest (and incompatible) stack). There probably was some mix-up
between CMD_NET and NET options.
The dependency on CMD_NET seems unnecessary as it seems perfectly fine
to run bdinfo without CMD_NET (build and run tested). So let's instead
make the dependency on NET || NET_LWIP.
Fixes: 95744d2527cb ("cmd: bdinfo: enable -e when CONFIG_CMD_NET_LWIP=y")
Signed-off-by: Quentin Schulz <[email protected]>
---
cmd/bdinfo.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/cmd/bdinfo.c b/cmd/bdinfo.c
index 20c8c97f0cd..09fe8067642 100644
--- a/cmd/bdinfo.c
+++ b/cmd/bdinfo.c
@@ -152,7 +152,7 @@ static int bdinfo_print_all(struct bd_info *bd)
bdinfo_print_num_l("relocaddr", gd->relocaddr);
bdinfo_print_num_l("reloc off", gd->reloc_off);
printf("%-12s= %u-bit\n", "Build", (uint)sizeof(void *) * 8);
- if (IS_ENABLED(CONFIG_CMD_NET) || IS_ENABLED(CONFIG_CMD_NET_LWIP))
+ if (IS_ENABLED(CONFIG_NET) || IS_ENABLED(CONFIG_NET_LWIP))
print_eth();
bdinfo_print_num_l("fdt_blob", (ulong)map_to_sysmem(gd->fdt_blob));
if (IS_ENABLED(CONFIG_VIDEO))
@@ -193,8 +193,8 @@ int do_bdinfo(struct cmd_tbl *cmdtp, int flag, int argc,
char *const argv[])
case 'a':
return bdinfo_print_all(bd);
case 'e':
- if (!IS_ENABLED(CONFIG_CMD_NET) &&
- !IS_ENABLED(CONFIG_CMD_NET_LWIP))
+ if (!IS_ENABLED(CONFIG_NET) &&
+ !IS_ENABLED(CONFIG_NET_LWIP))
return CMD_RET_USAGE;
print_eth();
return CMD_RET_SUCCESS;
It must also be the case that we never both build cmd/bdinfo.c and also
have no network stack, otherwise we'd get a warning around print_eth
being defined but unused. Can you guard that function too? It needs
This doesn't happen though for some reason.
make ringneck-px30_defconfig
make menuconfig # CMD_NET=n, NO_NET=y
make
No warning or error (CMD_BDI=y and I've checked by adding #error whatever in
the file). eth-uclass.c which defines eth_get_dev_index() is not compiled in
(no eth-uclass.o in build/drivers/).
Hunh, ok...
Compiler magic? /me shrugs
eth_get_dev_index to exist which does require a network stack. Also,
maybe we should be checking on the "no networking enabled" symbol? Or
Yes we probably should but we do NET || NET_LWIP everywhere, so I believe
it's better to stay consistent for now.
Makes sense.
Mmmmm... So CMD_NET is only selectable when NET || NET_LWIP today[1], so
keeping only CMD_NET check is enough (removing CMD_NET_LWIP which anyway
doesn't exist). But at the same time, there's nothing CMD_NET does that
is required for this part of bdinfo to work, so I think going for NET ||
NET_LWIP still is better? What do you think?
[1] https://elixir.bootlin.com/u-boot/v2025.10/source/cmd/Kconfig#L1840
no, because that would then conflict with the other series you're
working on that you mentioned?
In the upcoming series, I plan on having NET mean "there's a networking
stack available" and I'll replace all current NET || NET_LWIP with simply
NET (the "new" meaning for NET; the current NET will be renamed to
NET_LEGACY). It'll be based on this series, and I don't want to be making
this patch dependent on the huge changes in the upcoming series. I'm not
confident that upcoming series is necessarily worth merging or that it'll go
through and be merged. I'm at 198 files changed and the list of people
get_maintainer returns is 160 people... I still have my doubt on the
NET->NET_LEGACY rename and reusing NET for NET_LEGACY || NET_LWIP.
I'm on PTO in ~24h for ~3 weeks and I'm torn on whether to send the series
(if it's ready) by then, feels a bit weird to drop a big changeset like that
and disappear for a while :)
Yes, lets see it when you're back from vacation, thanks and enjoy your
PTO!
Thanks, happy holidays and good luck for the 2026.01 release, hopefully
everything goes smooth :)
Cheers,
Quentin
