public inbox for linux-iio@vger.kernel.org
 help / color / mirror / Atom feed
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,
>>> +};
>> [...]

  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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox