From: Daniel Baluta <daniel.baluta@intel.com>
To: Jonathan Cameron <jic23@kernel.org>,
Lars-Peter Clausen <lars@metafoo.de>
Cc: jlbec@evilplan.org, knaack.h@gmx.de,
linux-kernel@vger.kernel.org, linux-iio@vger.kernel.org,
octavian.purdila@intel.com, pebolle@tiscali.nl,
patrick.porlan@intel.com, adriana.reus@intel.com,
constantin.musca@intel.com, marten@intuitiveaerial.com
Subject: Re: [PATCH v5 3/4] iio: trigger: Introduce IIO hrtimer based trigger
Date: Wed, 06 May 2015 19:25:09 +0300 [thread overview]
Message-ID: <554A4065.8050101@intel.com> (raw)
In-Reply-To: <0944C1CC-6F9C-49C5-8195-994413B68680@kernel.org>
On 05/05/2015 04:51 PM, Jonathan Cameron wrote:
>
>
> On 4 May 2015 20:54:08 GMT+01:00, Lars-Peter Clausen <lars@metafoo.de> wrote:
>> On 05/04/2015 12:50 PM, Daniel Baluta wrote:
>> [...]
>>> +IIO_HRTIMER_INFO_ATTR(sampling_frequency, S_IRUGO | S_IWUSR,
>>> + iio_hrtimer_info_show_sampling_frequency,
>>> + iio_hrtimer_info_store_sampling_frequency);
>>
>> I wonder if the sampling frequency should be configurable the regular
>> IIO
>> API, just like any other IIO device. But things like min/max sampling
>> frequency should be configured in configfs.
> Would have to be in the trigger dir rather than device... Makes sense to put it there.
> Limits on it here seem like a sensible idea.
But then each trigger will have sampling_frequency right? This is not
what we want.
>>
>> [...]
>>> +#endif /* CONFIGFS_FS */
>>> +
>> [...]
>>> +static struct iio_sw_trigger *iio_trig_hrtimer_probe(const char
>> *name)
>>> +{
>> [...]
>>> +#ifdef CONFIG_CONFIGFS_FS
>>> + config_group_init_type_name(&trig_info->swt.group, name,
>>> + &iio_hrtimer_type);
>>> +#endif
>>
>> This should probably have a helper function in the sw trigger core,
>> that
>> gets stubbed out when CONFIG_FS is disabled. Otherwise we'll see the
>> same
>> #ifdef in every software trigger driver.
>> [...]
Agree with this. Will fix.
>>> +}
>>> +
>>> +static int iio_trig_hrtimer_remove(struct iio_sw_trigger *swt)
>>> +{
>>> + struct iio_hrtimer_info *trig_info;
>>> +
>>> + trig_info = iio_trigger_get_drvdata(swt->trigger);
>>> +
>>> + hrtimer_cancel(&trig_info->timer);
>>> +
>>> + iio_trigger_unregister(swt->trigger);
>>> + iio_trigger_free(swt->trigger);
>>
>> There is a bit of a race condition here. hrtimer_cancel() should be
>> called
>> between unregister and free, otherwise it might be re-armed before it
>> is
>> unregistered.
So this can be re-armed only if the buffer is re-enabled between
hrtimer_cancel and iio_trigger_unregister :). I'm trying to understand
how the race can happen.
>>
>>> + kfree(trig_info);
>>> +
>>> + return 0;
>>> +}
>>> +
>>> +struct iio_sw_trigger_ops iio_trig_hrtimer_ops = {
>>
>> const
Agree.
>>
>>> + .probe = iio_trig_hrtimer_probe,
>>> + .remove = iio_trig_hrtimer_remove,
>>> +};
>> [...]
next prev parent reply other threads:[~2015-05-06 16:25 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-05-04 10:50 [PATCH v5 0/4] Add initial configfs support for IIO Daniel Baluta
2015-05-04 10:50 ` [PATCH v5 1/4] iio: core: Introduce IIO software triggers Daniel Baluta
2015-05-04 20:11 ` Lars-Peter Clausen
2015-05-06 9:24 ` Daniel Baluta
2015-05-04 10:50 ` [PATCH v5 2/4] iio: core: Introduce IIO configfs support Daniel Baluta
2015-05-04 19:59 ` Lars-Peter Clausen
2015-05-05 13:48 ` Jonathan Cameron
2015-05-06 16:15 ` Daniel Baluta
2015-05-04 10:50 ` [PATCH v5 3/4] iio: trigger: Introduce IIO hrtimer based trigger Daniel Baluta
2015-05-04 19:54 ` Lars-Peter Clausen
2015-05-05 13:51 ` Jonathan Cameron
2015-05-06 16:25 ` Daniel Baluta [this message]
2015-05-06 17:16 ` Jonathan Cameron
2015-05-06 17:37 ` Daniel Baluta
2015-05-07 9:19 ` Jonathan Cameron
2015-05-07 10:26 ` Daniel Baluta
2015-05-07 18:26 ` Lars-Peter Clausen
2015-05-04 10:50 ` [PATCH v5 4/4] iio: Documentation: Add IIO configfs documentation Daniel Baluta
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=554A4065.8050101@intel.com \
--to=daniel.baluta@intel.com \
--cc=adriana.reus@intel.com \
--cc=constantin.musca@intel.com \
--cc=jic23@kernel.org \
--cc=jlbec@evilplan.org \
--cc=knaack.h@gmx.de \
--cc=lars@metafoo.de \
--cc=linux-iio@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=marten@intuitiveaerial.com \
--cc=octavian.purdila@intel.com \
--cc=patrick.porlan@intel.com \
--cc=pebolle@tiscali.nl \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.