U-Boot Archive on lore.kernel.org
 help / color / mirror / Atom feed
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>

      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