On 26 June 2013 13:38, Peter Crosthwaite <peter.crosthwa...@xilinx.com> wrote:
> On Wed, Jun 26, 2013 at 8:50 PM, Peter Maydell <peter.mayd...@linaro.org>
> wrote:
>> 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)
>>
>
> Are statement expressions sanctioned? Or do we need to give up the
> nice caller accessible return codes?
I just borrowed the syntax from the existing qemu_devtree_setprop_cells
macro to illustrate how the varargs bit would work; I'll tweak it to
actually get the return code right for the patch proper.
> And can we factor out common functionality (mainly the error checking)
> with existing set_prop_cells to make the interfaces consistent? (we
> need to get rid of those aborts sooner or later)
Maybe we should at some point switch to using Error** for error
reporting in our wrapper APIs here? It is a bit odd that half
our device tree functions die on error and the other half
report a failure code.
>> 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?
>>
>
> I have a patch in my tree that generalises qemu_devtree_getprop* to
> allow you walk parents for properties (as per the #foo-cells
> semantic). I use it for interrupt cells however, which kinda suggests
> that this wish for parent traversal is more generic than just
> populating reg. I think that Peters patch, along with a parent search
> friendly property search will be enough to be able to do whatever you
> want in only a handful of lines.
Sounds good to me.
-- PMM
