From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Date: Sat, 28 Jun 2008 10:15:48 +1000 From: David Gibson To: Scott Wood Subject: Re: dtc: Address an assortment of portability problems Message-ID: <20080628001548.GB4283@yookeroo.seuss> References: <20080626010349.GH308@yookeroo.seuss> <20080626152528.GA12256@loki.buserror.net> <20080626234743.GA16169@yookeroo.seuss> <4864FECF.3010304@freescale.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii In-Reply-To: <4864FECF.3010304@freescale.com> Cc: linuxppc-dev@ozlabs.org, Benno Rice List-Id: Linux on PowerPC Developers Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , On Fri, Jun 27, 2008 at 09:53:03AM -0500, Scott Wood wrote: > David Gibson wrote: >> On Thu, Jun 26, 2008 at 10:25:28AM -0500, Scott Wood wrote: >>> On Thu, Jun 26, 2008 at 11:03:49AM +1000, David Gibson wrote: >>>> - the endian handling functions in libfdt_env.h, based on >>>> endian.h and byteswap.h are replaced with some portable open-coded >>>> versions. Unfortunately, these result in fairly crappy code when >>>> compiled, but as far as I can determine there doesn't seem to be any >>>> POSIX, SUS or de facto standard way of determining endianness at >>>> compile time, nor standard names for byteswapping functions. >>> Since device-tree and network byte order happen to be the same, we could use >>> ntohl/htonl. >> >> Not for the 64-bit version. > > Why? They operate on uint32_t despite the "l" in the name, and there > are no 64-bit fields in the device tree... Yes there are. The memory reservations. We have and need fdt64_to_cpu(). -- David Gibson | I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_ | _way_ _around_! http://www.ozlabs.org/~dgibson