[U-Boot] [RFC PATCH v2 09/11] spl: Kconfig: Add SPL__SUPPORT as Kconfig option

Tom Rini
2016-08-26T20:06:43Z

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>