From: Andrew Morton <akpm@linux-foundation.org>
To: shuahkhan@gmail.com
Cc: neilb@suse.de, LKML <linux-kernel@vger.kernel.org>,
Jonas Bonn <jonas@southpole.se>,
Richard Purdie <richard.purdie@linuxfoundation.org>
Subject: Re: [PATCH ] leds: add new transient trigger for one shot timer support
Date: Fri, 20 Apr 2012 14:19:14 -0700 [thread overview]
Message-ID: <20120420141914.a3235c61.akpm@linux-foundation.org> (raw)
In-Reply-To: <1334894674.3051.18.camel@lorien2>
On Thu, 19 Apr 2012 22:04:34 -0600
Shuah Khan <shuahkhan@gmail.com> wrote:
> This patch adds a new transient trigger for one shot timer support and is
> to be used for the following example use cases:
>
> - Control of vibrate (phones, tablets etc.) hardware by userspace app.
> - Use of LED by userspace app as activity indicator.
> - Use of LED by userspace app as a kind of watchdog indicator -- as
> long as the app is alive, it can keep the LED illuminated, if it dies
> the LED will be extinguished automatically.
> - Use by any userspace app that needs a transient GPIO output
>
> Transient trigger exports two attributes:
> transient_enabled - one shot timer enable mechanism.
> 1 when enabled, 0 when disabled.
> enabled state indicates a timer
> with a value of transient_time running.
> disabled state indicates no active timer
> running.
> transient_time - one shot timer value. When transient_enabled
> is set, transient_time value is used to start
> a timer that runs once.
> When timer expires transient_enabled goes back to disabled state,
> transient_time is left at the set value to be used when transient
> is enabled at a future time. This will allow user app to set the
> time once and enable it to run it once for the specified value as
> needed.
Are there no comments from anyone on this?
>
> ...
>
> config LEDS_TRIGGER_TRANSIENT
> + tristate "LED Transient Trigger"
> + depends on LEDS_TRIGGERS
> + help
> + This allows one time enable of a transient state on GPIO/PWM based
> + hadrware.
Make it "This allows one time enabling of a transient state on GPIO/PWM
based hardware."
> + If unsure, say Y.
> +
>
> ...
>
> +static void transient_timer_function(unsigned long data)
> +{
> + struct led_classdev *led_cdev = (struct led_classdev *) data;
> + struct transient_trig_data *transient_data = led_cdev->trigger_data;
> +
> + if (transient_data->transient_enabled) {
> + transient_data->transient_enabled = 0;
> + led_cdev->brightness_set(led_cdev, LED_OFF);
> + del_timer(&transient_data->timer);
Deleting the timer from within its handler is ... odd. Also it is a
bit racy against a concurrent add_timer() on a different CPU.
> + }
> +}
> +
>
> ...
>
> +static ssize_t led_transient_enabled_store(struct device *dev,
> + struct device_attribute *attr, const char *buf, size_t size)
> +{
> + struct led_classdev *led_cdev = dev_get_drvdata(dev);
> + struct transient_trig_data *transient_data = led_cdev->trigger_data;
> + unsigned long state;
> + ssize_t ret = -EINVAL;
> +
> + ret = kstrtoul(buf, 10, &state);
> + if (ret)
> + return ret;
> +
> + if (state != 1 && state != 0)
> + return ret;
Bug - we'll return 0 here. Use "return -EINVAL" and remove the above
initialisation of `ret'.
> + /* cancel the running timer */
> + if (state == 0) {
> + transient_timer_function((unsigned long) led_cdev);
And this is perhaps why transient_timer_function() does del_timer().
I suggest it would be cleaner and simpler to do
transient_data->transient_enabled = 0;
del_timer(...);
right here.
This is all rather racy in its handling of ->transient_enabled (at
least), but afacit the races are harmless.
> + return size;
> + }
> +
> + transient_data->transient_enabled = (int) state;
The typecast is unneeded.
> + /* start timer with transient_time value */
> + if (state == 1 && transient_data->transient_time != 0) {
> + led_cdev->brightness_set(led_cdev, LED_FULL);
> + mod_timer(&transient_data->timer,
> + jiffies + transient_data->transient_time);
> + }
> +
> + return size;
> +}
> +
>
> ...
>
> +static ssize_t led_transient_time_store(struct device *dev,
> + struct device_attribute *attr, const char *buf, size_t size)
> +{
> + struct led_classdev *led_cdev = dev_get_drvdata(dev);
> + struct transient_trig_data *transient_data = led_cdev->trigger_data;
> + unsigned long state;
> + ssize_t ret = -EINVAL;
Unneeded initialisation.
> + ret = kstrtoul(buf, 10, &state);
> + if (ret)
> + return ret;
> +
> + transient_data->transient_time = state;
> +
> + return size;
> +}
> +
>
> ...
>
> +static void transient_trig_deactivate(struct led_classdev *led_cdev)
> +{
> + struct transient_trig_data *transient_data = led_cdev->trigger_data;
> +
> + if (led_cdev->activated) {
> + device_remove_file(led_cdev->dev, &dev_attr_transient_enabled);
> + device_remove_file(led_cdev->dev, &dev_attr_transient_time);
> + del_timer_sync(&transient_data->timer);
> + led_cdev->trigger_data = NULL;
> + led_cdev->activated = false;
> + kfree(transient_data);
OK. But it might be nicer to kill off the timer before doing anything else.
> + }
> + printk(KERN_DEBUG "Deativated led transient trigger %s\n",
> + led_cdev->name);
> +}
> +
>
> ...
>
next prev parent reply other threads:[~2012-04-20 21:19 UTC|newest]
Thread overview: 44+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-04-01 19:53 [PATCH RESEND] LEDS-One-Shot-Timer-Trigger-implementation Shuah Khan
2012-04-03 15:06 ` Shuah Khan
2012-04-06 23:53 ` Andrew Morton
2012-04-07 14:13 ` Shuah Khan
2012-04-07 21:56 ` Dmitry Torokhov
2012-04-08 23:42 ` NeilBrown
2012-04-09 0:06 ` Dmitry Torokhov
2012-04-09 22:25 ` NeilBrown
2012-04-10 8:21 ` Dmitry Torokhov
2012-04-09 16:55 ` Shuah Khan
2012-04-09 17:37 ` Dmitry Torokhov
2012-04-09 18:16 ` Shuah Khan
2012-04-09 18:45 ` Dmitry Torokhov
2012-04-09 20:20 ` Shuah Khan
2012-04-09 20:42 ` Dmitry Torokhov
2012-04-09 22:40 ` Shuah Khan
2012-04-10 7:17 ` Dmitry Torokhov
2012-04-10 18:34 ` Shuah Khan
2012-04-08 23:58 ` NeilBrown
2012-04-10 13:24 ` Richard Purdie
2012-04-10 15:31 ` Shuah Khan
2012-04-11 10:05 ` Richard Purdie
2012-04-11 15:33 ` Shuah Khan
2012-04-15 16:35 ` Shuah Khan
2012-04-15 22:34 ` [PATCH 1/1] leds: add "kickable" LED trigger Jonas Bonn
2012-04-15 22:37 ` Jonas Bonn
2012-04-16 15:28 ` Shuah Khan
2012-04-16 22:33 ` Jonas Bonn
2012-04-16 23:05 ` Shuah Khan
2012-04-20 4:04 ` [PATCH ] leds: add new transient trigger for one shot timer support Shuah Khan
2012-04-20 21:19 ` Andrew Morton [this message]
2012-04-20 22:48 ` Shuah Khan
2012-04-21 4:41 ` Jonas Bonn
2012-04-22 23:51 ` Shuah Khan
2012-04-23 1:56 ` NeilBrown
2012-04-23 5:29 ` Jonas Bonn
2012-04-23 5:45 ` NeilBrown
2012-04-23 22:22 ` Shuah Khan
2012-04-25 17:42 ` [PATCH v2] leds: add new transient trigger for one shot timer activation Shuah Khan
2012-04-26 6:02 ` NeilBrown
2012-04-26 14:48 ` Shuah Khan
2012-04-26 23:00 ` Andrew Morton
2012-04-30 20:33 ` [PATCH v3] " Shuah Khan
2012-04-23 5:07 ` [PATCH ] leds: add new transient trigger for one shot timer support Jonas Bonn
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20120420141914.a3235c61.akpm@linux-foundation.org \
--to=akpm@linux-foundation.org \
--cc=jonas@southpole.se \
--cc=linux-kernel@vger.kernel.org \
--cc=neilb@suse.de \
--cc=richard.purdie@linuxfoundation.org \
--cc=shuahkhan@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
Powered by JetHome