Re: [U-Boot] [PATCH v2 21/44] Convert CONFIG_SPL_GPIO_SUPPORT to Kconfig

[Tom Rini]

On Mon, Sep 12, 2016 at 01:32:54PM +0900, Masahiro Yamada wrote:
> Hi Simon,
> 
> 
> 2016-09-12 13:16 GMT+09:00 Simon Glass :
> > Hi,
> >
> > On 6 September 2016 at 09:54, Tom Rini  wrote:
> >> On Mon, Sep 05, 2016 at 07:04:45PM -0600, Simon Glass wrote:
> >>> Hi Masahiro,
> >>>
> >>> On 4 September 2016 at 20:40, Masahiro Yamada
> >>>  wrote:
> >>> > 2016-09-02 23:35 GMT+09:00 Tom Rini :
> >>> >
> >>> >>> >> diff --git a/arch/arm/mach-exynos/Kconfig 
> >>> >>> >> b/arch/arm/mach-exynos/Kconfig
> >>> >>> >> index c25fcf3..d4a5bc9 100644
> >>> >>> >> --- a/arch/arm/mach-exynos/Kconfig
> >>> >>> >> +++ b/arch/arm/mach-exynos/Kconfig
> >>> >>> >> @@ -61,6 +61,9 @@ endif
> >>> >>> >>
> >>> >>> >>  if ARCH_EXYNOS5
> >>> >>> >>
> >>> >>> >> +config SPL_GPIO_SUPPORT
> >>> >>> >> +   default y
> >>> >>> >> +
> >>> >>> >
> >>> >>> >
> >>> >>> > As we discussed before,
> >>> >>> > we decided to not do this.
> >>> >>>
> >>> >>> Tom was keen to avoid changing every defconfig file. It is there
> >>> >>> another way to express common defaults?
> >>> >>
> >>> >> I was thinking in the Kconfig with the entry for SPL_GPIO_SUPPORT, for
> >>> >> optional stuff and select in the board, etc, Kconfig for non-optional
> >>> >> stuff.  Now, I realize that optional vs non-optional is more the domain
> >>> >> of the individual SoC custodians, so we'll have some clean up 
> >>> >> afterwards
> >>> >> that isn't on you (well, aside from the SoCs you know like rockchip 
> >>> >> ;)).
> >>> >
> >>> > config SPL_GPIO_SUPPORT
> >>> >default y
> >>> >
> >>> > is incorrect because it could violate
> >>> > the dependency in the proper Kconfig entry in spl/Kconfig.
> >>>
> >>> But only if options depended on by this are not set, right?
> >>>
> >>> >
> >>> >
> >>> >
> >>> >
> >>> > Basically, we are supposed to use "select FOO" when it is mandatory,
> >>> > or add CONFIG_FOO=y in a defconfig when the board wants it, but
> >>> > can still make it optional.
> >>>
> >>> Yes, but this is not mandatory. It is a default, and some boards will
> >>> unset it. I did this in response to Tom's comment about trying to cut
> >>> down the defconfig patch size.
> >>
> >> Well, here is where it is tricky.  For example, in SPL when we bring in
> >> the GPIO code, it's because it's required to enable DDR or know which
> >> board rev we're on.  So it needs to be select'd or people will get
> >> failure to build problems.  Other things like filesystems should be an
> >> option.
> >>
> >>> > I know our pain comes from that "include" is not supported by Kconfig.
> >>>
> >>> How would that help? Why don't we implement it?
> >>
> >> Well, if we could more literally translate the various *common*.h files
> >> into a Kconfig file that was "included" it would be easier to say that
> >> various CONFIG variables are just a bool (or hex) and then
> >> board/ti/am335x/Kconfig would 'include
> >> include/kconfig/ti_am33xx_common.k' and get all of the stuff it
> >> used to get from include/configs/ti_am335x_common.h.
> >>
> >>> > What I can suggest now is:
> >>> >
> >>> >
> >>> >
> >>> > [1]  Add ARCH_WANT_* to specify a SoC-common default.
> >>> >
> >>> >
> >>> >config SPL_GPIO_SUPPORT
> >>> > bool "GPIO support for SPL"
> >>> > default  ARCH_WANT_SPL_GPIO_SUPPORT
> >>> >
> >>> >
> >>> >config ARCH_WANT_SPL_GPIO_SUPPORT
> >>> > bool
> >>> >
> >>> >
> >>> >config ARCH_EXYNOS5
> >>> >select ARCH_WANT_SPL_GPIO_SUPPORT
> >>> >
> >>> >
> >>> > Linux used to have ARCH_WANT_OPTIONAL_GPIOLIB to do similar things.
> >>> > (they stopped this way, though)
> >>
> >> This may be better.
> >>
> >>> > [2] Support multi boards with one defconfig
> >>> > (barebox supports multi-platform like Linux does.)
> >>
> >> Unless I missed something, this is just kicking the problem up a level
> >> frankly.  They just allow (and we could / can / do, depending on the
> >> SoC) one full "barebox" to be loaded by the board-specific preloader.
> >> We can, should, and hopefully will once DM is 'done', have this be an
> >> option.  But that's a different problem set from how do we configure the
> >> board specific part of a build.
> >>
> >>> > [3] use pre-processor to support #include <...>
> >>> >
> >>> >
> >>> >
> >>> >
> >>> >
> >>> > BTW, SPL_GPIO_SUPPORT is optional in this case?
> >>> >
> >>> > U-Boot proper supports a command line interface,
> >>> > while SPL is usually run in a non-interactive mode.
> >>> >
> >>> > So, what SPL needs is generally mandatory,
> >>> > so we can "select" it,  I guess.
> >>>
> >>> I found a lot of cases where 90% of the boards with the same SoC  had
> >>> the same setting for this (and a few other) options, but some boards
> >>> did not. So I did not want to use select, since then it is impossible
> >>> to unselect.
> >>
> >> Maybe this is where [1] above will work best and we 

Re: [U-Boot] [PATCH v2 21/44] Convert CONFIG_SPL_GPIO_SUPPORT to Kconfig

[Masahiro Yamada]

Hi Simon,


