From mboxrd@z Thu Jan  1 00:00:00 1970
From: Wolfgang Denk <wd@denx.de>
Date: Thu, 20 May 2010 10:28:12 +0200
Subject: [U-Boot] libfdt: make fdt_increase_size() available to everyone
In-Reply-To: <4BF4623B.1080109@freescale.com>
References: <1273526815-1091-1-git-send-email-timur@freescale.com>
	<1273975868.3244.9.camel@xps>
	<AANLkTilPrgpUwL630lzSmzKt5bBXFiq6zDPIiR3pQcwa@mail.gmail.com>
	<20100517131650.1060EE6D663@gemini.denx.de>
	<4BF14FBF.3040900@freescale.com>
	<20100517203355.2B215E6D663@gemini.denx.de>
	<4BF29FE9.1070305@freescale.com>
	<20100518151841.B6F18E6D663@gemini.denx.de>
	<4BF2B302.2030909@freescale.com>
	<20100518222042.2C2C2E6D663@gemini.denx.de>
	<AANLkTimFF-MM8jLicndervkWwRVpMQEeEuVd_RNTMxrY@mail.gmail.com>
	<20100519065420.BC269E6D663@gemini.denx.de>
	<4BF3FC6D.4000605@freescale.com>
	<20100519151402.9066DE6D663@gemini.denx.de>
	<4BF4051A.1090202@freescale.com>
	<20100519154417.61E04E6D663@gemini.denx.de>
	<52E9D06A-E721-4907-9024-11BDC8D006E0@kernel.crashing.org>
	<20100519220628.6CBC2E5C89E@gemini.denx.de>
	<4BF4623B.1080109@freescale.com>
Message-ID: <20100520082812.57AEBCCF026@gemini.denx.de>
List-Id: <u-boot.lists.denx.de>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
To: u-boot@lists.denx.de

Dear Timur Tabi,

In message <4BF4623B.1080109@freescale.com> you wrote:
>
> > Why would this in any way be a board specific implementation? This
> > makes no sense to me. The feature to include some binary data into the
> > DTB is IMO in no way dependent on or specific to a certain board.
> 
> The data I'm trying to embed is firmware for various devices on some of our
> SOCs, such as the QE on the MPC8360.  Only boards with SOCs that have these
> devices come with firmware, and not all of them require the firmware to be
> passed to Linux.

Yes, I know all of this. This is your specific use case. But maybe you
can take the blinkers off for a moment, and face up to other potential
use cases as well?

User A might want to ambed a FPGA bit stream, user B something we
don't even dream of yet.

Instead of implementing this feature in a way that makes it restricted
to your current use case only we can as well make it generic enough so
others can use it as well.

> Please note that fdt_increase_size() is just a front-end to fdt_open_into(),
> so technically I don't need to fdt_increase_size().  However, you said you
> would reject any patch that uses fdt_open_into() in this manner, so we're
> back to square one.

Back to square one? I did not realize you ever left that position ;-)

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Do not simplify the design of a program if a way can be found to make
it complex and wonderful.