From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ian Campbell Date: Mon, 06 Oct 2014 09:22:17 +0100 Subject: [U-Boot] [PATCH for-next 0/3] sunxi: Kconfig consolidation and cleanup In-Reply-To: <20141006111642.D7C9.AA925319@jp.panasonic.com> References: <1412412466.17796.65.camel@hellion.org.uk> <1412415124.12707.2.camel@hellion.org.uk> <20141006111642.D7C9.AA925319@jp.panasonic.com> Message-ID: <1412583737.12695.40.camel@hellion.org.uk> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de 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 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 > >