From mboxrd@z Thu Jan 1 00:00:00 1970 From: Mike Rapoport Subject: Re: Request review of device tree documentation Date: Wed, 16 Jun 2010 09:17:22 +0300 Message-ID: <4C186C72.2020506@compulab.co.il> 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> <4C186B7B.1060308@firmworks.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; Format="flowed" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <4C186B7B.1060308@firmworks.com> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: linuxppc-dev-bounces+glppe-linuxppc-embedded-2=m.gmane.org@lists.ozlabs.org Errors-To: linuxppc-dev-bounces+glppe-linuxppc-embedded-2=m.gmane.org@lists.ozlabs.org To: Mitch Bradley 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: devicetree@vger.kernel.org Mitch Bradley wrote: > 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? Currently it aims to abstract hardware from U-Boot and reuse the same HW access code across operating systems and bootloaders. If this code would have callbacks I afraid the things would became worse. > 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 >> >> -- Sincerely yours, Mike.