linux-iio.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Lars-Peter Clausen <lars@metafoo.de>
To: Sachin Kamat <sachin.kamat@linaro.org>
Cc: linux-iio@vger.kernel.org, Jonathan Cameron <jic23@kernel.org>
Subject: Re: [PATCH 01/32] iio: core: Implement devm_iio_device_{register,unregister}
Date: Thu, 26 Sep 2013 22:31:11 +0200	[thread overview]
Message-ID: <5244998F.4090905@metafoo.de> (raw)
In-Reply-To: <1380106208-6948-2-git-send-email-sachin.kamat@linaro.org>

On 09/25/2013 12:49 PM, Sachin Kamat wrote:
> Add device managed devm_iio_device_{register,unregister}()
> to automatically unregister IIO drivers thus leading to
> simplified IIO driver code.
>

I have the same fears as Jonathan that this is going to be used incorrectly
for drivers where the remove function is not empty. But hopefully the
benefits outweigh the dangers. So I think we should add this functionality.
But the implementation looks broken. Also few nitpicks on style issue inline
below. Otherwise looks good.


> Signed-off-by: Sachin Kamat <sachin.kamat@linaro.org>
> Cc: Lars-Peter Clausen <lars@metafoo.de>
> ---
>  Documentation/driver-model/devres.txt |    2 ++
>  drivers/iio/industrialio-core.c       |   35 +++++++++++++++++++++++++++++++++
>  include/linux/iio/iio.h               |   25 +++++++++++++++++++++++
>  3 files changed, 62 insertions(+)
> 
> diff --git a/Documentation/driver-model/devres.txt b/Documentation/driver-model/devres.txt
> index fcb34a5..ffeab1d 100644
> --- a/Documentation/driver-model/devres.txt
> +++ b/Documentation/driver-model/devres.txt
> @@ -242,6 +242,8 @@ IIO
>    devm_iio_device_free()
>    devm_iio_trigger_alloc()
>    devm_iio_trigger_free()
> +  devm_iio_device_register()
> +  devm_iio_device_unregister()
>  
>  IO region
>    devm_request_region()
> diff --git a/drivers/iio/industrialio-core.c b/drivers/iio/industrialio-core.c
> index 24db185..58f494b 100644
> --- a/drivers/iio/industrialio-core.c
> +++ b/drivers/iio/industrialio-core.c
> @@ -1125,6 +1125,41 @@ void iio_device_unregister(struct iio_dev *indio_dev)
>  	device_del(&indio_dev->dev);
>  }
>  EXPORT_SYMBOL(iio_device_unregister);
> +
> +static void devm_iio_device_unreg(struct device *dev, void *res)
> +{
> +	iio_device_unregister(*(struct iio_dev **)res);
> +}
> +
> +int devm_iio_device_register(struct device *dev, struct iio_dev *indio_dev)
> +{
> +	void *ptr;
> +	int iio_dev;

ret is probably a better name.

> +
> +	ptr = devres_alloc(devm_iio_device_unreg, 0, GFP_KERNEL);

So we allocate memory with the size of 0. And then never actually pass the
IIO device itself to the devres managed resource, but de-reference the
pointer in devm_iio_device_unreg assuming it points is a iio_dev struct
pointer. This doesn't seem right. I think it needs to be something like this:

struct iio_dev **ptr;

ptr = devres_alloc(devm_iio_device_unreg, sizeof(*ptr), GFP_KERNEL);

...

*ptr = indio_dev;

> +	if (!ptr)
> +		return -ENOMEM;
> +
> +	iio_dev = iio_device_register(indio_dev);
> +	if (!iio_dev)
> +		devres_add(dev, ptr);
> +	else
> +		devres_free(ptr);
> +
> +	return iio_dev;
> +}
> +EXPORT_SYMBOL_GPL(devm_iio_device_register);
> +
> +void devm_iio_device_unregister(struct device *dev, struct iio_dev *iio_dev)

The last parameter should be named indio_dev.

> +{
> +	int rc;
> +
> +	rc = devres_release(dev, devm_iio_device_unreg,
> +			    devm_iio_device_match, iio_dev);
> +	WARN_ON(rc);
> +}
> +EXPORT_SYMBOL_GPL(devm_iio_device_unregister);
> +
>  subsys_initcall(iio_init);
>  module_exit(iio_exit);
>  
> diff --git a/include/linux/iio/iio.h b/include/linux/iio/iio.h
> index ac1cb8f..be16dd6 100644
> --- a/include/linux/iio/iio.h
> +++ b/include/linux/iio/iio.h
> @@ -453,6 +453,31 @@ int iio_device_register(struct iio_dev *indio_dev);
>  void iio_device_unregister(struct iio_dev *indio_dev);
>  
>  /**
> + * devm_iio_device_register - Resource-managed iio_device_register()
> + * @dev:	Device to allocate iio_dev for
> + * @indio_dev:	Device structure filled by the device driver
> + *
> + * Managed iio_device_register.  iio_dev registered with this function is

The IIO device registered ...

I would also add that this function calls iio_device_register() internally
and to look at that function for more information.

> + * automatically unregistered on driver detach.
> + *
> + * If an iio_dev registered with this function needs to be unregistered
> + * separately, devm_iio_device_unregister() must be used.
> + *
> + * RETURNS:
> + * 0 on success, negative error number on failure.
> + */

