[U-Boot] [PATCH v2 11/58] keymile: Unroll km/km83xx-common.h

[Mario Six]

Hi Holger,

On Tue, Nov 13, 2018 at 11:42 AM Holger Brunck <holger.brunck at 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.six at 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