On Tue, Jun 16, 2015 at 2:26 PM, Daniel Mack <daniel@xxxxxxxxxx> wrote: > On 06/16/2015 04:39 PM, Matt Ranostay wrote: >> On Tue, Jun 16, 2015 at 12:54 AM, Jacek Anaszewski >> <j.anaszewski@xxxxxxxxxxx> wrote: >>> On 06/16/2015 04:46 AM, Matt Ranostay wrote: > >>>> + for_each_child_of_node(node, child) { >>>> + led->cdev.name = >>>> + of_get_property(child, "label", NULL) ? : >>>> child->name; >>>> + led->cdev.default_trigger = >>>> + of_get_property(child, "linux,default-trigger", >>>> NULL); >>>> + led->cdev.flags = 0; >>>> + led->cdev.brightness_set = cap11xx_led_set; >>>> + led->cdev.max_brightness = 1; >>>> + led->cdev.brightness = LED_OFF; >>>> + >>>> + error = of_property_read_u32(child, "reg", ®); >>>> + if (error != 0 || reg >= priv->num_leds) >>>> + continue; >>>> + led->reg = reg; >>>> + led->priv = priv; >>>> + >>>> + INIT_WORK(&led->work, cap11xx_led_work); >>>> + error = devm_led_classdev_register(dev, &led->cdev); >>>> + if (error < 0) >>>> + return -EINVAL; >>>> + >>>> + schedule_work(&led->work); >>> >>> >>> Why do you schedule work here? It should be done only in brightness_set op. >>> >> The LED needs to be set to initial turned off state, since there is no >> Power ON/OFF register for the cap11xx devices.. So LEDs state would be >> persistent across warm reboots. >> Thoughts on how to do this better? > > What's wrong with this? > > regmap_write(priv->regmap, CAP11XX_REG_LED_OUTPUT_CONTROL, 0); > > Outside the loop, of course ... > Works for me, and prevents the workqueues tasks for blocking each other in regmap_update_bits. However I just noticed the DLSLEEP state that cap11xx_input_close() requests via cap11xx_set_sleep(true) could disable the LEDs. Need to double check this later tonight... > > Daniel > -- 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