linux-iio.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jonathan Cameron <jic23@kernel.org>
To: Crestez Dan Leonard <leonard.crestez@intel.com>,
	Peter Meerwald-Stadler <pmeerw@pmeerw.net>
Cc: linux-iio@vger.kernel.org, linux-kernel@vger.kernel.org,
	Hartmut Knaack <knaack.h@gmx.de>,
	Lars-Peter Clausen <lars@metafoo.de>,
	Daniel Baluta <daniel.baluta@intel.com>
Subject: Re: [PATCH 5/5] max44000: Initial triggered buffer support
Date: Sun, 17 Apr 2016 09:41:38 +0100	[thread overview]
Message-ID: <57134C42.8070103@kernel.org> (raw)
In-Reply-To: <570BCCA5.7020004@intel.com>

On 11/04/16 17:11, Crestez Dan Leonard wrote:
> On 04/07/2016 10:59 PM, Peter Meerwald-Stadler wrote:
>>>   static int max44000_probe(struct i2c_client *client,
>>>                 const struct i2c_device_id *id)
>>>   {
>>> @@ -513,6 +569,12 @@ static int max44000_probe(struct i2c_client *client,
>>>           return ret;
>>>       }
>>>
>>> +    ret = iio_triggered_buffer_setup(indio_dev, NULL, max44000_trigger_handler, NULL);
>>> +    if (ret < 0) {
>>> +        dev_err(&client->dev, "iio triggered buffer setup failed\n");
>>> +        return ret;
>>> +    }
>>> +
>>>       return iio_device_register(indio_dev);
>>
>> no devm_ possible anymore :-)
> 
> It's not clear to me why explicit calls to
> iio_triggered_buffer_cleanup are done in every driver. Wouldn't it be
> possible for iio_dev_release to call iio_triggered_buffer_cleanup?
> That would require triggered_buffer_cleanup to explictly NULL the
> fields it deallocates so that duplicate cleanups don't crash.
Because not all devices are using the triggered buffer setup function
thus they can't use the cleanup one.  There are different buffers for
starters and the core has no way to identify them (very deliberately
as it should never care what they are).

There is also the general obvious correctness of code question.
If you do one thing in probe, it should be reverse in remove...

We could in theory do a devm version of the iio_triggered_buffer_cleanup
function though as then the tear down would occur in the write order and
as it is a devm_ call in the probe we'd know how the unwind was being
done...


> -- 
> Regards,
> Leonard


  reply	other threads:[~2016-04-17  8:41 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-04-07 16:21 [PATCH 0/5] Support for max44000 Ambient and Infrared Proximity Sensor Crestez Dan Leonard
2016-04-07 16:21 ` [PATCH 1/5] max44000: Initial commit Crestez Dan Leonard
2016-04-07 19:48   ` Peter Meerwald-Stadler
2016-04-10 13:12     ` Jonathan Cameron
2016-04-11 15:08       ` Crestez Dan Leonard
2016-04-17  8:36         ` Jonathan Cameron
2016-04-18 10:32           ` Mark Brown
2016-04-18 10:59             ` Lars-Peter Clausen
2016-04-18 12:15             ` Crestez Dan Leonard
2016-04-18 12:34               ` Mark Brown
     [not found]                 ` <57153733.1070605@kernel.org>
2016-04-19  9:06                   ` Mark Brown
2016-04-18 19:38             ` Jonathan Cameron
2016-04-07 16:21 ` [PATCH 2/5] max44000: Initial support for proximity reading Crestez Dan Leonard
2016-04-10 13:14   ` Jonathan Cameron
2016-04-07 16:21 ` [PATCH 3/5] max44000: Support controlling LED current output Crestez Dan Leonard
2016-04-10 13:16   ` Jonathan Cameron
2016-04-07 16:21 ` [PATCH 4/5] max44000: Expose ambient sensor scaling Crestez Dan Leonard
2016-04-10 13:20   ` Jonathan Cameron
2016-04-07 16:21 ` [PATCH 5/5] max44000: Initial triggered buffer support Crestez Dan Leonard
2016-04-07 19:59   ` Peter Meerwald-Stadler
2016-04-11 16:11     ` Crestez Dan Leonard
2016-04-17  8:41       ` Jonathan Cameron [this message]
2016-04-07 21:56   ` kbuild test robot
2016-04-10 13:24   ` Jonathan Cameron

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=57134C42.8070103@kernel.org \
    --to=jic23@kernel.org \
    --cc=daniel.baluta@intel.com \
    --cc=knaack.h@gmx.de \
    --cc=lars@metafoo.de \
    --cc=leonard.crestez@intel.com \
    --cc=linux-iio@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=pmeerw@pmeerw.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;
as well as URLs for NNTP newsgroup(s).