2016-09-12 13:16 GMT+09:00 Simon Glass :
> Hi,
>
> On 6 September 2016 at 09:54, Tom Rini  wrote:
>> On Mon, Sep 05, 2016 at 07:04:45PM -0600, Simon Glass wrote:
>>> Hi Masahiro,
>>>
>>> On 4 September 2016 at 20:40, Masahiro Yamada
>>>  wrote:
>>> > 2016-09-02 23:35 GMT+09:00 Tom Rini :
>>> >
>>> >>> >> diff --git a/arch/arm/mach-exynos/Kconfig 
>>> >>> >> b/arch/arm/mach-exynos/Kconfig
>>> >>> >> index c25fcf3..d4a5bc9 100644
>>> >>> >> --- a/arch/arm/mach-exynos/Kconfig
>>> >>> >> +++ b/arch/arm/mach-exynos/Kconfig
>>> >>> >> @@ -61,6 +61,9 @@ endif
>>> >>> >>
>>> >>> >>  if ARCH_EXYNOS5
>>> >>> >>
>>> >>> >> +config SPL_GPIO_SUPPORT
>>> >>> >> +   default y
>>> >>> >> +
>>> >>> >
>>> >>> >
>>> >>> > As we discussed before,
>>> >>> > we decided to not do this.
>>> >>>
>>> >>> Tom was keen to avoid changing every defconfig file. It is there
>>> >>> another way to express common defaults?
>>> >>
>>> >> I was thinking in the Kconfig with the entry for SPL_GPIO_SUPPORT, for
>>> >> optional stuff and select in the board, etc, Kconfig for non-optional
>>> >> stuff.  Now, I realize that optional vs non-optional is more the domain
>>> >> of the individual SoC custodians, so we'll have some clean up afterwards
>>> >> that isn't on you (well, aside from the SoCs you know like rockchip ;)).
>>> >
>>> > config SPL_GPIO_SUPPORT
>>> >default y
>>> >
>>> > is incorrect because it could violate
>>> > the dependency in the proper Kconfig entry in spl/Kconfig.
>>>
>>> But only if options depended on by this are not set, right?
>>>
>>> >
>>> >
>>> >
>>> >
>>> > Basically, we are supposed to use "select FOO" when it is mandatory,
>>> > or add CONFIG_FOO=y in a defconfig when the board wants it, but
>>> > can still make it optional.
>>>
>>> Yes, but this is not mandatory. It is a default, and some boards will
>>> unset it. I did this in response to Tom's comment about trying to cut
>>> down the defconfig patch size.
>>
>> Well, here is where it is tricky.  For example, in SPL when we bring in
>> the GPIO code, it's because it's required to enable DDR or know which
>> board rev we're on.  So it needs to be select'd or people will get
>> failure to build problems.  Other things like filesystems should be an
>> option.
>>
>>> > I know our pain comes from that "include" is not supported by Kconfig.
>>>
>>> How would that help? Why don't we implement it?
>>
>> Well, if we could more literally translate the various *common*.h files
>> into a Kconfig file that was "included" it would be easier to say that
>> various CONFIG variables are just a bool (or hex) and then
>> board/ti/am335x/Kconfig would 'include
>> include/kconfig/ti_am33xx_common.k' and get all of the stuff it
>> used to get from include/configs/ti_am335x_common.h.
>>
>>> > What I can suggest now is:
>>> >
>>> >
>>> >
>>> > [1]  Add ARCH_WANT_* to specify a SoC-common default.
>>> >
>>> >
>>> >config SPL_GPIO_SUPPORT
>>> > bool "GPIO support for SPL"
>>> > default  ARCH_WANT_SPL_GPIO_SUPPORT
>>> >
>>> >
>>> >config ARCH_WANT_SPL_GPIO_SUPPORT
>>> > bool
>>> >
>>> >
>>> >config ARCH_EXYNOS5
>>> >select ARCH_WANT_SPL_GPIO_SUPPORT
>>> >
>>> >
>>> > Linux used to have ARCH_WANT_OPTIONAL_GPIOLIB to do similar things.
>>> > (they stopped this way, though)
>>
>> This may be better.
>>
>>> > [2] Support multi boards with one defconfig
>>> > (barebox supports multi-platform like Linux does.)
>>
>> Unless I missed something, this is just kicking the problem up a level
>> frankly.  They just allow (and we could / can / do, depending on the
>> SoC) one full "barebox" to be loaded by the board-specific preloader.
>> We can, should, and hopefully will once DM is 'done', have this be an
>> option.  But that's a different problem set from how do we configure the
>> board specific part of a build.
>>
>>> > [3] use pre-processor to support #include <...>
>>> >
>>> >
>>> >
>>> >
>>> >
>>> > BTW, SPL_GPIO_SUPPORT is optional in this case?
>>> >
>>> > U-Boot proper supports a command line interface,
>>> > while SPL is usually run in a non-interactive mode.
>>> >
>>> > So, what SPL needs is generally mandatory,
>>> > so we can "select" it,  I guess.
>>>
>>> I found a lot of cases where 90% of the boards with the same SoC  had
>>> the same setting for this (and a few other) options, but some boards
>>> did not. So I did not want to use select, since then it is impossible
>>> to unselect.
>>
>> Maybe this is where [1] above will work best and we can select
>> ARCH_WANT_.. (or BOARD_WANT_...) from TARGET_... and leave some things
>> as questions.
>>
>>> This series is actually really tricky. I'm looking forward to putting
>>> it to bed. We need to make these conversions easier.
>>
>> Agreed!
>
> I am not sure about the WANT business, but I am sure that I don't want
> to work through all the 

Re: [U-Boot] [PATCH v2 21/44] Convert CONFIG_SPL_GPIO_SUPPORT to Kconfig

[Simon Glass]

Hi,

