Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932200Ab2EJLO4 (ORCPT ); Thu, 10 May 2012 07:14:56 -0400 Received: from trinity.fluff.org ([89.16.178.74]:39328 "EHLO trinity.fluff.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753121Ab2EJLOR (ORCPT ); Thu, 10 May 2012 07:14:17 -0400 Date: Thu, 10 May 2012 11:41:36 +0100 From: Ben Dooks To: Mark Brown Cc: Wolfgang Denk , linux-embedded@vger.kernel.org, Samuel Ortiz , Arnd Bergmann , Stephen Warren , Linus Walleij , linux-kernel@vger.kernel.org, Igor Grinberg , Olof Johansson , Lee Jones , Arnd Bergmann , linux-arm-kernel@lists.infradead.org Subject: Re: Handling of modular boards Message-ID: <20120510104136.GA30103@trinity.fluff.org> References: <20120504185850.GO14230@opensource.wolfsonmicro.com> <201205041934.08830.arnd@arndb.de> <20120504203357.6B79B206451@gemini.denx.de> <20120504220944.GT14230@opensource.wolfsonmicro.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20120504220944.GT14230@opensource.wolfsonmicro.com> X-Disclaimer: These are my views alone. X-URL: http://www.fluff.org/ User-Agent: Mutt/1.5.20 (2009-06-14) X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: ben@trinity.fluff.org X-SA-Exim-Scanned: No (on trinity.fluff.org); SAEximRunCond expanded to false Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1606 Lines: 36 On Fri, May 04, 2012 at 11:09:45PM +0100, Mark Brown wrote: > On Fri, May 04, 2012 at 10:33:57PM +0200, Wolfgang Denk wrote: > > > On the other hand, some of the issues we're trying to solve here > > for the kernel are also present in the boot loader, so this needs to > > do this anyway - whether by inserting new or modifying (enabling or > > disabling) existing properties in the DT is not really relevant here. > > FWIW if the bootloader can usefully handle this stuff I think that's a > good approach but there is substantial variation in quality of > implementation between bootloaders and even when the bootloader is a > good one it's not always practical to update it or the data it relies > on. I agree, the list of devices should be in the device-tree handed to whatever OS is being booted. It isn't a Linux specific problem that we're looking at here. Any operating system, pre-OS test suite, etc. is going going to need this information, and in my view the bootloader should be doing whatever is needed to create a device-tree to passed through to the next loaded system. Also, having the information available to $bootloader means the user can verify the presence of the peripherals before the OS is loaded. -- Ben Dooks, ben@fluff.org, http://www.fluff.org/ben/ Large Hadron Colada: A large Pina Colada that makes the universe disappear. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/