On Fri, Mar 11, 2016 at 2:43 PM, Laxman Dewangan <ldewangan@xxxxxxxxxx> wrote:
The child node for gpio hogs under gpio controller's nodeActually it's just "label" as seen from the code and the binding.
provide the mechanism to automatic GPIO request and
configuration as part of the gpio-controller's driver
probe function.
Currently, property "gpio" takes one gpios for such
configuration. Add support to have multiple GPIOs in
this property so that multiple GPIOs of gpio-controller
can be configured by this mechanism with one child node.
Signed-off-by: Laxman Dewangan <ldewangan@xxxxxxxxxx>
Cc: Benoit Parrot <bparrot@xxxxxx>
Cc: Alexandre Courbot <acourbot@xxxxxxxxxx>
---
Changes from V1:
- Add "labels" property for GPIO label names.
Though it would make sense to have labels (pluralis) as it can be more
than one and accompanies "gpios" which is plural.
Rob: what is the pattern here?
(Grep the existing bindings to check how multiple labels are handled
in other subsystems...)
(...)yaah, line-name is deprecated property and so not adding array string here. Array string will be supported with label only. I did not add print as deprecated property to avoid noise in log.
- if (name && of_property_read_string(np, "line-name", name))This looks to me like if "line-name" is specified, all lines will get the
- *name = np->name;
+ if (!name)
+ goto out;
+ ret = of_property_read_string(np, "line-name", name);
+ if (ret)
+ ret = of_property_read_string_index(np, "label", gpio_index,
+ name);
+ if (ret)
+ *name = np->name;
same name if gpios contain more than one item. Is this what we want?