On 6 September 2016 at 09:54, Tom Rini  wrote:
> On Mon, Sep 05, 2016 at 07:04:45PM -0600, Simon Glass wrote:
>> Hi Masahiro,
>>
>> On 4 September 2016 at 20:40, Masahiro Yamada
>>  wrote:
>> > 2016-09-02 23:35 GMT+09:00 Tom Rini :
>> >
>> >>> >> diff --git a/arch/arm/mach-exynos/Kconfig 
>> >>> >> b/arch/arm/mach-exynos/Kconfig
>> >>> >> index c25fcf3..d4a5bc9 100644
>> >>> >> --- a/arch/arm/mach-exynos/Kconfig
>> >>> >> +++ b/arch/arm/mach-exynos/Kconfig
>> >>> >> @@ -61,6 +61,9 @@ endif
>> >>> >>
>> >>> >>  if ARCH_EXYNOS5
>> >>> >>
>> >>> >> +config SPL_GPIO_SUPPORT
>> >>> >> +   default y
>> >>> >> +
>> >>> >
>> >>> >
>> >>> > As we discussed before,
>> >>> > we decided to not do this.
>> >>>
>> >>> Tom was keen to avoid changing every defconfig file. It is there
>> >>> another way to express common defaults?
>> >>
>> >> I was thinking in the Kconfig with the entry for SPL_GPIO_SUPPORT, for
>> >> optional stuff and select in the board, etc, Kconfig for non-optional
>> >> stuff.  Now, I realize that optional vs non-optional is more the domain
>> >> of the individual SoC custodians, so we'll have some clean up afterwards
>> >> that isn't on you (well, aside from the SoCs you know like rockchip ;)).
>> >
>> > config SPL_GPIO_SUPPORT
>> >default y
>> >
>> > is incorrect because it could violate
>> > the dependency in the proper Kconfig entry in spl/Kconfig.
>>
>> But only if options depended on by this are not set, right?
>>
>> >
>> >
>> >
>> >
>> > Basically, we are supposed to use "select FOO" when it is mandatory,
>> > or add CONFIG_FOO=y in a defconfig when the board wants it, but
>> > can still make it optional.
>>
>> Yes, but this is not mandatory. It is a default, and some boards will
>> unset it. I did this in response to Tom's comment about trying to cut
>> down the defconfig patch size.
>
> Well, here is where it is tricky.  For example, in SPL when we bring in
> the GPIO code, it's because it's required to enable DDR or know which
> board rev we're on.  So it needs to be select'd or people will get
> failure to build problems.  Other things like filesystems should be an
> option.
>
>> > I know our pain comes from that "include" is not supported by Kconfig.
>>
>> How would that help? Why don't we implement it?
>
> Well, if we could more literally translate the various *common*.h files
> into a Kconfig file that was "included" it would be easier to say that
> various CONFIG variables are just a bool (or hex) and then
> board/ti/am335x/Kconfig would 'include
> include/kconfig/ti_am33xx_common.k' and get all of the stuff it
> used to get from include/configs/ti_am335x_common.h.
>
>> > What I can suggest now is:
>> >
>> >
>> >
>> > [1]  Add ARCH_WANT_* to specify a SoC-common default.
>> >
>> >
>> >config SPL_GPIO_SUPPORT
>> > bool "GPIO support for SPL"
>> > default  ARCH_WANT_SPL_GPIO_SUPPORT
>> >
>> >
>> >config ARCH_WANT_SPL_GPIO_SUPPORT
>> > bool
>> >
>> >
>> >config ARCH_EXYNOS5
>> >select ARCH_WANT_SPL_GPIO_SUPPORT
>> >
>> >
>> > Linux used to have ARCH_WANT_OPTIONAL_GPIOLIB to do similar things.
>> > (they stopped this way, though)
>
> This may be better.
>
>> > [2] Support multi boards with one defconfig
>> > (barebox supports multi-platform like Linux does.)
>
> Unless I missed something, this is just kicking the problem up a level
> frankly.  They just allow (and we could / can / do, depending on the
> SoC) one full "barebox" to be loaded by the board-specific preloader.
> We can, should, and hopefully will once DM is 'done', have this be an
> option.  But that's a different problem set from how do we configure the
> board specific part of a build.
>
>> > [3] use pre-processor to support #include <...>
>> >
>> >
>> >
>> >
>> >
>> > BTW, SPL_GPIO_SUPPORT is optional in this case?
>> >
>> > U-Boot proper supports a command line interface,
>> > while SPL is usually run in a non-interactive mode.
>> >
>> > So, what SPL needs is generally mandatory,
>> > so we can "select" it,  I guess.
>>
>> I found a lot of cases where 90% of the boards with the same SoC  had
>> the same setting for this (and a few other) options, but some boards
>> did not. So I did not want to use select, since then it is impossible
>> to unselect.
>
> Maybe this is where [1] above will work best and we can select
> ARCH_WANT_.. (or BOARD_WANT_...) from TARGET_... and leave some things
> as questions.
>
>> This series is actually really tricky. I'm looking forward to putting
>> it to bed. We need to make these conversions easier.
>
> Agreed!

I am not sure about the WANT business, but I am sure that I don't want
to work through all the SoCs and figure how how they should set it.
I'd like to get this series in since i think it is a good starting
point for improving things. Changing to WANT will be easier after that
if we want to. Also I feel this 

Re: [U-Boot] [PATCH v2 21/44] Convert CONFIG_SPL_GPIO_SUPPORT to Kconfig

[Masahiro Yamada]

2016-09-07 0:54 GMT+09:00 Tom Rini :
> On Mon, Sep 05, 2016 at 07:04:45PM -0600, Simon Glass wrote:
>> Hi Masahiro,
>>
>> On 4 September 2016 at 20:40, Masahiro Yamada
>>  wrote:
>> > 2016-09-02 23:35 GMT+09:00 Tom Rini :
>> >
>> >>> >> diff --git a/arch/arm/mach-exynos/Kconfig 
>> >>> >> b/arch/arm/mach-exynos/Kconfig
>> >>> >> index c25fcf3..d4a5bc9 100644
>> >>> >> --- a/arch/arm/mach-exynos/Kconfig
>> >>> >> +++ b/arch/arm/mach-exynos/Kconfig
>> >>> >> @@ -61,6 +61,9 @@ endif
>> >>> >>
>> >>> >>  if ARCH_EXYNOS5
>> >>> >>
>> >>> >> +config SPL_GPIO_SUPPORT
>> >>> >> +   default y
>> >>> >> +
>> >>> >
>> >>> >
>> >>> > As we discussed before,
>> >>> > we decided to not do this.
>> >>>
>> >>> Tom was keen to avoid changing every defconfig file. It is there
>> >>> another way to express common defaults?
>> >>
>> >> I was thinking in the Kconfig with the entry for SPL_GPIO_SUPPORT, for
>> >> optional stuff and select in the board, etc, Kconfig for non-optional
>> >> stuff.  Now, I realize that optional vs non-optional is more the domain
>> >> of the individual SoC custodians, so we'll have some clean up afterwards
>> >> that isn't on you (well, aside from the SoCs you know like rockchip ;)).
>> >
>> > config SPL_GPIO_SUPPORT
>> >default y
>> >
>> > is incorrect because it could violate
>> > the dependency in the proper Kconfig entry in spl/Kconfig.
>>
>> But only if options depended on by this are not set, right?
>>
>> >
>> >
>> >
>> >
>> > Basically, we are supposed to use "select FOO" when it is mandatory,
>> > or add CONFIG_FOO=y in a defconfig when the board wants it, but
>> > can still make it optional.
>>
>> Yes, but this is not mandatory. It is a default, and some boards will
>> unset it. I did this in response to Tom's comment about trying to cut
>> down the defconfig patch size.
>
> Well, here is where it is tricky.  For example, in SPL when we bring in
> the GPIO code, it's because it's required to enable DDR or know which
> board rev we're on.  So it needs to be select'd or people will get
> failure to build problems.  Other things like filesystems should be an
> option.

