On 26 June 2013 11:31, Alexander Graf <ag...@suse.de> wrote:
> I think it makes sense to make this API special-purpose for "reg".
> We currently have a generic "put any number of 32bit values into the
> property" function (qemu_devtree_setprop_cells).
Yes, but that doesn't work for things that aren't simple arrays
of 32 bit values, so I think that a generic way to deal
with those too would be useful. If you wanted to write a
"ranges" property you'd need this too, so it doesn't just
apply to "reg".
I think we could avoid the "varargs doesn't promote" problem
by using a varargs-macro wrapper:
#define qemu_devtree_setprop_sized_cells(fdt, node, prop, ...) \
do { \
uint64_t args[] = { __VA_ARGS__ }; \
do_qemu_devtree_setprop_sized_cells(fdt, node, prop, \
args, sizeof(args));
} while (0)
which will promote everything (including the size arguments,
harmlessly) to uint64_t, and avoids having a varargs function.
> Can't we also just add a qemu_devtree_setprop_reg() that walks
> the tree downwards in search for #address-cells and #size-cells
> and assembles the correct reg property from a list of 64bit
> arguments?
Do we have an actual use for this? It seems pretty complicated.
I would expect that in practice there are two major use cases:
(a) create your own fdt from scratch (in which case you can
just make everything 64 bits and in any case will know
when creating nodes what the #address-cells etc are)
(b) modify an existing fdt, in which case you definitely don't
want to go poking around too deeply in the tree; anything
more than just "put an extra node in the root" is starting
to get pretty chancy.
thanks
-- PMM
