From: Ian Campbell <ijc@hellion.org.uk>
To: u-boot@lists.denx.de
Subject: [U-Boot] [PATCH for-next 0/3] sunxi: Kconfig consolidation and cleanup
Date: Mon, 06 Oct 2014 09:22:17 +0100 [thread overview]
Message-ID: <1412583737.12695.40.camel@hellion.org.uk> (raw)
In-Reply-To: <20141006111642.D7C9.AA925319@jp.panasonic.com>
On Mon, 2014-10-06 at 11:16 +0900, Masahiro Yamada wrote:
> Hi Ian,
>
> On Sat, 04 Oct 2014 10:32:04 +0100
> Ian Campbell <ijc@hellion.org.uk> wrote:
>
> > On Sat, 2014-10-04 at 09:47 +0100, Ian Campbell wrote:
> > > Probably the board [...] selection could be moved out
> > > without any dependencies, although the board one in particular will be
> > > quite a big patch I think it would be worth it.
> >
> > On the topic of board selection which way round should the SoC vs. board
> > options be arrange? Should we have invisible TARGET_SUN?I options which
> > are selected by each board, or should we have the boards depend on the
> > appropriate TARGET?
> >
> > In the first case a user would need to choose from a pretty long list of
> > boards, in the second case they would need to know which SoC the board
> > has.
> >
> > I'm leaning towards the first.
>
>
> Either would work, but as for Tegra, the second one has been chosen.
Thanks. I think global consistency is a worthwhile goal, so sunxi should
follow the same pattern.
>
>
> Architecture select (CONFIG_ARCH)
> -> Tegra Platform (CONFIG_TEGRA)
> -> Tegra SoC select (CONFIG_TEGRA20 / 30 / 114 / 124)
> -> Board select
>
>
>
>
> > I don't think either would be an impediment to an eventually single
> > common binary which I'm imagining would appear as a "Generic board"
> > option which depends/selects all appropriate SoCs.
>
>
>
>
> Best Regards
> Masahiro Yamada
>
>
prev parent reply other threads:[~2014-10-06 8:22 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-10-04 8:47 [U-Boot] [PATCH for-next 0/3] sunxi: Kconfig consolidation and cleanup Ian Campbell
2014-10-04 8:48 ` [U-Boot] [PATCH for-next 1/3] sunxi: Kconfig: Consolidate SYS_CONFIG_NAME settings Ian Campbell
2014-10-06 7:48 ` Hans de Goede
2014-10-06 8:23 ` Ian Campbell
2014-10-04 8:48 ` [U-Boot] [PATCH for-next 2/3] sunxi: kconfig: Add top-level TARGET_SUNXI Ian Campbell
2014-10-05 2:37 ` Chen-Yu Tsai
2014-10-06 1:39 ` Masahiro Yamada
2014-10-06 8:27 ` Ian Campbell
2014-10-06 10:54 ` Masahiro Yamada
2014-10-22 19:14 ` Ian Campbell
2014-10-24 11:46 ` Masahiro Yamada
2014-10-24 13:22 ` Ian Campbell
2014-10-24 14:04 ` Hans de Goede
2014-10-26 16:55 ` Masahiro YAMADA
2014-10-06 7:55 ` Hans de Goede
2014-10-04 8:48 ` [U-Boot] [PATCH for-next 3/3] sunxi: Kconfig: Make SPL_FEL a toplevel Kconfig option Ian Campbell
2014-10-06 7:58 ` Hans de Goede
2014-10-06 8:28 ` Ian Campbell
2014-10-06 8:43 ` Hans de Goede
2014-10-04 9:32 ` [U-Boot] [PATCH for-next 0/3] sunxi: Kconfig consolidation and cleanup Ian Campbell
2014-10-06 2:16 ` Masahiro Yamada
2014-10-06 8:22 ` Ian Campbell [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=1412583737.12695.40.camel@hellion.org.uk \
--to=ijc@hellion.org.uk \
--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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.