[PATCH 3/3] arm: mvebu: helios-4: add defconfig for spi booting

[Josua Mayer]

Am 14.01.24 um 15:37 schrieb Tom Rini:
> On Sun, Jan 14, 2024 at 09:47:31AM +0000, Josua Mayer wrote:
>> Hi Tim,
>>
>> Am 13.01.24 um 18:22 schrieb Tom Rini:
>>> On Sat, Jan 13, 2024 at 05:36:57PM +0100, Josua Mayer wrote:
>>>
>>>> Add a new defconfig based on existing helios4_config file to support
>>>> booting from spi flash.
>>>>
>>>> Settings for environment location are based on vendor u-boot:
>>>> https://github.com/kobol-io/u-boot/blob/helios4/include/configs/helios4.h#L59
>>>>
>>>> A separate defconfig is required because the options are not
>>>> intuitive from menuconfig, numeric values in particular.
>>>>
>>>> Signed-off-by: Josua Mayer <josua at solid-run.com>
>>>> ---
>>>>  configs/helios4_spi_defconfig | 81 +++++++++++++++++++++++++++++++++++++++++++
>>>>  1 file changed, 81 insertions(+)
>>> So, a super new thing that might be of interest, but please try this
>>> since I'd like to prove/disprove the use-case.  This could instead be:
>>> configs/helios4_spi_defconfig:
>>> #include "configs/helios4_defconfig"
>>> ... enable/disable options specific to the SPI boot use case ...
>> I will try it, I like the idea conceptually.
> OK.
>
>>> And so now both boards will otherwise be kept in-sync for general config
>>> changes.  It could further be done as:
>>> configs/helios4_spi_defconfig:
>>> #include "configs/helios4_defconfig"
>>> #include "board/kobol/helios4/spiboot.config"
>> Here is potential for making it infinitely complex.
>> E.g. one might argue there should be an armada38x_spi.config
> Yes, and it depends a little on the use cases of the hardware platforms
> what makes the most sense. Today we have some Tegra platforms that
> started out using config fragments, but thinking about it right now
> should perhaps change to this style of defconfig.
Using the fragments avoids adding more defconfig files,
and adding to MAINTAINERS file.
So I attempt this method for v2.

My reasoning would be that boot media related options
are mostly maintainers choices to be made once per product,
and then kept constant. So it fits better in board/ directory than configs/.

> On the other hand, TI
> is intentionally adding feature.config fragments as the "feature.config"
> doesn't change between parts of the K3 family and should also be re-used
> on custom designs to enable that feature. Things are new enough here
> that I want people to experiment and see what works best for their use
> cases rather than providing strict rules just yet.
>