[PATCH 00/36] Tidy up the 'bd' command.

[Alexey Brodkin]

Hi Simon,

> -----Original Message-----
> From: Simon Glass <sjg at chromium.org>
> Sent: Tuesday, May 5, 2020 2:17 AM
> To: U-Boot Mailing List <u-boot at lists.denx.de>

[snip]

> Subject: [PATCH 00/36] Tidy up the 'bd' command.
> 
> The code for the 'bd' command never got the 'generic board' treatment many
> years ago when global_data and bd_info were converted. As a result it
> still has a lot of arch-specific duplication of generic code.
> 
> This series aims to make as much code in this file generic as possible, so
> that it is easy to add new info on all architectures.
> 
> For the three architectures that actually need additional code (ARM, PPC
> and m68k) this is moved into arch-specific files.
> 
> With this series, bdinfo.c drops from nearly 500 lines to just over 100.
> 
> It also makes x86 report the frame buffer address properly (the original
> goal of my effort).
> 
> Simon Glass (36):
>   bdinfo: nds32: Use generic bd_info
>   bdinfo: riscv: Use generic bd_info
>   bdinfo: m68k: Drop bd_info->bi_ipbfreq
>   bdinfo: xtensa: Create a generic do_bdinfo for xtensa
>   bdinfo: mips: Use the generic bd command
>   bdinfo: nios2: Use the generic bd command
>   bdinfo: microblaze: Use the generic bd command
>   bdinfo: sh: Use the generic bd command
>   bdinfo: x86: Use the generic bd command
>   bdinfo: sandbox: Use the generic bd command
>   bdinfo: nds32: Use the generic bd command
>   bdinfo: riscv: Use the generic bd command
>   bdinfo: arm: Use the generic bd command

Looks like this one contains much more than just ARM changes.
Instead it looks like a massive migration to a generic bdinfo.
So I would propose either split it into per-arch changes
(though given this series size it might not be a good idea) or
alternatively maybe just ask for affected architecture maintainers
for an ack?

Also IMHO it would be very convenient to have a link to a git tree
with all these changes - it will significantly simplify review process.

But regardless all my comments above I'd like to note that this series
is very welcome as a long needed clean-up of that per-arch nonsense.
Thanks for doing this significant and useful work!

-Alexey