[U-Boot] [RFC PATCH] sunxi: support board-specific configuration options

[Hans de Goede]

Hi,

On 24-08-15 11:18, Bernhard Nortmann wrote:
> Hi Hans!
>
> I agree that picking user-defined LEDs as an example might not have been the
> best choice. Stuff like that should probably go into more 'generic' frameworks,
> e.g. a place to deal with those would be to define them in the device tree and
> have a proper driver handling them.
>
> Unfortunately I can't think of another prominent/convincing example for this
> kind of tweaking... (maybe board-specific hardware quirks?)
>
> IIRC, I started the whole thing while trying to incorporate some 'personal'
> config changes (like support for the "led" command, a modified "bootcmd"
> and netconsole activation). The difficulty I encountered with that was that
> while the build system seems to accept certain options, it would happily
> ignore other CONFIG_* settings from the *_defconfig (anything not in
> Kconfig?), which led me to take the ".h include" route.
>
> Many other boards seem to use a similar approach, often with quite
> minimal .h files (e.g. include/configs/xilinx-ppc440.h or rpi.h)
> I understand that this might be "old" U-Boot configuration style,
> and thus deprecated - that's certainly a valid objection.

Right, introducing new CONFIG_FOO_BAR defines without having them defined
through a Kconfig file is not really something we want to do. In general
for any new option we will need a new Kconfig entry.

And you're also right that you can only set CONFIG_FOO_BAR defines through
the defconfig if they are defined in a Kconfig file.

Note please also ask yourself "do we really need a new option for this?"
before adding new options. e.g. enabling extra commands typically is something
which we likely will want to do for all sunxi boards, rather then just
one or two, since if it is useful on one board it is likely useful on all
the others too, and post SPL we are not really space constrained.

Regards,

Hans



>
> Regards, B. Nortmann
>
>
> Am 22.08.2015 16:02, schrieb Hans de Goede:
>>
>> We want to move away from using CONFIG_SYS_EXTRA_OPTIONS, not start using
>> more of them.
>>
>> The proper way to deal with this would be to allow defining one or more
>> LED gpio pins in Kconfig, like e.g. the USB?_VBUS_PIN config options
>> in board/sunxi/Kconfig, and then modify the generic code paths so that
>> these will be used when set.
>>
>> This way we get led support for all boards in one go (once all the
>> defconfig-s are updated to set the gpio pins), and we do not end up
>> with board specific code.
>>
>> Regards,
>>
>> Hans
>