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