I agree.


>> > I know our pain comes from that "include" is not supported by Kconfig.
>>
>> How would that help? Why don't we implement it?
>
> Well, if we could more literally translate the various *common*.h files
> into a Kconfig file that was "included" it would be easier to say that
> various CONFIG variables are just a bool (or hex) and then
> board/ti/am335x/Kconfig would 'include
> include/kconfig/ti_am33xx_common.k' and get all of the stuff it
> used to get from include/configs/ti_am335x_common.h.

Yes, exactly.

The problem is we can not sync defconfigs any more.
Actually, we can only sync *common* defconfigs,
but we cannot per-board ones.


>> > What I can suggest now is:
>> >
>> >
>> >
>> > [1]  Add ARCH_WANT_* to specify a SoC-common default.
>> >
>> >
>> >config SPL_GPIO_SUPPORT
>> > bool "GPIO support for SPL"
>> > default  ARCH_WANT_SPL_GPIO_SUPPORT
>> >
>> >
>> >config ARCH_WANT_SPL_GPIO_SUPPORT
>> > bool
>> >
>> >
>> >config ARCH_EXYNOS5
>> >select ARCH_WANT_SPL_GPIO_SUPPORT
>> >
>> >
>> > Linux used to have ARCH_WANT_OPTIONAL_GPIOLIB to do similar things.
>> > (they stopped this way, though)
>
> This may be better.
>
>> > [2] Support multi boards with one defconfig
>> > (barebox supports multi-platform like Linux does.)
>
> Unless I missed something, this is just kicking the problem up a level
> frankly.  They just allow (and we could / can / do, depending on the
> SoC) one full "barebox" to be loaded by the board-specific preloader.

Right.
Barebox proper can be multi-platform
because it supports driver model and device tree.

On the other hand, barebox PBL (= correspond to U-Boot SPL)
is a per-board image.
(More precisely, per-board and per-boot-mode image)


> We can, should, and hopefully will once DM is 'done', have this be an
> option.  But that's a different problem set from how do we configure the
> board specific part of a build.


As far as I know, things are roughly like this:

The build system of barebox generates a *big* PBL object first
by compiling every source files for all of enabled boards,
enabled boot modes, like boardA_nand, boardA_mmc, boardB_nand, boardC, etc.
Then gives a different entry point for each board/boot-mode
to the linker script.

The objects unreachable from the board-specific entry point
are ripped off by the GCC garbage collection.
For example, the  board_a_init()
is unreachable from the entry point of board B/C,
so contained only in the board A PBL.

Finally, it gets small per-board/per-boot-mode PBL images.


So, there is no CONFIG options to switch the boot-flow of PBL.

For U-Boot,
we enable CONFIG_SPL_NAND_SUPPORT for  boardA_nand_defconfig,
and CONFIG_SPL_MMC_SUPPORT for boardA_mmc_defconfig.

Re: [U-Boot] [PATCH v2 21/44] Convert CONFIG_SPL_GPIO_SUPPORT to Kconfig

[Tom Rini]

On Mon, Sep 05, 2016 at 07:04:45PM -0600, Simon Glass wrote:
> Hi Masahiro,
> 
> On 4 September 2016 at 20:40, Masahiro Yamada
>  wrote:
> > 2016-09-02 23:35 GMT+09:00 Tom Rini :
> >
> >>> >> diff --git a/arch/arm/mach-exynos/Kconfig 
> >>> >> b/arch/arm/mach-exynos/Kconfig
> >>> >> index c25fcf3..d4a5bc9 100644
> >>> >> --- a/arch/arm/mach-exynos/Kconfig
> >>> >> +++ b/arch/arm/mach-exynos/Kconfig
> >>> >> @@ -61,6 +61,9 @@ endif
> >>> >>
> >>> >>  if ARCH_EXYNOS5
> >>> >>
> >>> >> +config SPL_GPIO_SUPPORT
> >>> >> +   default y
> >>> >> +
> >>> >
> >>> >
> >>> > As we discussed before,
> >>> > we decided to not do this.
> >>>
> >>> Tom was keen to avoid changing every defconfig file. It is there
> >>> another way to express common defaults?
> >>
> >> I was thinking in the Kconfig with the entry for SPL_GPIO_SUPPORT, for
> >> optional stuff and select in the board, etc, Kconfig for non-optional
> >> stuff.  Now, I realize that optional vs non-optional is more the domain
> >> of the individual SoC custodians, so we'll have some clean up afterwards
> >> that isn't on you (well, aside from the SoCs you know like rockchip ;)).
> >
> > config SPL_GPIO_SUPPORT
> >default y
> >
> > is incorrect because it could violate
> > the dependency in the proper Kconfig entry in spl/Kconfig.
> 
> But only if options depended on by this are not set, right?
> 
> >
> >
> >
> >
> > Basically, we are supposed to use "select FOO" when it is mandatory,
> > or add CONFIG_FOO=y in a defconfig when the board wants it, but
> > can still make it optional.
> 
> Yes, but this is not mandatory. It is a default, and some boards will
> unset it. I did this in response to Tom's comment about trying to cut
> down the defconfig patch size.

Well, here is where it is tricky.  For example, in SPL when we bring in
the GPIO code, it's because it's required to enable DDR or know which
board rev we're on.  So it needs to be select'd or people will get
failure to build problems.  Other things like filesystems should be an
option.

> > I know our pain comes from that "include" is not supported by Kconfig.
> 
> How would that help? Why don't we implement it?

