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

[David Gibson <david@gibson.dropbear.id.au>]

[-- Attachment #1: Type: text/plain, Size: 2611 bytes --]

On Wed, Jun 26, 2013 at 11:50:26AM +0100, Peter Maydell wrote:
> On 26 June 2013 11:31, Alexander Graf <agraf@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.

Heh.  Oops, didn't read this before I suggested the same thing.
Although a statement expression will let you actually get any fdt
error codes out.

> > 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.

So, I tend to think that "reg" and "ranges" specific helpers would be
nicer than having to add the size for every parameter.  But I was
thinking of passing in the address-cells and size-cells values rather
than having the function dig around in the tree to get them.

The other way to avoid varargs would be to have a helper that just
adds one entry at a time, using fdt_appendprop().

-- 
David Gibson			| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au	| minimalist, thank you.  NOT _the_ _other_
				| _way_ _around_!
http://www.ozlabs.org/~dgibson

[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]