From mboxrd@z Thu Jan  1 00:00:00 1970
From: Bernhard Nortmann <bernhard.nortmann@web.de>
Date: Mon, 24 Aug 2015 11:18:26 +0200
Subject: [U-Boot] [RFC PATCH] sunxi: support board-specific
	configuration options
In-Reply-To: <55D880E5.2040407@redhat.com>
References: <1440244364-11752-1-git-send-email-bernhard.nortmann@web.de>
 <1440244364-11752-2-git-send-email-bernhard.nortmann@web.de>
 <55D880E5.2040407@redhat.com>
Message-ID: <55DAE162.7010303@web.de>
List-Id: <u-boot.lists.denx.de>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
To: u-boot@lists.denx.de

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