Well, if we could more literally translate the various *common*.h files
into a Kconfig file that was "included" it would be easier to say that
various CONFIG variables are just a bool (or hex) and then
board/ti/am335x/Kconfig would 'include
include/kconfig/ti_am33xx_common.k' and get all of the stuff it
used to get from include/configs/ti_am335x_common.h.

> > What I can suggest now is:
> >
> >
> >
> > [1]  Add ARCH_WANT_* to specify a SoC-common default.
> >
> >
> >config SPL_GPIO_SUPPORT
> > bool "GPIO support for SPL"
> > default  ARCH_WANT_SPL_GPIO_SUPPORT
> >
> >
> >config ARCH_WANT_SPL_GPIO_SUPPORT
> > bool
> >
> >
> >config ARCH_EXYNOS5
> >select ARCH_WANT_SPL_GPIO_SUPPORT
> >
> >
> > Linux used to have ARCH_WANT_OPTIONAL_GPIOLIB to do similar things.
> > (they stopped this way, though)

This may be better.

> > [2] Support multi boards with one defconfig
> > (barebox supports multi-platform like Linux does.)

Unless I missed something, this is just kicking the problem up a level
frankly.  They just allow (and we could / can / do, depending on the
SoC) one full "barebox" to be loaded by the board-specific preloader.
We can, should, and hopefully will once DM is 'done', have this be an
option.  But that's a different problem set from how do we configure the
board specific part of a build.

> > [3] use pre-processor to support #include <...>
> >
> >
> >
> >
> >
> > BTW, SPL_GPIO_SUPPORT is optional in this case?
> >
> > U-Boot proper supports a command line interface,
> > while SPL is usually run in a non-interactive mode.
> >
> > So, what SPL needs is generally mandatory,
> > so we can "select" it,  I guess.
> 
> I found a lot of cases where 90% of the boards with the same SoC  had
> the same setting for this (and a few other) options, but some boards
> did not. So I did not want to use select, since then it is impossible
> to unselect.

Maybe this is where [1] above will work best and we can select
ARCH_WANT_.. (or BOARD_WANT_...) from TARGET_... and leave some things
as questions.

> This series is actually really tricky. I'm looking forward to putting
> it to bed. We need to make these conversions easier.

Agreed!

-- 
Tom


signature.asc
Description: Digital signature
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v2 21/44] Convert CONFIG_SPL_GPIO_SUPPORT to Kconfig

[Simon Glass]

Hi Masahiro,

On 4 September 2016 at 20:40, Masahiro Yamada
 wrote:
> 2016-09-02 23:35 GMT+09:00 Tom Rini :
>
>>> >> diff --git a/arch/arm/mach-exynos/Kconfig b/arch/arm/mach-exynos/Kconfig
>>> >> index c25fcf3..d4a5bc9 100644
>>> >> --- a/arch/arm/mach-exynos/Kconfig
>>> >> +++ b/arch/arm/mach-exynos/Kconfig
>>> >> @@ -61,6 +61,9 @@ endif
>>> >>
>>> >>  if ARCH_EXYNOS5
>>> >>
>>> >> +config SPL_GPIO_SUPPORT
>>> >> +   default y
>>> >> +
>>> >
>>> >
>>> > As we discussed before,
>>> > we decided to not do this.
>>>
>>> Tom was keen to avoid changing every defconfig file. It is there
>>> another way to express common defaults?
>>
>> I was thinking in the Kconfig with the entry for SPL_GPIO_SUPPORT, for
>> optional stuff and select in the board, etc, Kconfig for non-optional
>> stuff.  Now, I realize that optional vs non-optional is more the domain
>> of the individual SoC custodians, so we'll have some clean up afterwards
>> that isn't on you (well, aside from the SoCs you know like rockchip ;)).
>
> config SPL_GPIO_SUPPORT
>default y
>
> is incorrect because it could violate
> the dependency in the proper Kconfig entry in spl/Kconfig.

But only if options depended on by this are not set, right?

>
>
>
>
> Basically, we are supposed to use "select FOO" when it is mandatory,
> or add CONFIG_FOO=y in a defconfig when the board wants it, but
> can still make it optional.

Yes, but this is not mandatory. It is a default, and some boards will
unset it. I did this in response to Tom's comment about trying to cut
down the defconfig patch size.

>
>
> I know our pain comes from that "include" is not supported by Kconfig.

How would that help? Why don't we implement it?

>
> What I can suggest now is:
>
>
>
> [1]  Add ARCH_WANT_* to specify a SoC-common default.
>
>
>config SPL_GPIO_SUPPORT
> bool "GPIO support for SPL"
> default  ARCH_WANT_SPL_GPIO_SUPPORT
>
>
>config ARCH_WANT_SPL_GPIO_SUPPORT
> bool
>
>
>config ARCH_EXYNOS5
>select ARCH_WANT_SPL_GPIO_SUPPORT
>
>
> Linux used to have ARCH_WANT_OPTIONAL_GPIOLIB to do similar things.
> (they stopped this way, though)
>
>
>
> [2] Support multi boards with one defconfig
> (barebox supports multi-platform like Linux does.)
>
>
> [3] use pre-processor to support #include <...>
>
>
>
>
>
> BTW, SPL_GPIO_SUPPORT is optional in this case?
>
> U-Boot proper supports a command line interface,
> while SPL is usually run in a non-interactive mode.
>
> So, what SPL needs is generally mandatory,
> so we can "select" it,  I guess.

I found a lot of cases where 90% of the boards with the same SoC  had
the same setting for this (and a few other) options, but some boards
did not. So I did not want to use select, since then it is impossible
to unselect.

This series is actually really tricky. I'm looking forward to putting
it to bed. We need to make these conversions easier.

Regards,
Simon
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v2 21/44] Convert CONFIG_SPL_GPIO_SUPPORT to Kconfig

[Masahiro Yamada]

2016-09-02 23:35 GMT+09:00 Tom Rini :

