Hi Pavel, On 04/06/2017 05:50 PM, Pavel Machek wrote: > Hi! > >>> diff --git a/Documentation/devicetree/bindings/leds/leds-pca9532.txt b/Documentation/devicetree/bindings/leds/leds-pca9532.txt >>> index 198f3ba..8374075 100644 >>> --- a/Documentation/devicetree/bindings/leds/leds-pca9532.txt >>> +++ b/Documentation/devicetree/bindings/leds/leds-pca9532.txt >>> @@ -17,6 +17,8 @@ Optional sub-node properties: >>> - label: see Documentation/devicetree/bindings/leds/common.txt >>> - type: Output configuration, see dt-bindings/leds/leds-pca9532.h (default NONE) >>> - linux,default-trigger: see Documentation/devicetree/bindings/leds/common.txt >>> + - default-state: see Documentation/devicetree/bindings/leds/common.txt >>> + This property is only valid for sub-nodes of type <PCA9532_TYPE_LED>. >>> >>> Example: >>> #include <dt-bindings/leds/leds-pca9532.h> >>> @@ -33,6 +35,14 @@ Example: >>> label = "pca:green:power"; >>> type = <PCA9532_TYPE_LED>; >>> }; >>> + kernel-booting { >>> + type = <PCA9532_TYPE_LED>; >>> + default-state = "on"; >>> + }; >>> + sys-stat { >>> + type = <PCA9532_TYPE_LED>; >>> + default-state = "keep"; // don't touch, was set by U-Boot >>> + }; >> >> Adjusted above indentation to match the preceding lines. > >>> @@ -475,6 +494,16 @@ pca9532_of_populate_pdata(struct device *dev, struct device_node *np) >>> of_property_read_u32(child, "type", &pdata->leds[i].type); >>> of_property_read_string(child, "linux,default-trigger", >>> &pdata->leds[i].default_trigger); >>> + if (!of_property_read_string(child, "default-state", &state)) { >>> + if (!strcmp(state, "on")) >>> + pdata->leds[i].state = PCA9532_ON; >>> + else if (!strcmp(state, "keep")) >>> + pdata->leds[i].state = PCA9532_KEEP; >>> + else if (!strcmp(state, "pwm0")) >>> + pdata->leds[i].state = PCA9532_PWM0; >>> + else if (!strcmp(state, "pwm1")) >>> + pdata->leds[i].state = PCA9532_PWM1; >>> + } >>> if (++i >= maxleds) { >>> of_node_put(child); >>> break; > > This seems to look for "pwm0" and "pwm1" strings, which do not seem to > be documented. > > Plus... is it useful to have default-state? We already have default > trigger. If we keep the value by default (on PC, we do something like > that) this patch should not be neccessary? Thanks for the heads-up. Dropping the patch for now. I guess that pwm0/1 got propagated to v2 by an omission. Regarding default-on: Felix, do you have any use case that require default-on set to "keep"? -- Best regards, Jacek Anaszewski -- 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