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