>> >> diff --git a/arch/arm/mach-exynos/Kconfig b/arch/arm/mach-exynos/Kconfig
>> >> index c25fcf3..d4a5bc9 100644
>> >> --- a/arch/arm/mach-exynos/Kconfig
>> >> +++ b/arch/arm/mach-exynos/Kconfig
>> >> @@ -61,6 +61,9 @@ endif
>> >>
>> >>  if ARCH_EXYNOS5
>> >>
>> >> +config SPL_GPIO_SUPPORT
>> >> +   default y
>> >> +
>> >
>> >
>> > As we discussed before,
>> > we decided to not do this.
>>
>> Tom was keen to avoid changing every defconfig file. It is there
>> another way to express common defaults?
>
> I was thinking in the Kconfig with the entry for SPL_GPIO_SUPPORT, for
> optional stuff and select in the board, etc, Kconfig for non-optional
> stuff.  Now, I realize that optional vs non-optional is more the domain
> of the individual SoC custodians, so we'll have some clean up afterwards
> that isn't on you (well, aside from the SoCs you know like rockchip ;)).

config SPL_GPIO_SUPPORT
   default y

is incorrect because it could violate
the dependency in the proper Kconfig entry in spl/Kconfig.




Basically, we are supposed to use "select FOO" when it is mandatory,
or add CONFIG_FOO=y in a defconfig when the board wants it, but
can still make it optional.


I know our pain comes from that "include" is not supported by Kconfig.

What I can suggest now is:



[1]  Add ARCH_WANT_* to specify a SoC-common default.


   config SPL_GPIO_SUPPORT
bool "GPIO support for SPL"
default  ARCH_WANT_SPL_GPIO_SUPPORT


   config ARCH_WANT_SPL_GPIO_SUPPORT
bool


   config ARCH_EXYNOS5
   select ARCH_WANT_SPL_GPIO_SUPPORT


Linux used to have ARCH_WANT_OPTIONAL_GPIOLIB to do similar things.
(they stopped this way, though)



[2] Support multi boards with one defconfig
(barebox supports multi-platform like Linux does.)


[3] use pre-processor to support #include <...>





BTW, SPL_GPIO_SUPPORT is optional in this case?

U-Boot proper supports a command line interface,
while SPL is usually run in a non-interactive mode.

So, what SPL needs is generally mandatory,
so we can "select" it,  I guess.

-- 
Best Regards
Masahiro Yamada
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v2 21/44] Convert CONFIG_SPL_GPIO_SUPPORT to Kconfig

[Tom Rini]

On Tue, Aug 30, 2016 at 12:33:05PM -0600, Simon Glass wrote:
> Hi Masahiro,
> 
> On 29 August 2016 at 21:25, Masahiro Yamada
>  wrote:
> > 2016-08-30 9:21 GMT+09:00 Simon Glass :
> >> Move this option to Kconfig and tidy up existing uses.
> >>
> >> Signed-off-by: Simon Glass 
> >
> >>
> >> diff --git a/arch/arm/cpu/armv7/am33xx/Kconfig 
> >> b/arch/arm/cpu/armv7/am33xx/Kconfig
> >> index efbc219..54474c2 100644
> >> --- a/arch/arm/cpu/armv7/am33xx/Kconfig
> >> +++ b/arch/arm/cpu/armv7/am33xx/Kconfig
> >> @@ -3,6 +3,9 @@ if AM43XX
> >>  config SPL_EXT_SUPPORT
> >> default y
> >>
> >> +config SPL_GPIO_SUPPORT
> >> +   default y
> >> +
> >>  config TARGET_AM43XX_EVM
> >> bool "Support am43xx_evm"
> >> select TI_I2C_BOARD_DETECT
> >> diff --git a/arch/arm/cpu/armv7/omap3/Kconfig 
> >> b/arch/arm/cpu/armv7/omap3/Kconfig
> >> index de65ac6..e1c981e 100644
> >> --- a/arch/arm/cpu/armv7/omap3/Kconfig
> >> +++ b/arch/arm/cpu/armv7/omap3/Kconfig
> >> @@ -6,6 +6,9 @@ config SPL_EXT_SUPPORT
> >>  config SPL_FAT_SUPPORT
> >> default y
> >>
> >> +config SPL_GPIO_SUPPORT
> >> +   default y
> >> +
> >>  choice
> >> prompt "OMAP3 board select"
> >> optional
> >> diff --git a/arch/arm/cpu/armv7/omap4/Kconfig 
> >> b/arch/arm/cpu/armv7/omap4/Kconfig
> >> index 92eb2f4..48ce9d3 100644
> >> --- a/arch/arm/cpu/armv7/omap4/Kconfig
> >> +++ b/arch/arm/cpu/armv7/omap4/Kconfig
> >> @@ -6,6 +6,9 @@ config SPL_EXT_SUPPORT
> >>  config SPL_FAT_SUPPORT
> >> default y
> >>
> >> +config SPL_GPIO_SUPPORT
> >> +   default y
> >> +
> >>  choice
> >> prompt "OMAP4 board select"
> >> optional
> >> diff --git a/arch/arm/cpu/armv7/omap5/Kconfig 
> >> b/arch/arm/cpu/armv7/omap5/Kconfig
> >> index e367828..5b049ad 100644
> >> --- a/arch/arm/cpu/armv7/omap5/Kconfig
> >> +++ b/arch/arm/cpu/armv7/omap5/Kconfig
> >> @@ -6,6 +6,9 @@ config SPL_EXT_SUPPORT
> >>  config SPL_FAT_SUPPORT
> >> default y
> >>
> >> +config SPL_GPIO_SUPPORT
> >> +   default y
> >> +
> >>  choice
> >> prompt "OMAP5 board select"
> >> optional
> >> diff --git a/arch/arm/mach-exynos/Kconfig b/arch/arm/mach-exynos/Kconfig
> >> index c25fcf3..d4a5bc9 100644
> >> --- a/arch/arm/mach-exynos/Kconfig
> >> +++ b/arch/arm/mach-exynos/Kconfig
> >> @@ -61,6 +61,9 @@ endif
> >>
> >>  if ARCH_EXYNOS5
> >>
> >> +config SPL_GPIO_SUPPORT
> >> +   default y
> >> +
> >
> >
> > As we discussed before,
> > we decided to not do this.
> 
> Tom was keen to avoid changing every defconfig file. It is there
> another way to express common defaults?

I was thinking in the Kconfig with the entry for SPL_GPIO_SUPPORT, for
optional stuff and select in the board, etc, Kconfig for non-optional
stuff.  Now, I realize that optional vs non-optional is more the domain
of the individual SoC custodians, so we'll have some clean up afterwards
that isn't on you (well, aside from the SoCs you know like rockchip ;)).

-- 
Tom


signature.asc
Description: Digital signature
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v2 21/44] Convert CONFIG_SPL_GPIO_SUPPORT to Kconfig