The kernel doc should be placed above the implementation, not the
definition. And yes we got that wrong on quite a few functions.

> +int devm_iio_device_register(struct device *dev, struct iio_dev *indio_dev);
> +
> +/**
> + * devm_iio_device_unregister - Resource-managed iio_device_unregister()
> + * @dev:	Device this iio_dev belongs to
> + * @indio_dev:	the iio_dev associated with the device
> + *
> + * Unregister iio_dev registered with devm_iio_device_register().
> + */
> +void devm_iio_device_unregister(struct device *dev, struct iio_dev *indio_dev);
> +
> +/**
>   * iio_push_event() - try to add event to the list for userspace reading
>   * @indio_dev:		IIO device structure
>   * @ev_code:		What event
> 


  reply	other threads:[~2013-09-26 20:29 UTC|newest]

Thread overview: 40+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-09-25 10:49 [PATCH Resend 00/32] iio: Introduce devm_iio_device_{register,unregister} Sachin Kamat
2013-09-25 10:49 ` [PATCH 01/32] iio: core: Implement devm_iio_device_{register,unregister} Sachin Kamat
2013-09-26 20:31   ` Lars-Peter Clausen [this message]
2013-09-27  3:07     ` Sachin Kamat
2013-09-25 10:49 ` [PATCH 02/32] iio: accel: kxsd9: Use devm_iio_device_register Sachin Kamat
2013-09-25 20:45   ` Jonathan Cameron
2013-09-25 10:49 ` [PATCH 03/32] iio: adc: mcp3422: " Sachin Kamat
2013-09-25 10:49 ` [PATCH 04/32] iio: adc: twl6030-gpadc: " Sachin Kamat
2013-09-25 10:49 ` [PATCH 05/32] iio: adc: viperboard: " Sachin Kamat
2013-09-25 10:49 ` [PATCH 06/32] iio: dac: ad5421: " Sachin Kamat
2013-09-25 10:49 ` [PATCH 07/32] iio: dac: ad5755: " Sachin Kamat
2013-09-25 10:49 ` [PATCH 08/32] iio: dac: max517: " Sachin Kamat
2013-09-25 21:00   ` Jonathan Cameron
2013-09-25 10:49 ` [PATCH 09/32] iio: dac: mcp4725: " Sachin Kamat
2013-09-25 10:49 ` [PATCH 10/32] iio: gyro: adis16130: " Sachin Kamat
2013-09-25 10:49 ` [PATCH 11/32] iio: gyro: adxrs450: " Sachin Kamat
2013-09-25 10:49 ` [PATCH 12/32] iio: light: vcnl4000: " Sachin Kamat
2013-09-25 10:49 ` [PATCH 13/32] staging: iio: adis16220: " Sachin Kamat
2013-09-25 10:49 ` [PATCH 14/32] staging: iio: ad7816: " Sachin Kamat
2013-09-25 10:49 ` [PATCH 15/32] staging: iio: lpc32xx_adc: " Sachin Kamat
2013-09-25 10:49 ` [PATCH 16/32] staging: iio: addac: " Sachin Kamat
2013-09-25 10:49 ` [PATCH 17/32] staging: iio: ad7150: " Sachin Kamat
2013-09-25 10:49 ` [PATCH 18/32] staging: iio: ad7746: " Sachin Kamat
2013-09-25 10:49 ` [PATCH 19/32] staging: iio: ad5930: " Sachin Kamat
2013-09-25 10:49 ` [PATCH 20/32] staging: iio: ad9850: " Sachin Kamat
2013-09-25 10:49 ` [PATCH 21/32] staging: iio: ad9852: " Sachin Kamat
2013-09-25 10:49 ` [PATCH 22/32] staging: iio: ad9910: " Sachin Kamat
2013-09-25 10:49 ` [PATCH 23/32] staging: iio: ad9951: " Sachin Kamat
2013-09-25 10:50 ` [PATCH 24/32] staging: iio: adis16060: " Sachin Kamat
2013-09-25 10:50 ` [PATCH 25/32] staging: iio: isl29018: " Sachin Kamat
2013-09-25 10:50 ` [PATCH 26/32] staging: iio: isl29028: " Sachin Kamat
2013-09-25 10:50 ` [PATCH 27/32] staging: iio: tsl2583: " Sachin Kamat
2013-09-25 10:50 ` [PATCH 28/32] staging: iio: tsl2x7x_core: " Sachin Kamat
2013-09-25 16:32   ` Jonathan Cameron
2013-09-25 10:50 ` [PATCH 29/32] staging: iio: ade7854: " Sachin Kamat
2013-09-25 10:50 ` [PATCH 30/32] staging: iio: ad2s1200: " Sachin Kamat
2013-09-25 10:50 ` [PATCH 31/32] staging: iio: ad2s90: " Sachin Kamat
2013-09-25 10:50 ` [PATCH 32/32] staging: iio: ad7152: " Sachin Kamat
2013-09-25 16:24 ` [PATCH Resend 00/32] iio: Introduce devm_iio_device_{register,unregister} Jonathan Cameron
2013-09-25 16:30   ` 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=5244998F.4090905@metafoo.de \
    --to=lars@metafoo.de \
    --cc=jic23@kernel.org \
    --cc=linux-iio@vger.kernel.org \
    --cc=sachin.kamat@linaro.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).