Re: [PATCH v4 3/3] leds: Add ktd2692 flash LED driver

[Ingi Kim]

Hi Varka,

On 2015ë 03ì 25ì 12:28, Varka Bhadram wrote:
> On 03/25/2015 07:00 AM, Ingi Kim wrote:
> 
>> This patch adds a driver to support the ktd2692 flash LEDs.
>> ktd2692 can control flash current by ExpressWire interface.
>>
>> Signed-off-by: Ingi Kim <ingi2.kim@xxxxxxxxxxx>
>> ---
>>   drivers/leds/Kconfig        |   9 +
>>   drivers/leds/Makefile       |   1 +
>>   drivers/leds/leds-ktd2692.c | 412 ++++++++++++++++++++++++++++++++++++++++++++
>>   3 files changed, 422 insertions(+)
>>   create mode 100644 drivers/leds/leds-ktd2692.c
>>
> (...)
> 
>> +static int ktd2692_parse_dt(struct ktd2692_context *led, struct device *dev,
>> +                u32 *flash_timeout_us)
>> +{
>> +    struct device_node *np = dev->of_node;
>> +
> 
> Unnecessary one line space..
> 

Oh, I missed it! Thanks

>> +    int ret;
>> +
>> +    led->ctrl_gpio = of_get_named_gpio(np, "ctrl-gpio", 0);
>> +    if (!gpio_is_valid(led->ctrl_gpio)) {
>> +        dev_err(dev, "no ctrl-gpio property found\n");
>> +        return -EINVAL;
>> +    }
>> +
>> +    led->aux_gpio = of_get_named_gpio(np, "aux-gpio", 0);
>> +    if (!gpio_is_valid(led->aux_gpio)) {
>> +        dev_err(dev, "no aux-gpio property found\n");
>> +        return -EINVAL;
>> +    }
>> +
>> +    ret = devm_gpio_request_one(dev, led->ctrl_gpio,
>> +                    GPIOF_OPEN_SOURCE, "ctrl-gpio");
>> +    if (ret) {
>> +        dev_err(dev, "failed to request ctrl-gpio %d error %d\n",
>> +                led->ctrl_gpio, ret);
>> +        return ret;
>> +    }
>> +
>> +    ret = devm_gpio_request_one(dev, led->aux_gpio,
>> +                    GPIOF_OPEN_SOURCE, "aux-gpio");
>> +    if (ret) {
>> +        dev_err(dev, "failed to request aux-gpio %d error %d\n",
>> +                led->aux_gpio, ret);
>> +        return ret;
>> +    }
>> +
>> +    ret = of_property_read_u32(np, "flash-timeout-us", flash_timeout_us);
>> +    /* default setting */
>> +    if (ret)
>> +        *flash_timeout_us = KTD2692_FLASH_MODE_TIMEOUT_DEFAULT_US;
>> +
>> +    return 0;
>> +}
>> +
>> +static const struct led_flash_ops flash_ops = {
>> +    .strobe_set = ktd2692_led_flash_strobe_set,
>> +    .timeout_set = ktd2692_led_flash_timeout_set,
>> +};
>> +
>> +static int ktd2692_probe(struct platform_device *pdev)
>> +{
>> +    struct ktd2692_context *led;
>> +    struct led_classdev *led_cdev;
>> +    struct led_classdev_flash *fled_cdev;
>> +    struct led_flash_setting flash_timeout;
>> +    u32 flash_timeout_us;
>> +    int ret;
>> +
>> +    led = devm_kzalloc(&pdev->dev, sizeof(*led), GFP_KERNEL);
>> +    if (!led)
>> +        return -ENOMEM;
>> +
>> +    if (!pdev->dev.of_node)
>> +        return -ENXIO;
>> +
> 
> Above operation dt related. So if you do that in ktd2692_parse_dt(), it will be good
> 

Good point!
I'll do that

>> +    fled_cdev = &led->fled_cdev;
>> +    led_cdev = &fled_cdev->led_cdev;
>> +
>> +    ret = ktd2692_parse_dt(led, &pdev->dev, &flash_timeout_us);
>> +    if (ret)
>> +        return ret;
>> +
>> +    led->regulator = devm_regulator_get(&pdev->dev, "vin");
>> +    if (IS_ERR(led->regulator)) {
>> +        dev_err(&pdev->dev, "regulator get failed\n");
>> +        return PTR_ERR(led->regulator);
>> +    }
>> +
>> +    ktd2692_init_flash_timeout(flash_timeout_us, &flash_timeout);
>> +
>> +    fled_cdev->timeout = flash_timeout;
>> +    fled_cdev->ops = &flash_ops;
>> +
>> +    led_cdev->name = KTD2692_DEFAULT_NAME;
>> +    led_cdev->brightness_set = ktd2692_led_brightness_set;
>> +    led_cdev->brightness_set_sync = ktd2692_led_brightness_set_sync;
>> +    led_cdev->flags |= LED_CORE_SUSPENDRESUME;
>> +    led_cdev->flags |= LED_DEV_CAP_FLASH;
>> +
>> +    mutex_init(&led->lock);
>> +    INIT_WORK(&led->work_brightness_set, ktd2692_brightness_set_work);
>> +
>> +    platform_set_drvdata(pdev, led);
>> +
>> +    ret = led_classdev_flash_register(&pdev->dev, fled_cdev);
>> +    if (ret) {
>> +        dev_err(&pdev->dev, "can't register LED %s\n", led_cdev->name);
>> +        cancel_work_sync(&led->work_brightness_set);
> 
> Is the above API is correct to use in this place.?
> 
> cancel_work_sync â cancel a work and wait for it to finish...
> 
> Work is not yet scheduled..?
> 
> What about mutex destroy..?
> 

Right, I should remove this API.
It seems to be useless in this place

And mutex_destroy() will be added, Thank you!

>> +        return ret;
>> +    }
>> +
>> +    ktd2692_setup(led);
>> +    ktd2692_led_regulator_enable(led);
>> +
>> +    return 0;
>> +}
>> +
>> +static int ktd2692_remove(struct platform_device *pdev)
>> +{
>> +    struct ktd2692_context *led = platform_get_drvdata(pdev);
>> +
>> +    ktd2692_led_regulator_disable(led);
>> +    led_classdev_flash_unregister(&led->fled_cdev);
>> +    cancel_work_sync(&led->work_brightness_set);
>> +
>> +    mutex_destroy(&led->lock);
>> +
>> +    return 0;
>> +}
>> +
>> +static const struct of_device_id ktd2692_match[] = {
>> +    { .compatible = "kinetic,ktd2692", },
>> +    { /* sentinel */ },
>> +};
>> +
>> +static struct platform_driver ktd2692_driver = {
>> +    .driver = {
>> +        .name  = "leds-ktd2692",
>> +        .of_match_table = ktd2692_match,
>> +    },
>> +    .probe  = ktd2692_probe,
>> +    .remove = ktd2692_remove,
>> +};
>> +
>> +module_platform_driver(ktd2692_driver);
>> +
>> +MODULE_AUTHOR("Ingi Kim <ingi2.kim@xxxxxxxxxxx>");
>> +MODULE_DESCRIPTION("Kinetic KTD2692 LED driver");
>> +MODULE_LICENSE("GPL v2");
> 
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/