mbox series

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

Message ID 20200504231732.98778-1-sjg@chromium.org
Headers show
Series Tidy up the 'bd' command. | expand

Message

Simon Glass May 4, 2020, 11:16 p.m. UTC
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
  bdinfo: Drop the option to not use the generic 'bd' command
  bdinfo: Drop unused __maybe_unused
  bdinfo: microblaze: sh: nios2: Drop arch-specific flash info
  bdinfo: Drop unnecessary inline on functions
  bdinfo: Drop print_std_bdinfo()
  bdinfo: ppc: Drop arch-specific print_baudrate()
  bdinfo: sh: arc: Drop arch-specific print_bi_mem()
  bdinfo: Drop print_bi_boot_params()
  bdinfo: Drop print_bi_flash()
  bdinfo: Drop print_cpu_word_size()
  bdinfo: net: ppc: Drop bi_enet1addr and other similar info
  bdinfo: net: ppc: Drop prints for CONFIG_HAS_ETHn
  bdinfo: net: Drop legacy ethernet bdinfo
  bdinfo: net: Inline print_eths()
  bdinfo: net: Inline print_eth_ip_addr()
  bdinfo: Export some basic printing functions
  bdinfo: arm: Move ARM-specific info into its own file
  bdinfo: ppc: Move PPC-specific info into its own file
  bdinfo: m68k: Move m68k-specific info into its own file
  bdinfo: m68k: ppc: Move arch-specific code from bdinfo
  bdinfo: Update the file comments
  bdinfo: dm: Update fb_base when using driver model
  bdinfo: x86: vesa: Update fb_base to the correct value

 arch/arm/lib/Makefile           |   1 +
 arch/arm/lib/bdinfo.c           |  51 ++++
 arch/m68k/lib/Makefile          |   1 +
 arch/m68k/lib/bdinfo.c          |  34 +++
 arch/nds32/include/asm/u-boot.h |  20 +-
 arch/powerpc/lib/Makefile       |   2 +
 arch/powerpc/lib/bdinfo.c       |  46 ++++
 arch/riscv/include/asm/u-boot.h |  19 +-
 arch/x86/lib/fsp/fsp_graphics.c |   5 +-
 cmd/bdinfo.c                    | 451 +++-----------------------------
 common/board_r.c                |  16 +-
 drivers/video/video-uclass.c    |   1 +
 include/asm-generic/u-boot.h    |  18 --
 include/init.h                  |   9 +
 14 files changed, 185 insertions(+), 489 deletions(-)
 create mode 100644 arch/arm/lib/bdinfo.c
 create mode 100644 arch/m68k/lib/bdinfo.c
 create mode 100644 arch/powerpc/lib/bdinfo.c

Comments

Alexey Brodkin May 6, 2020, 9:28 a.m. UTC | #1
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
Simon Glass May 6, 2020, 2:47 p.m. UTC | #2
Hi Alexey,


On Wed, 6 May 2020 at 03:28, Alexey Brodkin <Alexey.Brodkin at synopsys.com> wrote:
>
> 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?

This is not a very large migration, just a small change to one
command, mostly. We already have generic bdinfo (same 'struct bd') for
all but two archs.

The series is split by arch - see the tags for each commit. That is
why some maintainers get some patches and not others, or at least that
is my hope, since patman runs get_maintainers separately on each
commit.

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

See u-boot-dm/bd-working for the tree. I always post a series there
before sending, but don't always mention the name, sorry.

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

:-)

Regards,
Simon