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

[Masahiro Yamada]

2016-08-23 0:21 GMT+09:00 Andrew F. Davis <afd at 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 at 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)





-- 
Best Regards
Masahiro Yamada