[Simon Glass]

Hi Masahiro,

On 29 August 2016 at 21:25, Masahiro Yamada
 wrote:
> 2016-08-30 9:21 GMT+09:00 Simon Glass :
>> Move this option to Kconfig and tidy up existing uses.
>>
>> Signed-off-by: Simon Glass 
>
>>
>> diff --git a/arch/arm/cpu/armv7/am33xx/Kconfig 
>> b/arch/arm/cpu/armv7/am33xx/Kconfig
>> index efbc219..54474c2 100644
>> --- a/arch/arm/cpu/armv7/am33xx/Kconfig
>> +++ b/arch/arm/cpu/armv7/am33xx/Kconfig
>> @@ -3,6 +3,9 @@ if AM43XX
>>  config SPL_EXT_SUPPORT
>> default y
>>
>> +config SPL_GPIO_SUPPORT
>> +   default y
>> +
>>  config TARGET_AM43XX_EVM
>> bool "Support am43xx_evm"
>> select TI_I2C_BOARD_DETECT
>> diff --git a/arch/arm/cpu/armv7/omap3/Kconfig 
>> b/arch/arm/cpu/armv7/omap3/Kconfig
>> index de65ac6..e1c981e 100644
>> --- a/arch/arm/cpu/armv7/omap3/Kconfig
>> +++ b/arch/arm/cpu/armv7/omap3/Kconfig
>> @@ -6,6 +6,9 @@ config SPL_EXT_SUPPORT
>>  config SPL_FAT_SUPPORT
>> default y
>>
>> +config SPL_GPIO_SUPPORT
>> +   default y
>> +
>>  choice
>> prompt "OMAP3 board select"
>> optional
>> diff --git a/arch/arm/cpu/armv7/omap4/Kconfig 
>> b/arch/arm/cpu/armv7/omap4/Kconfig
>> index 92eb2f4..48ce9d3 100644
>> --- a/arch/arm/cpu/armv7/omap4/Kconfig
>> +++ b/arch/arm/cpu/armv7/omap4/Kconfig
>> @@ -6,6 +6,9 @@ config SPL_EXT_SUPPORT
>>  config SPL_FAT_SUPPORT
>> default y
>>
>> +config SPL_GPIO_SUPPORT
>> +   default y
>> +
>>  choice
>> prompt "OMAP4 board select"
>> optional
>> diff --git a/arch/arm/cpu/armv7/omap5/Kconfig 
>> b/arch/arm/cpu/armv7/omap5/Kconfig
>> index e367828..5b049ad 100644
>> --- a/arch/arm/cpu/armv7/omap5/Kconfig
>> +++ b/arch/arm/cpu/armv7/omap5/Kconfig
>> @@ -6,6 +6,9 @@ config SPL_EXT_SUPPORT
>>  config SPL_FAT_SUPPORT
>> default y
>>
>> +config SPL_GPIO_SUPPORT
>> +   default y
>> +
>>  choice
>> prompt "OMAP5 board select"
>> optional
>> diff --git a/arch/arm/mach-exynos/Kconfig b/arch/arm/mach-exynos/Kconfig
>> index c25fcf3..d4a5bc9 100644
>> --- a/arch/arm/mach-exynos/Kconfig
>> +++ b/arch/arm/mach-exynos/Kconfig
>> @@ -61,6 +61,9 @@ endif
>>
>>  if ARCH_EXYNOS5
>>
>> +config SPL_GPIO_SUPPORT
>> +   default y
>> +
>
>
> As we discussed before,
> we decided to not do this.

Tom was keen to avoid changing every defconfig file. It is there
another way to express common defaults?

Regards,
Simon
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v2 21/44] Convert CONFIG_SPL_GPIO_SUPPORT to Kconfig

[Masahiro Yamada]

2016-08-30 9:21 GMT+09:00 Simon Glass :
> Move this option to Kconfig and tidy up existing uses.
>
> Signed-off-by: Simon Glass 

>
> diff --git a/arch/arm/cpu/armv7/am33xx/Kconfig 
> b/arch/arm/cpu/armv7/am33xx/Kconfig
> index efbc219..54474c2 100644
> --- a/arch/arm/cpu/armv7/am33xx/Kconfig
> +++ b/arch/arm/cpu/armv7/am33xx/Kconfig
> @@ -3,6 +3,9 @@ if AM43XX
>  config SPL_EXT_SUPPORT
> default y
>
> +config SPL_GPIO_SUPPORT
> +   default y
> +
>  config TARGET_AM43XX_EVM
> bool "Support am43xx_evm"
> select TI_I2C_BOARD_DETECT
> diff --git a/arch/arm/cpu/armv7/omap3/Kconfig 
> b/arch/arm/cpu/armv7/omap3/Kconfig
> index de65ac6..e1c981e 100644
> --- a/arch/arm/cpu/armv7/omap3/Kconfig
> +++ b/arch/arm/cpu/armv7/omap3/Kconfig
> @@ -6,6 +6,9 @@ config SPL_EXT_SUPPORT
>  config SPL_FAT_SUPPORT
> default y
>
> +config SPL_GPIO_SUPPORT
> +   default y
> +
>  choice
> prompt "OMAP3 board select"
> optional
> diff --git a/arch/arm/cpu/armv7/omap4/Kconfig 
> b/arch/arm/cpu/armv7/omap4/Kconfig
> index 92eb2f4..48ce9d3 100644
> --- a/arch/arm/cpu/armv7/omap4/Kconfig
> +++ b/arch/arm/cpu/armv7/omap4/Kconfig
> @@ -6,6 +6,9 @@ config SPL_EXT_SUPPORT
>  config SPL_FAT_SUPPORT
> default y
>
> +config SPL_GPIO_SUPPORT
> +   default y
> +
>  choice
> prompt "OMAP4 board select"
> optional
> diff --git a/arch/arm/cpu/armv7/omap5/Kconfig 
> b/arch/arm/cpu/armv7/omap5/Kconfig
> index e367828..5b049ad 100644
> --- a/arch/arm/cpu/armv7/omap5/Kconfig
> +++ b/arch/arm/cpu/armv7/omap5/Kconfig
> @@ -6,6 +6,9 @@ config SPL_EXT_SUPPORT
>  config SPL_FAT_SUPPORT
> default y
>
> +config SPL_GPIO_SUPPORT
> +   default y
> +
>  choice
> prompt "OMAP5 board select"
> optional
> diff --git a/arch/arm/mach-exynos/Kconfig b/arch/arm/mach-exynos/Kconfig
> index c25fcf3..d4a5bc9 100644
> --- a/arch/arm/mach-exynos/Kconfig
> +++ b/arch/arm/mach-exynos/Kconfig
> @@ -61,6 +61,9 @@ endif
>
>  if ARCH_EXYNOS5
>
> +config SPL_GPIO_SUPPORT
> +   default y
> +


