Re: [PATCH -next v2 1/2] device property: Return -ENXIO if there is no suitable FW interface
From: Rafael J. Wysocki <hidden>
Date: 2015-08-27 00:48:20
Also in:
lkml
On Wednesday, August 26, 2015 04:25:59 PM Guenter Roeck wrote:
On 08/26/2015 04:37 PM, Rafael J. Wysocki wrote:quoted
On Wednesday, August 26, 2015 01:20:44 PM Guenter Roeck wrote:quoted
Return -ENXIO if device property array access functions don't find a suitable firmware interface. This lets drivers decide if they should use available platform data instead. Cc: Rafael J. Wysocki <redacted> Signed-off-by: Guenter Roeck <linux@roeck-us.net> --- v2: Added patch drivers/base/property.c | 7 +++++++ 1 file changed, 7 insertions(+)diff --git a/drivers/base/property.c b/drivers/base/property.c index 287704d680bf..9600b824d138 100644 --- a/drivers/base/property.c +++ b/drivers/base/property.c@@ -69,6 +69,9 @@ static int pset_prop_read_array(struct property_set *pset, const char *name, struct property_entry *prop; unsigned int item_size; + if (!pset) + return -ENXIO; +This isn't exactly straightforward, because it relies on the fact that pset_prop_read_array() is the last thing tried by FWNODE_PROP_READ_ARRAY() and fwnode_property_read_string_array(). A comment about that might be helpful.I see two options: Add a comment above, or change the calling code to ... else if (is_pset(fwnode)) return pset_prop_read_array(to_pset(fwnode), propname, DEV_PROP_STRING, val, nval); return -ENXIO; which would make it obvious and avoid side effects if the code is changed later on. Would you be ok with this ?
The second option is obviously cleaner to me and I prefer cleaner code. :-) Thanks, Rafael