From: Hartmut Knaack <knaack.h@gmx.de>
To: Octavian Purdila <octavian.purdila@intel.com>
Cc: linux-iio@vger.kernel.org,
Srinivas Pandruvada <srinivas.pandruvada@intel.com>
Subject: Re: [RFC 6/8] iio: bmc150: introduce bmc150_accel_trigger
Date: Mon, 24 Nov 2014 21:26:10 +0100 [thread overview]
Message-ID: <54739462.7060300@gmx.de> (raw)
In-Reply-To: <CAE1zotKM30FQ1ScrEiPGW4SuLvjTUVpj4eg0wpCLY=UVU_UHxw@mail.gmail.com>
Octavian Purdila schrieb am 24.11.2014 11:42:
> On Mon, Nov 24, 2014 at 1:06 AM, Hartmut Knaack <knaack.h@gmx.de> wrote:
>>> +
>>> +static void bmc150_accel_unregister_triggers(struct bmc150_accel_data *data,
>>> + int from)
>>> +{
>>> + int i;
>>> +
>>> + for (i = from; i >= 0; i++) {
>>> + if (data->triggers[i].indio_trig) {
>>> + iio_trigger_unregister(data->triggers[i].indio_trig);
>>> + data->triggers[i].indio_trig = NULL;
>> Better use devm_iio_trigger_free()?
>
> Wouldn't that be called anyway a little bit later?
I thought it would be cleaner/safer to release it using the opposite of devm_iio_trigger_alloc(), instead of changing its reference to NULL.
>
>>> + }
>>> + i--;
>>> + }
>> i++ and i-- in the same loop looks like an infinite loop to me. Not to mention what happens on the second attempt to unregister the same trigger.
>
> Oops.
>
>>> +}
>>> +
>>> +static int bmc150_accel_triggers_setup(struct iio_dev *indio_dev,
>>> + struct bmc150_accel_data *data)
>>> +{
>>> + int i, ret;
>>> +
>>> + for (i = 0; i < BMC150_ACCEL_TRIGGERS; i++) {
>>> + struct bmc150_accel_trigger *t = &data->triggers[i];
>>> + const char *name = bmc150_accel_triggers[i].name;
>>> + int intr = bmc150_accel_triggers[i].intr;
>>> +
>>> + t->indio_trig = devm_iio_trigger_alloc(&data->client->dev, name,
>>> + indio_dev->name,
>>> + indio_dev->id);
>>> + if (!t->indio_trig) {
>>> + ret = -ENOMEM;
>>> + break;
>>> + }
>>> +
>>> + t->indio_trig->dev.parent = &data->client->dev;
>>> + t->indio_trig->ops = &bmc150_accel_trigger_ops;
>>> + t->intr = &data->interrupts[intr];
>>> + t->data = data;
>>> + iio_trigger_set_drvdata(t->indio_trig, t);
>>> +
>>> + ret = iio_trigger_register(t->indio_trig);
>>> + if (ret)
>>> + break;
>>> + }
>>> +
>>> + if (ret)
>>> + bmc150_accel_unregister_triggers(data, i);
>> I think this should be called with i - 1.
>
> You're right.
>
> Thanks for the reviews Hartmut, I will send a new version after we
> decide on the hardware buffer approach.
> --
> To unsubscribe from this list: send the line "unsubscribe linux-iio" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
next prev parent reply other threads:[~2014-11-24 20:26 UTC|newest]
Thread overview: 40+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-11-17 17:55 [RFC 0/8] iio: add support for hardware fifo Octavian Purdila
2014-11-17 17:55 ` [RFC 1/8] " Octavian Purdila
2014-11-18 13:37 ` jic23
2014-11-18 15:21 ` Octavian Purdila
2014-11-17 17:56 ` [RFC 2/8] iio: bmc150: refactor slope duration and threshold update Octavian Purdila
2014-11-23 21:58 ` Hartmut Knaack
2014-11-23 22:16 ` Octavian Purdila
2014-11-17 17:56 ` [RFC 3/8] iio: bmc150: refactor interrupt enabling Octavian Purdila
2014-11-23 22:02 ` Hartmut Knaack
2014-11-23 22:24 ` Octavian Purdila
2014-11-17 17:56 ` [RFC 4/8] iio: bmc150: exit early if event / trigger state is not changed Octavian Purdila
2014-11-17 17:56 ` [RFC 5/8] iio: bmc150: introduce bmc150_accel_interrupt Octavian Purdila
2014-11-17 17:56 ` [RFC 6/8] iio: bmc150: introduce bmc150_accel_trigger Octavian Purdila
2014-11-23 23:06 ` Hartmut Knaack
2014-11-24 10:42 ` Octavian Purdila
2014-11-24 20:26 ` Hartmut Knaack [this message]
2014-11-25 16:06 ` Octavian Purdila
2014-11-17 17:56 ` [RFC 7/8] iio: bmc150: introduce bmc150_accel_event Octavian Purdila
2014-11-17 17:56 ` [RFC 8/8] iio: bmc150: add support for hardware fifo Octavian Purdila
2014-11-18 13:49 ` jic23
2014-11-18 15:31 ` Octavian Purdila
2014-11-24 10:37 ` Hartmut Knaack
2014-11-18 13:24 ` [RFC 0/8] iio: " jic23
2014-11-18 15:03 ` Octavian Purdila
2014-11-18 16:44 ` Lars-Peter Clausen
2014-11-18 17:04 ` Octavian Purdila
2014-11-18 17:23 ` Lars-Peter Clausen
2014-11-18 19:35 ` Octavian Purdila
2014-11-19 11:48 ` Lars-Peter Clausen
2014-11-19 12:33 ` Octavian Purdila
2014-12-12 12:57 ` Jonathan Cameron
2014-11-19 13:32 ` Octavian Purdila
2014-11-26 13:06 ` Octavian Purdila
2014-12-01 21:19 ` Lars-Peter Clausen
2014-12-02 9:13 ` Octavian Purdila
2014-12-12 13:10 ` Jonathan Cameron
2014-12-12 13:04 ` Jonathan Cameron
2014-12-12 12:52 ` Jonathan Cameron
2014-11-18 15:35 ` Pandruvada, Srinivas
2014-11-18 16:41 ` Lars-Peter Clausen
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=54739462.7060300@gmx.de \
--to=knaack.h@gmx.de \
--cc=linux-iio@vger.kernel.org \
--cc=octavian.purdila@intel.com \
--cc=srinivas.pandruvada@intel.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 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.