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.
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
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
