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 11:50:26 +0100

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.

> 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



reply via email to

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