As we discussed before,
we decided to not do this.





-- 
Best Regards
Masahiro Yamada
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH v2 21/44] Convert CONFIG_SPL_GPIO_SUPPORT to Kconfig

[Simon Glass]

Move this option to Kconfig and tidy up existing uses.

Signed-off-by: Simon Glass 
---

Changes in v2: None

 arch/arm/cpu/armv7/am33xx/Kconfig| 3 +++
 arch/arm/cpu/armv7/omap3/Kconfig | 3 +++
 arch/arm/cpu/armv7/omap4/Kconfig | 3 +++
 arch/arm/cpu/armv7/omap5/Kconfig | 3 +++
 arch/arm/mach-exynos/Kconfig | 3 +++
 arch/arm/mach-tegra/Kconfig  | 3 +++
 board/sunxi/Kconfig  | 3 +++
 board/ti/common/Kconfig  | 3 +++
 configs/am335x_baltos_defconfig  | 1 +
 configs/am335x_igep0033_defconfig| 1 +
 configs/am335x_shc_defconfig | 1 +
 configs/am335x_shc_ict_defconfig | 1 +
 configs/am335x_shc_netboot_defconfig | 1 +
 configs/am335x_shc_prompt_defconfig  | 1 +
 configs/am335x_shc_sdboot_defconfig  | 1 +
 configs/am335x_shc_sdboot_prompt_defconfig   | 1 +
 configs/am335x_sl50_defconfig| 1 +
 configs/apx4devkit_defconfig | 1 +
 configs/at91sam9m10g45ek_mmc_defconfig   | 1 +
 configs/at91sam9m10g45ek_nandflash_defconfig | 1 +
 configs/at91sam9n12ek_nandflash_defconfig| 1 +
 configs/at91sam9n12ek_spiflash_defconfig | 1 +
 configs/at91sam9x5ek_nandflash_defconfig | 1 +
 configs/at91sam9x5ek_spiflash_defconfig  | 1 +
 configs/axm_defconfig| 1 +
 configs/bg0900_defconfig | 1 +
 configs/birdland_bav335a_defconfig   | 1 +
 configs/birdland_bav335b_defconfig   | 1 +
 configs/brppt1_mmc_defconfig | 1 +
 configs/brppt1_nand_defconfig| 1 +
 configs/brppt1_spi_defconfig | 1 +
 configs/brxre1_defconfig | 1 +
 configs/cgtqmx6eval_defconfig| 1 +
 configs/cm_fx6_defconfig | 1 +
 configs/cm_t335_defconfig| 1 +
 configs/corvus_defconfig | 1 +
 configs/draco_defconfig  | 1 +
 configs/etamin_defconfig | 1 +
 configs/gwventana_defconfig  | 1 +
 configs/ipam390_defconfig| 1 +
 configs/m28evk_defconfig | 1 +
 configs/m53evk_defconfig | 1 +
 configs/ma5d4evk_defconfig   | 1 +
 configs/mx23_olinuxino_defconfig | 1 +
 configs/mx23evk_defconfig| 1 +
 configs/mx28evk_auart_console_defconfig  | 1 +
 configs/mx28evk_defconfig| 1 +
 configs/mx28evk_nand_defconfig   | 1 +
 configs/mx28evk_spi_defconfig| 1 +
 configs/mx6cuboxi_defconfig  | 1 +
 configs/mx6sabresd_spl_defconfig | 1 +
 configs/mx6slevk_spl_defconfig   | 1 +
 configs/mx6sxsabresd_spl_defconfig   | 1 +
 configs/mx6ul_14x14_evk_defconfig| 1 +
 configs/mx6ul_9x9_evk_defconfig  | 1 +
 configs/novena_defconfig | 1 +
 configs/ot1200_spl_defconfig | 1 +
 configs/pcm051_rev1_defconfig| 1 +
 configs/pcm051_rev3_defconfig| 1 +
 configs/pcm058_defconfig | 1 +
 configs/pengwyn_defconfig| 1 +
 configs/pepper_defconfig | 1 +
 configs/picosam9g45_defconfig| 1 +
 configs/platinum_picon_defconfig | 1 +
 configs/platinum_titanium_defconfig  | 1 +
 configs/pxm2_defconfig   | 1 +
 configs/rastaban_defconfig   | 1 +
 configs/rut_defconfig| 1 +
 configs/sama5d2_ptc_nandflash_defconfig  | 1 +
 configs/sama5d2_ptc_spiflash_defconfig   | 1 +
 configs/sama5d2_xplained_mmc_defconfig   | 1 +
 configs/sama5d2_xplained_spiflash_defconfig  | 1 +
 configs/sama5d3_xplained_mmc_defconfig   | 1 +
 configs/sama5d3_xplained_nandflash_defconfig | 1 +
 configs/sama5d3xek_mmc_defconfig | 1 +
 configs/sama5d3xek_nandflash_defconfig   | 1 +
 configs/sama5d3xek_spiflash_defconfig| 1 +
 configs/sama5d4_xplained_mmc_defconfig   | 1 +
 configs/sama5d4_xplained_nandflash_defconfig | 1 +
 configs/sama5d4_xplained_spiflash_defconfig  | 1 +
 configs/sama5d4ek_mmc_defconfig  | 1 +
 configs/sama5d4ek_nandflash_defconfig| 1 +
 configs/sama5d4ek_spiflash_defconfig | 1 +
 configs/sansa_fuze_plus_defconfig| 1 +
 configs/sc_sps_1_defconfig   | 1 +
 configs/smartweb_defconfig   | 1 +
 configs/taurus_defconfig | 1 +
 configs/thuban_defconfig | 1 +
 configs/ti814x_evm_defconfig | 1 +
 configs/ti816x_evm_defconfig | 1 +
 configs/udoo_defconfig   | 1 +
 configs/wandboard_defconfig  | 1 +
 configs/woodburn_sd_defconfig| 1 +