From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from rs35.luxsci.com (rs35.luxsci.com [66.216.127.90]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by ozlabs.org (Postfix) with ESMTPS id A9934B7D83 for ; Wed, 16 Jun 2010 16:13:59 +1000 (EST) Message-ID: <4C186B7B.1060308@firmworks.com> Date: Tue, 15 Jun 2010 20:13:15 -1000 From: Mitch Bradley MIME-Version: 1.0 To: Mike Rapoport Subject: Re: Request review of device tree documentation References: <4C13430B.5000907@firmworks.com> <1276339529.1962.184.camel@pasglop> <1276339684.1962.186.camel@pasglop> <4C13B618.1030006@firmworks.com> <1276383132.1962.195.camel@pasglop> <4C146F18.9030008@firmworks.com> <20100614124438.GF9323@yookeroo> <20100614160201.GD9550@shareable.org> <4C165FD1.6080505@firmworks.com> <4C186AA8.4040709@compulab.co.il> In-Reply-To: <4C186AA8.4040709@compulab.co.il> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Cc: Nicolas Pitre , microblaze-uclinux@itee.uq.edu.au, devicetree-discuss , Jamie Lokier , linuxppc-dev , Dan Malek , Jeremy Kerr , linux-arm-kernel@lists.infradead.org, David Gibson List-Id: Linux on PowerPC Developers Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Mike Rapoport wrote: > Mitch Bradley wrote: > >> The second topic is the hypothetical use of OFW as a HAL. That will >> not happen for several reasons. The opposition to the idea is >> widespread and deeply held, and there are good arguments to support >> that opposition. Furthermore, the economic conditions necessary for >> the creation of such a HAL do not exist in the ARM world, nor indeed >> in the Linux world in general. (The necessary condition is the >> ability for one company to impose a substantial change by fiat - >> essentially a monopoly position.) >> >> Shall we agree, then, that any further discussion of the HAL issue is >> "just for fun", and that nobody needs to feel threatened that it >> would actually happen? > > I've recently worked with vendor versions of U-Boot for advanced ARM > SoCs. There is already *huge* chunk of HAL code in those versions. And > if there would be possibility to have callbacks into the firmware > these chunks would only grow, IMHO. How can there be HAL code in U-Boot unless there is already the possibility to have callbacks into the firmware? It is not HAL if it can't be called. > > >> The potential for "vendors breaking out of the debugging use case and >> turning it into a HAL" is miniscule, because >> >> a) The callback is disabled by default >> b) The technical challenges of the callback interface limit its >> applicability to specific "wizard user" scenarios >> c) OFW is unlikely to achieve sufficient market penetration for the >> HAL thing to be worth doing >> >> >> _______________________________________________ >> linux-arm-kernel mailing list >> linux-arm-kernel@lists.infradead.org >> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel > >