allowing values to boolean flags lets us setup
defaults on DTSI which can get disabled later
at board DTS if, for whatever reason, board can't
use that default.
One such example is DM81xx EVM where we can't use
MUSB's multipoint feature even though SoC supports
it. Something at the board level prevents us from
using the feature.
Instead of removing "multipoint;" from DTSI and
adding it to all board DTS just so we can remove
it from our quirky board seems like overkill when
we could just add:
multipoint = <0>;
to that quirky board's DTS.
Note that the description here is but one example
and it's likely many others have faced something
similar.
Signed-off-by: Felipe Balbi <balbi@xxxxxx>
---
include/linux/of.h | 22 ++++++++++++++++++++--
1 file changed, 20 insertions(+), 2 deletions(-)
diff --git a/include/linux/of.h b/include/linux/of.h
index 76c055b20fef..c5ee9320f237 100644
--- a/include/linux/of.h
+++ b/include/linux/of.h
@@ -792,14 +792,32 @@ static inline int of_property_read_u32(const struct device_node *np,
* @propname: name of the property to be searched.
*
* Search for a property in a device node.
- * Returns true if the property exist false otherwise.
+ * Returns true if the property exist and has a value greater than zero,
+ * fals otherwise.
*/
static inline bool of_property_read_bool(const struct device_node *np,
const char *propname)
{
struct property *prop = of_find_property(np, propname, NULL);
+ int rc;
+ u32 val;
- return prop ? true : false;
+ if (!prop)
+ return false;
+
+ rc = of_property_read_u32(np, propname, &val);
+
+ /*
+ * if property doesn't have a value, or prop->length == 0 and
+ * we overflow, treat it as simple value-less flag.
+ */
+ if (rc == -ENODATA || rc == -EOVERFLOW)
+ return true;
+ if (WARN(rc < 0, "failed to read '%s' value -> %d\n",
+ propname, rc))
+ return false;
+
+ return !!val;
}
static inline int of_property_read_s32(const struct device_node *np,
--
2.3.0-rc1
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
