Hi Holger, On Tue, Nov 13, 2018 at 11:42 AM Holger Brunck <holger.bru...@ch.abb.com> wrote: > > Hi Mario, > > > Simplify the keymile config files once more by unrolling the > > km/km83xx-common.h, and resolve the #ifdef logic as needed. > > > > Signed-off-by: Mario Six <mario....@gdsys.cc> > > > > --- > > > > v1 -> v2: > > No changes > > > > --- > > include/configs/km8360.h | 291 > ++++++++++++++++++++++++++++++++++++++- > > include/configs/km83xx-common.h | 296 > ---------------------------------------- > > include/configs/kmopti2.h | 289 > ++++++++++++++++++++++++++++++++++++++- > > include/configs/kmsupx5.h | 289 > ++++++++++++++++++++++++++++++++++++++- > > include/configs/kmtegr1.h | 288 > +++++++++++++++++++++++++++++++++++++- > > include/configs/kmtepr2.h | 289 > ++++++++++++++++++++++++++++++++++++++- > > include/configs/kmvect1.h | 288 > +++++++++++++++++++++++++++++++++++++- > > include/configs/suvd3.h | 291 > ++++++++++++++++++++++++++++++++++++++- > > include/configs/tuge1.h | 289 > ++++++++++++++++++++++++++++++++++++++- > > include/configs/tuxx1.h | 289 > ++++++++++++++++++++++++++++++++++++++- > > 10 files changed, 2579 insertions(+), 320 deletions(-) > > delete mode 100644 include/configs/km83xx-common.h > > could you elaborate why you need to do this? Turning 320 lines into 2579 > does not sound like simplifying the code. I understand that you > try to move a lot of config options to Kconfig for 83xx, which is good. But > why can't we keep common header files for things which are common for > some of our boards? For example duplicating CS configurations or SDRAM > settings for similar boards seems to be unneeded to me and increases > maintenance in the future. > The purpose of the unrolling is to use semi-automatic conversion tools (i.e. a bunch of Python scripts I threw together) to move most of the config options over to Kconfig; mostly for the "bit-field" options, like CONFIG_SYS_{BR,OR}_* that are actually a bunch of options rolled into one, which are turned into multiple Kconfig options.
But, yes, I'll re-instate the common includes, no problem. I made the series under the initial series impression that the keymile boards were essentially unmaintained, so I thought nobody would care. But now that you're actively maintaining again, I'll put the configs back in a readable state. :-) Concerning the boards, though: Are there any plans for migrating them to DM? I see at least a kmeter1 device tree in the Linux kernel, but the other boards would need device trees as well (or you could do everything with platdata, I guess). There are DM drivers for a lot of MPC83xx functions upstream now, so quite a few things should work already. > Best regards > Holger Brunck Best regards, Mario _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot