Hi David, On 11 June 2018 at 23:19, David Gibson <david@xxxxxxxxxxxxxxxxxxxxx> wrote: > On Wed, Jun 06, 2018 at 03:37:09PM -0600, Simon Glass wrote: >> It is useful to be able to create a device tree from scratch using >> software. This is supported in libfdt but not currently available in the >> Python bindings. >> >> Add a new FdtSw class to handle this, with various methods corresponding >> to the libfdt functions. When the tree is complete, calling AsFdt() will >> return the completed device-tree object. >> >> Signed-off-by: Simon Glass <sjg@xxxxxxxxxxxx> >> --- >> >> Changes in v2: None >> >> pylibfdt/libfdt.i | 269 ++++++++++++++++++++++++++++++++++++++++ >> tests/pylibfdt_tests.py | 91 +++++++++++++- >> 2 files changed, 357 insertions(+), 3 deletions(-) >> >> diff --git a/pylibfdt/libfdt.i b/pylibfdt/libfdt.i >> index 566a401..6f9593d 100644 >> --- a/pylibfdt/libfdt.i >> +++ b/pylibfdt/libfdt.i [..] >> %rename(fdt_property) fdt_property_func; >> @@ -750,6 +1006,11 @@ typedef int fdt32_t; >> $1 = PyString_AsString($input); /* char *str */ >> } >> >> +/* typemap used for fdt_add_reservemap_entry() */ >> +%typemap(in) uint64_t { >> + $1 = PyLong_AsUnsignedLong($input); > > Will swig do the right thing here if you pass in a Python int rather > than a Python long? Yes the test does pass in a normal int (e.g. 0) so it seems OK. I believe this function is intended to convert something (anything) to a long. I've respun the series along the lines that you suggested. I suspect it will need a few more revisions though as we refine the ideas. The main question is anticipating being out of space, or retrying operations afterwards. I went for the former since in the case where you are adding a large property it is more efficient. Regards, Simon -- To unsubscribe from this list: send the line "unsubscribe devicetree-compiler" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html