From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: MIME-Version: 1.0 Sender: glikely@secretlab.ca In-Reply-To: <1259207974.16367.226.camel@pasglop> References: <20091124081316.6216.66310.stgit@angua> <20091124081827.6216.1896.stgit@angua> <1259207974.16367.226.camel@pasglop> From: Grant Likely Date: Wed, 25 Nov 2009 21:05:59 -0700 Message-ID: Subject: Re: [PATCH 04/11] of/flattree: eliminate cell_t typedef To: Benjamin Herrenschmidt Content-Type: text/plain; charset=ISO-8859-1 Cc: sfr@canb.auug.org.au, monstr@monstr.eu, microblaze-uclinux@itee.uq.edu.au, devicetree-discuss@lists.ozlabs.org, sparclinux@vger.kernel.org, linuxppc-dev@lists.ozlabs.org, davem@davemloft.net List-Id: Linux on PowerPC Developers Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , On Wed, Nov 25, 2009 at 8:59 PM, Benjamin Herrenschmidt wrote: > On Tue, 2009-11-24 at 01:18 -0700, Grant Likely wrote: >> A cell is firmly established as a u32. =A0No need to do an ugly typedef >> to redefine it to cell_t. =A0Eliminate the unnecessary typedef so that >> it doesn't have to be added to the of_fdt header file >> >> Signed-off-by: Grant Likely >> --- > > I'm not sure about that one. Yes, we do use u32 a lot and cell_t rarely, > so it would seem logical to switch.... On the other hand, we have that > pesky endianness issue we have never fully solved. So we need accessors > to sort that out, which means directly tapping things as u32 * is not a > good idea if we're going to enforce the use of such accessors. > > I believe we should probably just enforce that properties are big endian > for flat device-trees. In which case we could just use __be32 or on of > thoes sparse-friendly types. I know x86 people won't like that much and > to be honest I don't know what 1295 specifies for real OFs but there > aren't enough real OFs around on LE machines for us to care much about > it, is there ? Word from Mitch is the device tree is network byte order. period. > The reason I prefer a fixed endianness is that allowing "LE" trees > becomes really nasty when a number is expressed using multiple cells. > That brings the question as to whether the two cells need to be flipped > as well or only the bytes within each cell. And that's the easy bit > (probably flip the whole thing). What about something like a PCI "reg" > property which is made of 3 cells, two of them forming a 64-bit address > and one containing additional data & attributes ? What is flipped and > where ? exactly. > So yes, cell_t might not be the right approach and by far to generic a > name, but u32 isn't the answer neither. You're right, it's not, but makes merging less complex, and then I can refactor properly. g. --=20 Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd.