[U-Boot] [PATCH v5 5/16] cmd: Add Kconfig option for CMD_MTDPARTS and related options

["Jörg Krause" <joerg.krause@embedded.rocks>]

Hi Maxime,

On Wed, 2017-05-31 at 21:47 +0200, Maxime Ripard wrote:
> On Wed, May 31, 2017 at 08:27:33AM +0200, Jörg Krause wrote:
> > Hi Maxime,
> > 
> > On Tue, 2017-05-30 at 23:09 +0200, Maxime Ripard wrote:
> > > Hi Jörg,
> > > 
> > > On Tue, May 30, 2017 at 09:39:57AM +0200, Jörg Krause wrote:
> > > > On Mon, 2017-02-27 at 18:22 +0100, Maxime Ripard wrote:
> > > > > CMD_MTDPARTS is something the user might or might not want to
> > > > > select,
> > > > > and
> > > > > might depends on (or be selected by) other options too.
> > > > > 
> > > > > This is even truer for the MTDIDS_DEFAULT and MTDPARTS_DEFAULT
> > > > > options that
> > > > > might change from one board to another, or from one user to the
> > > > > other,
> > > > > depending on what it expects and what storage devices are
> > > > > available.
> > > > > 
> > > > > In order to ease that configuration, add those options to
> > > > > Kconfig.
> > > > > 
> > > > > Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
> > > > > Reviewed-by: Tom Rini <trini@konsulko.com>
> > > > > ---
> > > > >  cmd/Kconfig    | 20 ++++++++++++++++++++
> > > > >  cmd/mtdparts.c |  8 ++++++++
> > > > >  2 files changed, 28 insertions(+), 0 deletions(-)
> > > > > 
> > > > > diff --git a/cmd/Kconfig b/cmd/Kconfig
> > > > > index ef5315631476..0734d669dbd7 100644
> > > > > --- a/cmd/Kconfig
> > > > > +++ b/cmd/Kconfig
> > > > > @@ -801,6 +801,26 @@ config CMD_FS_GENERIC
> > > > >  	help
> > > > >  	  Enables filesystem commands (e.g. load, ls) that work
> > > > > for
> > > > > multiple
> > > > >  	  fs types.
> > > > > +
> > > > > +config CMD_MTDPARTS
> > > > > +	depends on ARCH_SUNXI
> > > > 
> > > > Is there any reason to limit the command for the sunxi arch only?
> > > 
> > > Yes, if we don't, this will generate warnings for each architecture
> > > that has not moved that option from their header to Kconfig.
> > 
> > I see! However, wouldn't it be best to migrate all architectures to
> > Kconfig instead of doing it seperately?
> 
> Probably, but there was a quite significant number of Kconfig symbols
> introduced, used by a very significant number of boards and
> architectures.

I see!

> This was really to unreasonable to do at the time, but we can
> definitely do that now.

That would be great! Many thanks!

Jörg