On 26.06.2013, at 12:50, Peter Maydell wrote:
> 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.
That would work, yes :).
>
>> 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.
Well, though I do agree it would mimic exactly what the interpreter will do
when reading those values, ensuring consistency, no?
Alex
