[PATCH 04/11] of/flattree: eliminate cell_t typedef

Grant Likely grant.likely at secretlab.ca
Thu Nov 26 15:05:59 EST 2009


On Wed, Nov 25, 2009 at 8:59 PM, Benjamin Herrenschmidt
<benh at kernel.crashing.org> 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 at secretlab.ca>
>> ---
>
> 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.


More information about the Linuxppc-dev mailing list