Message ID | 20200504231732.98778-1-sjg@chromium.org |
---|---|
Headers | show |
Series | Tidy up the 'bd' command. | expand |
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
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