| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Message-id: <55136438.9060303@samsung.com>
Date: Thu, 26 Mar 2015 10:43:20 +0900
From: Ingi Kim <ingi2.kim@...sung.com>
To: Varka Bhadram <varkabhadram@...il.com>
Cc: cooloney@...il.com, rpurdie@...ys.net, robh+dt@...nel.org,
pawel.moll@....com, mark.rutland@....com,
ijc+devicetree@...lion.org.uk, galak@...eaurora.org,
sakari.ailus@....fi, j.anaszewski@...sung.com,
sw0312.kim@...sung.com, cw00.choi@...sung.com,
jh80.chung@...sung.com, ideal.song@...sung.com,
devicetree@...r.kernel.org, linux-kernel@...r.kernel.org,
linux-leds@...r.kernel.org
Subject: Re: [PATCH v4 3/3] leds: Add ktd2692 flash LED driver
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@...sung.com>
>> ---
>> 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@...sung.com>");
>> +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@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists