Re: [Qemu-devel] [PATCH 1/2] device_tree: Add qemu_devtree_setprop_sized_cells() utility function

[Alexander Graf]

On 26.06.2013, at 12:50, Peter Maydell wrote:

> On 26 June 2013 11:31, Alexander Graf <address@hidden> 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