From: Chanwoo Choi <cw00.choi@samsung.com>
To: Sangjung Woo <sangjung.woo@samsung.com>
Cc: MyungJoo Ham <myungjoo.ham@samsung.com>, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 1/8] extcon: Add resource-managed extcon register function
Date: Thu, 17 Apr 2014 14:35:53 +0900 [thread overview]
Message-ID: <534F6839.5070505@samsung.com> (raw)
In-Reply-To: <1397644023-32516-2-git-send-email-sangjung.woo@samsung.com>
Hi Sangjung,
Thanks for your contribution.
On 04/16/2014 07:26 PM, Sangjung Woo wrote:
> Add resource-managed extcon device register function for convenience.
> For example, if a extcon device is attached with new
> devm_extcon_dev_register(), that extcon device is automatically
> unregistered on driver detach.
>
> Signed-off-by: Sangjung Woo <sangjung.woo@samsung.com>
> ---
> drivers/extcon/extcon-class.c | 83 +++++++++++++++++++++++++++++++++++++++++
> include/linux/extcon.h | 8 ++++
> 2 files changed, 91 insertions(+)
>
> diff --git a/drivers/extcon/extcon-class.c b/drivers/extcon/extcon-class.c
> index 7ab21aa..accb49c 100644
> --- a/drivers/extcon/extcon-class.c
> +++ b/drivers/extcon/extcon-class.c
> @@ -32,6 +32,7 @@
> #include <linux/slab.h>
> #include <linux/sysfs.h>
> #include <linux/of.h>
> +#include <linux/gfp.h>
It is not necessary because 'device.h' already includes 'gfp.h' header file.
>
> /*
> * extcon_cable_name suggests the standard cable names for commonly used
> @@ -819,6 +820,88 @@ void extcon_dev_unregister(struct extcon_dev *edev)
> }
> EXPORT_SYMBOL_GPL(extcon_dev_unregister);
>
> +
> +/*
> + * Device resource management
> + */
> +
Should delete blank line.
> +struct extcon_devres {
> + struct extcon_dev *edev;
> +};
> +
> +static void devm_extcon_release(struct device *dev, void *res)
Need to change function name as following to sustain consistency of existing extcon functions.
- devm_extcon_release -> devm_extcon_dev_release()
> +{
> + struct extcon_devres *dr = (struct extcon_devres *)res;
> +
> + extcon_dev_unregister(dr->edev);
> +}
> +
> +static int devm_extcon_match(struct device *dev, void *res, void *data)
ditto.
- devm_extcon_match -> devm_extcon_dev_match
> +{
> + struct extcon_devres *dr = (struct extcon_devres *)res;
> + struct extcon_devres *match = (struct extcon_devres *)data;
I think that this function don't need explicit casting
because as I knew, casting is automatically about tool-chain.
> +
> + return dr->edev == match->edev;
> +}
> +
> +/**
> + * devm_extcon_dev_register() - Resource-managed extcon_dev_register()
> + * @dev: device to allocate extcon device
> + * @edev: the new extcon device to register
> + *
> + * Managed extcon_dev_register() function. If extcon device is attached with
> + * this function, that extcon device is automatically unregistered on driver
> + * detach. Internally this function calls extcon_dev_register() function.
> + * To get more information, refer that function.
> + *
> + * If extcon device is registered with this function and the device needs to be
> + * unregistered separately, devm_extcon_dev_unregister() should be used.
> + *
> + * RETURNS:
> + * 0 on success, negative error number on failure.
> + */
> +int devm_extcon_dev_register(struct device *dev, struct extcon_dev *edev)
> +{
> + struct extcon_devres *dr;
To improve readability, I prefer to change 'dr' variable name (e.g., dr ->devres)
> + int rc;
I think 'rc' variable name is ambiguous.
I prefer to change variable name for return value. (rc -> ret)
> +
> + dr = devres_alloc(devm_extcon_release, sizeof(struct extcon_devres),
ditto.
- devm_extcon_release -> devm_extcon_dev_release
We chan modify it as following:
sizeof(struct extcon_devres) -> sizeof(*dr)
> + GFP_KERNEL);
> + if (!dr)
> + return -ENOMEM;
> +
> + rc = extcon_dev_register(edev);
> + if (rc) {
> + devres_free(dr);
> + return rc;
> + }
> +
> + dr->edev = edev;
> + devres_add(dev, dr);
> +
> + return 0;
> +}
> +EXPORT_SYMBOL_GPL(devm_extcon_dev_register);
> +
> +/**
> + * devm_extcon_dev_unregister() - Resource-managed extcon_dev_unregister()
> + * @dev: device the extcon belongs to
> + * @edev: the extcon device to unregister
> + *
> + * Unregister extcon device that is registered with devm_extcon_dev_register()
> + * function.
> + */
> +void devm_extcon_dev_unregister(struct device *dev, struct extcon_dev *edev)
> +{
> + struct extcon_devres match_dr = { edev };
Should we define 'match_dr' variable? I think it is not necessary.
Maybe it could use 'edev' directly without casting.
> +
> + WARN_ON(devres_destroy(dev, devm_extcon_release,
> + devm_extcon_match, &match_dr));
I think that devres_release() is more proper than devres_destroy.
> +
> + extcon_dev_unregister(edev);
If you use devres_release() instead of devres_destroy(), don't need to call
extcon_dev_unregister() function separately because devres_release() function
would call 'release' function.
> +}
> +EXPORT_SYMBOL_GPL(devm_extcon_dev_unregister);
> +
> #ifdef CONFIG_OF
> /*
> * extcon_get_edev_by_phandle - Get the extcon device from devicetree
> diff --git a/include/linux/extcon.h b/include/linux/extcon.h
> index f488145..e1e85a1 100644
> --- a/include/linux/extcon.h
> +++ b/include/linux/extcon.h
> @@ -188,6 +188,14 @@ extern void extcon_dev_unregister(struct extcon_dev *edev);
> extern struct extcon_dev *extcon_get_extcon_dev(const char *extcon_name);
>
> /*
> + * Resource-managed extcon device register function.
> + */
> +extern int devm_extcon_dev_register(struct device *dev,
> + struct extcon_dev *edev);
> +extern void devm_extcon_dev_unregister(struct device *dev,
> + struct extcon_dev *edev);
This functions need to consider if CONFIG_OF is disabled.
IF CONFIG_OF is disabled, devm_extcon_dev_register/unregister() function
must need static inline function for dummy function.
Thanks,
Chanwoo Choi
next prev parent reply other threads:[~2014-04-17 5:35 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-04-16 10:26 [PATCH 0/8] Resource-managed extcon device register function Sangjung Woo
2014-04-16 10:26 ` [PATCH 1/8] extcon: Add resource-managed extcon " Sangjung Woo
2014-04-17 5:35 ` Chanwoo Choi [this message]
2014-04-16 10:26 ` [PATCH 2/8] extcon: adc-jack: Use devm_extcon_dev_register() Sangjung Woo
2014-04-16 10:26 ` [PATCH 3/8] extcon: gpio: " Sangjung Woo
2014-04-16 10:26 ` [PATCH 4/8] extcon: max14577: " Sangjung Woo
2014-04-16 11:40 ` Krzysztof Kozlowski
2014-04-16 10:27 ` [PATCH 5/8] extcon: max77693: " Sangjung Woo
2014-04-16 11:23 ` Krzysztof Kozlowski
2014-04-16 10:27 ` [PATCH 6/8] extcon: max8997: " Sangjung Woo
2014-04-16 11:23 ` Krzysztof Kozlowski
2014-04-16 10:27 ` [PATCH 7/8] extcon: palmas: " Sangjung Woo
2014-04-16 10:27 ` [PATCH 8/8] extcon: arizona: " Sangjung Woo
2014-04-16 10:44 ` Seung-Woo Kim
2014-04-17 1:00 ` Sangjung
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=534F6839.5070505@samsung.com \
--to=cw00.choi@samsung.com \
--cc=linux-kernel@vger.kernel.org \
--cc=myungjoo.ham@samsung.com \
--cc=sangjung.woo@samsung.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox