Hi Mario,
On Tue, Nov 13, 2018 at 11:42 AM Holger Brunck holger.brunck@ch.abb.com wrote:
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.
ok.
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. :-)
Thanks, indeed we were not doing much lately, but they are still alive and in use and we keep an eye on it what is going on mainline.
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.
migrating them to DM and make them future ready in u-boot ML was still on my list but due to missing time we did nothing until now. I know that we need to take some actions here, otherwise we might get removed from ML sooner or later and this is something we really like to avoid.
Yes we have DTS files for all our boards but mostly not mainlined. We have several 8321 boards which only differs slightly from an u-boot point of view. That is also the reason for our common includes as the boards for example only differ in one chip select for a FPGA or so. And that is why we have done a lot of effort of creating this include hierarchy in u-boot. We even have also some generic includes which are common for different architectures we have (kirkwood, powerpc). Best regards Holger