quoted

Why?  It should logically be an u8 * (and nothing
should ever cast it to anything else, accessor
functions should be used instead to get 32-bit ints
from it, etc.)

Ummm, no.

There are structures there, and other types of objects.

There are arrays of bytes there, with no guarantee of
any further alignment.

Look at how some of the sparc64 code does this, it's not a "u8 *" by
even the largest stretch of the imagination.

Maybe sparc64 does have some defined extra alignment;
on PowerPC, we get that alignment by making a copy of
the device tree.  That means no further interaction
with OF after very early boot (even before the kernel
proper starts); a less than desirable situation, and
certainly not something that a *generic* Linux OF
interface can require.  Also, in principle anyway,
you can have an integer follow a string in the same
property.

So just do an of_decode_int() and its cousins -- platforms
that are trying to guarantee alignment, or that can handle
unaligned memory accesses, can just define these as direct
accesses; everyone else should use the read-by-byte sequences.


Segher