On Wed, Jun 06, 2018 at 11:59:20AM -0800, Simon Glass wrote: > Hi David, > > On 4 June 2018 at 17:59, David Gibson <david@xxxxxxxxxxxxxxxxxxxxx> wrote: > > On Thu, May 17, 2018 at 11:09:16PM -0600, Simon Glass wrote: > >> Extend the Properties class with some functions to read a single integer > >> property. Add a new getprop_obj() function to return a Property object > >> instead of the raw data. > >> > >> This suggested approach can be extended to handle other types, as well as > >> arrays. > >> > >> Signed-off-by: Simon Glass <sjg@xxxxxxxxxxxx> > >> --- > >> > >> Changes in v3: > >> - Rename the functions with an 'as_' prefix instead of 'to_' > >> > >> Changes in v2: None > >> > >> pylibfdt/libfdt.i | 35 +++++++++++++++++++++++++++++++++++ > >> tests/pylibfdt_tests.py | 12 ++++++++++++ > >> tests/run_tests.sh | 1 + > >> tests/test_props.dts | 11 +++++++++++ > >> 4 files changed, 59 insertions(+) > >> create mode 100644 tests/test_props.dts > >> > >> diff --git a/pylibfdt/libfdt.i b/pylibfdt/libfdt.i > >> index 7e915cf..328d440 100644 > >> --- a/pylibfdt/libfdt.i > >> +++ b/pylibfdt/libfdt.i > >> @@ -376,6 +376,26 @@ class Fdt: > >> return pdata > >> return str(pdata[0]) > >> > >> + def getprop_obj(self, nodeoffset, prop_name, quiet=()): > >> + """Get a property from a node as a Property object > > > > Now that you've made Property a subclass of bytearray elsewhere, can't > > you unify the getprop() and getprop_obj() interfaces? > > I can, but it does introduce a minor issue. As per other functions > named after libfdt getprop() is a stub for fdt_getprop() which > provides access to the error number in event of failure, whereas > getprop_obj() returns None on error. > > For now I'll try returning either: > > - a Property object (subclass of bytearray), on success > - an integer err number, on error I think that's reasonable. Returning different types for different situations is pretty common in Python - I mean we were already doing it elsewhere returning either the bytearray or an error code. > Of course the function will raise unless the errors are specifically > quietened, so this behaviour may not be common. That too. > But it is a bit weird so let me know if you have a better idea. > It does make the previous patch moot I think, but I'll send it anyway > since if this patch doesn't fit we still want the previous one. > > Regards, > Simon -- 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:
signature.asc
Description: PGP signature
