[U-Boot] [PATCH v5 00/26]MTD defconfigs/Kconfigs/Makefiles heavy cleanup

[Miquel Raynal <miquel.raynal@bootlin.com>]

Hi Tom,

Tom Rini <trini@konsulko.com> wrote on Wed, 30 Oct 2019 09:57:13 -0400:

> On Thu, Oct 03, 2019 at 07:50:02PM +0200, Miquel Raynal wrote:
> 
> > Hello,
> > 
> > A year ago, while working on SPI-NAND support in U-Boot, I discovered
> > when modifying Makefiles a confusing organization where:
> > * Sub-directories/files are compiled from the root Makefile
> > * Commands are at the root of everything
> > 
> > First I sent a series to move Makefile entries in their respective
> > directories. Then, I decided to continue working on the clarification
> > of the Makefile hierarchy in MTD and I sent four iterations of this
> > series which did not got merge at that time. Anyway, I revived this
> > series by rebasing all my work and updating everything that needed an
> > update.
> > 
> > Here are the main points of the re-organization:
> > * Rename CONFIG_MTD into CONFIG_DM_MTD to reserve CONFIG_MTD to what
> >   is called today CONFIG_MTD_DEVICE.
> > * Fix build dependencies in defconfigs, like: "UBI and NAND depend on MTD".
> > * Fix the Kconfig files to reflect these dependencies (as defconfigs
> >   have been updated, nothing should break).
> > * Simplify the Makefiles: compiling the drivers/mtd/nand/raw/
> >   sub-directory should just depend on MTD being compiled and the NAND
> >   core as well, there is absolutely no logic to make it depend on
> >   CMD_NAND.
> > 
> > The New green Travis CI build for the fifth version of this series is
> > there (yes, 53 iterations):
> > 
> > Please note that the only red test fails because of timeout, not an
> > actual error (at least I could not spot it). It is possible that this
> > series will produce noticeable changes for the users. The only reason
> > for that is because their configuration file was wrong. I have done my
> > best to fix them one by one, but I am not omniscient.  
> 
> OK, so I want to grab this series, and I intend to do my best to do so.
> But the problem this exposes is just how complex the uses of CONFIG_NAND
> got and in turn symbol re-use, on PowerPC.  This (+ v6) showed a few
> minor migration problems when I size compared, and those are easily
> fixed.  What isn't so easily fixed is that it was also changing
> how/where the environment is found on some PowerPC boards.  Fixing that
> in turn requires finally finishing off the migration of the main
> CONFIG_ENV_xxx symbols to Kconfig.  I have this done outside of about 20
> boards.  I'm going to get that finished up as soon as I can and posted,
> then make this series depend on that.  Thanks again for doing the hard
> work here, we really need this particular migration and clean up!
> 

I see the problem, well, thanks for grabbing it, please keep us
updated and do not hesitate if you need help.

Thanks,
Miquèl