On Wed, Nov 25, 2009 at 8:59 PM, Benjamin Herrenschmidt <benh@xxxxxxxxxxxxxxxxxxx> wrote: > On Tue, 2009-11-24 at 01:18 -0700, Grant Likely wrote: >> A cell is firmly established as a u32. No need to do an ugly typedef >> to redefine it to cell_t. Eliminate the unnecessary typedef so that >> it doesn't have to be added to the of_fdt header file >> >> Signed-off-by: Grant Likely <grant.likely@xxxxxxxxxxxx> >> --- > > 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. -- Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd. -- To unsubscribe from this list: send the line "unsubscribe sparclinux" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
