From: Onkalo Samu <samu.p.onkalo@nokia.com>
To: ext Dmitry Torokhov <dmitry.torokhov@gmail.com>
Cc: "linux-input@vger.kernel.org" <linux-input@vger.kernel.org>
Subject: Re: [PATCH 1/1] Input polldev: Sysfs interface for setting of polling interval
Date: Tue, 10 Nov 2009 09:02:18 +0200 [thread overview]
Message-ID: <1257836538.22403.3.camel@4fid08082> (raw)
In-Reply-To: <20091109172850.GB30386@core.coreip.homeip.net>
Hi Dmitry,
Thank you for the comments.
On Mon, 2009-11-09 at 18:28 +0100, ext Dmitry Torokhov wrote:
>> -static void input_polldev_stop_workqueue(void)
>> +static void input_polldev_stop_workqueue(struct input_polled_dev
>> +*dev)
>> {
>> mutex_lock(&polldev_mutex);
>>
>> + cancel_delayed_work_sync(&dev->work);
>> +
>
>Why is this needed? We cancel the work when we close the device.
>
Actually not needed. I'll remove that.
>> +static ssize_t input_polldev_set_interval(struct device *dev,
>> + struct device_attribute *attr,
>const char *buf,
>> + size_t count)
>> +{
>> + struct input_polled_dev *polldev = dev_get_drvdata(dev);
>> + unsigned long delay;
>> + unsigned long interval;
>> +
>> + if (strict_strtoul(buf, 0, &interval))
>> + return -EINVAL;
>> +
>> + if (interval < polldev->poll_interval_min)
>> + return -EINVAL;
>> +
>> + if (interval > polldev->poll_interval_max)
>> + return -EINVAL;
>> +
>> + mutex_lock(&polldev_mutex);
>
>I think you want to use polldev->dev->mutex here instead.
Yes, there is not need to lock all polled devices. And using
that mutex we also avoid possible race conditions between close / open
operations.
>
>> +
>> + polldev->poll_interval = interval;
>> +
>> + if (polldev->is_opened) {
>
>polldev->dev->users.
Sure.
>
>> + if (polldev->poll_interval > 0) {
>> + delay =
>msecs_to_jiffies(polldev->poll_interval);
>> + if (delay >= HZ)
>> + delay = round_jiffies_relative(delay);
>> +
>> + queue_delayed_work(polldev_wq,
>&polldev->work, delay);
>
>This will not treschedule the work with the new interval if
>the old one is already scheduled.
True. I'll cancel work before scheduling new one.
>
>> + } else {
>> + cancel_delayed_work_sync(&polldev->work);
>
>Do we need to support stopping the polling ocmpletely?
If the polled device is used for cases where there are parallel
need for polled and interrupt based events, users may want to disable
polling. Some small sensors can utilize this combination. Especially in
battery operated devices this makes sense. Userspace can stop regular
polling, but still get part of the events from the device.
>> +
>> +static DEVICE_ATTR(interval, S_IRUGO | S_IWUSR,
>input_polldev_get_interval,
>> +
>input_polldev_set_interval);
>> +
>> +static struct attribute *sysfs_attrs[] = {
>> + &dev_attr_interval.attr,
>> + NULL
>> +};
>> +
>> +static struct attribute_group input_polldev_attribute_group = {
>> + .attrs = sysfs_attrs
>> +};
>
>Do you need attribute group? It is unnamed and we have just
>one attribute... But maybe we should make it named, like
>"poll" and add upper and lower limits (read-only).
I'll change interface to "poll", "min" and "max"
-Samu
prev parent reply other threads:[~2009-11-10 7:02 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-11-09 13:03 [PATCH 0/1] Polled input device: sysfs control for polling rate Samu Onkalo
2009-11-09 13:03 ` [PATCH 1/1] Input polldev: Sysfs interface for setting of polling interval Samu Onkalo
2009-11-09 17:28 ` Dmitry Torokhov
2009-11-10 7:02 ` Onkalo Samu [this message]
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=1257836538.22403.3.camel@4fid08082 \
--to=samu.p.onkalo@nokia.com \
--cc=dmitry.torokhov@gmail.com \
--cc=linux-input@vger.kernel.org \
/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;
as well as URLs for NNTP newsgroup(s).