From: One Thousand Gnomes <gnomes@lxorguk.ukuu.org.uk>
To: Joe Xue <lgxue@hotmail.com>
Cc: cooloney@gmail.com, rpurdie@rpsys.net, rob@landley.net,
milo.kim@ti.com, pavel@ucw.cz, linux-leds@vger.kernel.org,
linux-kernel@vger.kernel.org, linux-doc@vger.kernel.org
Subject: Re: [PATCH] Add LED pattern trigger
Date: Mon, 30 Dec 2013 16:21:58 +0000 [thread overview]
Message-ID: <20131230162158.7420e811@alan.etchedpixels.co.uk> (raw)
In-Reply-To: <1388362275-1618-1-git-send-email-lgxue@hotmail.com>
> + * Based on Richard Purdie's ledtrig-timer.c and Atsushi Nemoto's
> + * ledtrig-heartbeat.c and Shuah Khan's ledtrig-transient.c
I stil think this belongs in user space except for platforms with hardware
acceleration for it.
> +#define MAX_PATTEN_LEN 255
Arbitary limits that are not needed if it was in userspace, and not it
seems a sensible one - why not use 256 ?
> +static ssize_t pattern_delay_unit_store(struct device *dev,
> + struct device_attribute *attr, const char *buf, size_t size)
> +{
> + struct led_classdev *led_cdev = dev_get_drvdata(dev);
> + struct pattern_trig_data *pattern_data = led_cdev->trigger_data;
> + unsigned long state;
> + ssize_t ret = -EINVAL;
> +
> + ret = kstrtoul(buf, 10, &state);
> + if (ret)
> + return ret;
> +
> + pattern_data->delay_unit = state;
What happens if this is zero ?
> +static ssize_t pattern_pattern_store(struct device *dev,
> + struct device_attribute *attr, const char *buf, size_t size)
> +{
> + struct led_classdev *led_cdev = dev_get_drvdata(dev);
> + struct pattern_trig_data *pattern_data = led_cdev->trigger_data;
> + int i;
> + ssize_t ret = -EINVAL;
> +
> + int len = (size > MAX_PATTEN_LEN) ? MAX_PATTEN_LEN : (size - 1);
> +
> + /* legality check */
> + for (i = 0; i < len; i++) {
> + if (buf[i] != ' ' && buf[i] != '#' && buf[i] != '/')
> + return ret;
> + }
> +
> + del_timer_sync(&pattern_data->timer);
> +
> + memcpy(pattern_data->pattern, buf, len);
> + pattern_data->pattern[len] = '\0';
> + pattern_data->pattern_len = len;
> + pattern_data->count = 0;
> +
> + mod_timer(&pattern_data->timer, jiffies + 1);
What if the pattern isn't currently active ?
> + return size;
You only consumed len bytes so you should return len here.
> +}
> +
> +static DEVICE_ATTR(pattern, 0644, pattern_pattern_show, pattern_pattern_store);
> +static DEVICE_ATTR(delay_unit, 0644,
> + pattern_delay_unit_show, pattern_delay_unit_store);
Why are these world readable. If patterns tell you an action is due they
provide information that other processes shouldn't have access to.
> + memset(tdata->pattern, 0, MAX_PATTEN_LEN + 1);
Why +1, you don't need a zero terminator you know the length
Why allocate a fixed 256 byte blob when you can make the data the end of
the struct (ie pattern[0] in the declaration) and not waste memory.
> +static void pattern_trig_deactivate(struct led_classdev *led_cdev)
> +{
> + struct pattern_trig_data *pattern_data = led_cdev->trigger_data;
> +
> + if (led_cdev->activated) {
> + del_timer_sync(&pattern_data->timer);
> + device_remove_file(led_cdev->dev, &dev_attr_pattern);
> + device_remove_file(led_cdev->dev, &dev_attr_delay_unit);
This doesn't as far as I can see do what you think. If I have the file
currently open then device_remove_file will not remove my existing access
to it, but you just released the pattern data so I now write to free
memory.
> + led_cdev->trigger_data = NULL;
> + led_cdev->activated = false;
> + kfree(pattern_data);
> + }
> + __led_set_brightness(led_cdev, LED_OFF);
> +}
> +
> +static struct led_trigger pattern_trigger = {
const ?
next prev parent reply other threads:[~2013-12-30 16:22 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-12-30 0:11 Joe Xue
2013-12-30 16:21 ` One Thousand Gnomes [this message]
2013-12-30 23:24 ` Joe Xue
2013-12-31 0:18 ` One Thousand Gnomes
2013-12-31 18:48 ` Joe Xue
2014-01-01 20:10 ` One Thousand Gnomes
2014-01-01 22:44 ` David Lang
2014-01-01 23:01 ` One Thousand Gnomes
2014-01-01 23:51 ` David Lang
2014-01-03 0:14 ` Bryan Wu
2014-01-03 9:33 ` Richard Weinberger
2014-01-03 15:23 ` One Thousand Gnomes
2014-01-05 22:23 ` n900 led compiler (was Re: [PATCH] Add LED pattern trigger) Pavel Machek
2014-01-07 15:40 ` Linus Walleij
2013-12-30 18:33 ` [PATCH] Add LED pattern trigger Pavel Machek
2013-12-31 5:00 ` Joe Xue
2013-12-31 11:33 ` Pavel Machek
2013-12-31 12:29 ` Richard Weinberger
2013-12-31 19:03 ` Pavel Machek
2014-01-01 20:11 ` One Thousand Gnomes
2014-01-01 2:57 ` [PATCH v2 1/1] leds: " Joe Xue
2014-01-01 3:03 ` [PATCH v2 1/1] " Joe Xue
2014-01-06 21:47 ` [PATCH v3 1/1] leds: " lgxue
2014-01-06 22:10 ` Joe Xue
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=20131230162158.7420e811@alan.etchedpixels.co.uk \
--to=gnomes@lxorguk.ukuu.org.uk \
--cc=cooloney@gmail.com \
--cc=lgxue@hotmail.com \
--cc=linux-doc@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-leds@vger.kernel.org \
--cc=milo.kim@ti.com \
--cc=pavel@ucw.cz \
--cc=rob@landley.net \
--cc=rpurdie@rpsys.net \
/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
all inboxes | Powered by JetHome®