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
