qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH 1/2] device_tree: Add qemu_devtree_setprop_sized


From: Peter Maydell
Subject: Re: [Qemu-devel] [PATCH 1/2] device_tree: Add qemu_devtree_setprop_sized_cells() utility function
Date: Wed, 26 Jun 2013 14:13:28 +0100

On 26 June 2013 13:38, Peter Crosthwaite <address@hidden> wrote:
> On Wed, Jun 26, 2013 at 8:50 PM, Peter Maydell <address@hidden> 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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]