[U-Boot] [RFC PATCH v2 09/11] spl: Kconfig: Add SPL_<media>_SUPPORT as Kconfig option

[Tom Rini <trini@konsulko.com>]

On Tue, Aug 23, 2016 at 03:08:02PM +0900, Masahiro Yamada wrote:
> 2016-08-23 0:21 GMT+09:00 Andrew F. Davis <afd@ti.com>:
> > Create a new Kconfig file to contain SPL boot media loading support
> > options as we begin moving these to the Kconfig system and out of header
> > files. Initially add new configs for all the existing boot media types,
> > giving them the same definition name as before to allow compatibility
> > with systems not yet using Kconfig.
> >
> > Signed-off-by: Andrew F. Davis <afd@ti.com>
> > ---
> >  common/Kconfig     |  7 +++++++
> >  common/spl/Kconfig | 54 ++++++++++++++++++++++++++++++++++++++++++++++++++++++
> >  2 files changed, 61 insertions(+)
> >  create mode 100644 common/spl/Kconfig
> >
> > diff --git a/common/Kconfig b/common/Kconfig
> > index 46e7173..f594db5 100644
> > --- a/common/Kconfig
> > +++ b/common/Kconfig
> > @@ -156,6 +156,13 @@ config SPI_BOOT
> >           booted via SPI flash. This is not a must, some SoCs need this,
> >           somes not.
> >
> > +menu "SPL Media Loading Support"
> > +       depends on SPL
> > +
> > +source "common/spl/Kconfig"
> > +
> > +endmenu
> > +
> >  endmenu
> >
> >  config BOOTDELAY
> > diff --git a/common/spl/Kconfig b/common/spl/Kconfig
> > new file mode 100644
> > index 0000000..788ca14
> > --- /dev/null
> > +++ b/common/spl/Kconfig
> > @@ -0,0 +1,54 @@
> > +config SPL_YMODEM_SUPPORT
> > +       depends on SPL
> > +       bool "SPL Support for loading next stage from UART"
> > +       help
> > +         This option enables SPL to load the next stage bootloader
> > +         over a UART line using the x/y/z/modem protocol.
> > +
> > +config SPL_MMC_SUPPORT
> > +       bool "SPL Support for loading next stage from SD/MMC/eMMC"
> > +       help
> > +         This option enables SPL to load the next stage bootloader
> > +         from an SD/MMC/eMMC device.
> > +
> > +config SPL_SPI_SUPPORT
> > +       bool "SPL Support for loading next stage from SPI flash"
> > +       help
> > +         This option enables SPL to load the next stage bootloader
> > +         from SPI flash.
> > +
> > +config SPL_USB_SUPPORT
> > +       bool "SPL Support for loading next stage from USB"
> > +       help
> > +         This option enables SPL to load the next stage bootloader
> > +         from a USB device.
> > +
> > +config SPL_SATA_SUPPORT
> > +       bool "SPL Support for loading next stage from SATA"
> > +       help
> > +         This option enables SPL to load the next stage bootloader
> > +         from a SATA device.
> > +
> > +config SPL_NOR_SUPPORT
> > +       bool "SPL Support for loading next stage from NOR flash"
> > +       help
> > +         This option enables SPL to load the next stage bootloader
> > +         from NOR flash.
> > +
> > +config SPL_NAND_SUPPORT
> > +       bool "SPL Support for loading next stage from NAND flash"
> > +       help
> > +         This option enables SPL to load the next stage bootloader
> > +         from NAND flash.
> > +
> > +config SPL_ONENAND_SUPPORT
> > +       bool "SPL Support for loading next stage from ONENAND"
> > +       help
> > +         This option enables SPL to load the next stage bootloader
> > +         from ONENAND.
> > +
> > +config SPL_NET_SUPPORT
> > +       bool "SPL Support for loading next stage from NET"
> > +       help
> > +         This option enables SPL to load the next stage bootloader
> > +         from NET.
> 
> 
> 
> Historically, config options for SPL build were named
> in the format of CONFIG_SPL_*_SUPPORT,
> but the suffix "_SUPPORT" was not adding anything
> except making the macro name longer, in my opinion.
> 
> New options such as CONFIG_SPL_CLK, CONFIG_SPL_PINCTRL,
> only use SPL_ prefix because this naming scheme
> can exploit CONFIG_IS_ENABLED() macro.
> 
> 
> Then, I was hit by this question:
> 
> Given that SPL exists for loading the next stage image,
> "SPL Support for loading next stage from SD/MMC/eMMC"
> (from the Kconfig prompt of this patch) is nearly equal to
> "Enable MMC driver support for SPL".
> 
> 
> 
>   SPL_MMC_SUPPORT in common/spl/Kconfig (for loading image from MMC)
>   SPL_MMC  in drivers/mmc/Kconfig   (for enabling MMC driver for SPL)
> it would make it tedious to use if we added both of them.
> Theoretically, we can control them independently if we want, but
> common/spl/spl_*.c are almost small entry stubs.
> 
> 
> Tom,
> Which do you think a better place for those options?
> (SPL_YMODEM has no good directory, though)

My preference is to have SPL stuff in common/spl/Kconfig to start with.
And yes, we may have some redundant options that could be removed if
after investigation A && B are always enabled.

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20160826/9a71c38a/attachment.sig>