From: Tom Rini <trini@konsulko.com>
To: u-boot@lists.denx.de
Subject: [U-Boot] Kconfig options for several boards
Date: Fri, 7 Jun 2019 09:42:29 -0400 [thread overview]
Message-ID: <20190607134229.GL10942@bill-the-cat> (raw)
In-Reply-To: <e835945c1e304f19ac6060fdfdf6dd97@edu.hefr.ch>
On Thu, Jun 06, 2019 at 11:40:08AM +0000, Linder Pascal wrote:
> Hi everyone,
>
>
> I would like to turn on configurations for several Keymile boards, which are all using the Kirkwood architecture. Now, I do not want to change every defconfig file one after the other. Until now, we have used a common header file, but with the conversion to Kconfig another method has to be elaborated.
>
>
> While searching in the U-Boot source code, I found two different manners to fulfill our needs:
>
>
> * in arch/arm/mach-kirkwood/Kconfig:
>
> config TARGET_KM_KIRKWOOD
> bool "KM_KIRKWOOD Board"
> select BOARD_LATE_INIT
> select DM
> select DM_SPI
> select DM_SPI_FLASH
> imply CMD_CRAMFS
> imply CMD_DIAG
> imply FS_CRAMFS
>
>
> * in board/keymile/km_arm/Kconfig:
>
> config BOARD_SPECIFIC_OPTIONS # dummy
> def_bool y
> select DM
> select DM_SPI
> select DM_SPI_FLASH
>
> Which one do you guys prefer and for what reasons? Also, I would like to know what the dummy keyword is doing in the second proposition (found that in every usage of BOARD_SPECIFIC_OPTIONS).
In the second example, "dummy" is just a comment to note that it's not a
really user-visible option. I'm not sure if (for end-user ability to
change things) it's better or worse than arch/.../Kconfig and doing
options under the TARGET_xxx part or the third option is something like
board/ti/common/Kconfig::TI_COMMON_CMD_OPTIONS where we ask the user if
they want to grab a bunch of other options for a consistent experience.
That said, it really depends on what the options in question are even
about. If it's "the user should have the following commands enabled"
BOARD_SPECIFIC_OPTIONS and imply seems reasonable. And maybe we should
make more use of this as an alternative to adding "default y if ..."
statements to various Kconfig files. If we're talking about "in order
to function at all we need to enable .." that should be select'ed with
the TARGET_xxx option, and perhaps there should be a common symbol
between these platforms so N targets select that rather than N targets
select M options.
Hope that helps!
--
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20190607/583ad581/attachment.sig>
prev parent reply other threads:[~2019-06-07 13:42 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-06-06 11:40 [U-Boot] Kconfig options for several boards Linder Pascal
2019-06-07 13:42 ` Tom Rini [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20190607134229.GL10942@bill-the-cat \
--to=trini@konsulko.com \
--cc=u-boot@lists.denx.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox