From: Lars-Peter Clausen <lars@metafoo.de>
To: Josh Cartwright <joshc@codeaurora.org>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
linux-arm-msm@vger.kernel.org,
Sagar Dharia <sdharia@codeaurora.org>,
Gilad Avidov <gavidov@codeaurora.org>,
Michael Bohan <mbohan@codeaurora.org>
Subject: Re: [PATCH v3 02/10] spmi: Linux driver framework for SPMI
Date: Tue, 29 Oct 2013 16:21:28 +0100 [thread overview]
Message-ID: <526FD278.8080102@metafoo.de> (raw)
In-Reply-To: <149bbfe89e37376cc176c3aeb6c1fab9e4fd2b91.1382985169.git.joshc@codeaurora.org>
Couple of high-level comments on the in-kernel API.
On 10/28/2013 07:12 PM, Josh Cartwright wrote:
> +#ifdef CONFIG_PM_SLEEP
> +static int spmi_pm_suspend(struct device *dev)
> +{
> + const struct dev_pm_ops *pm = dev->driver ? dev->driver->pm : NULL;
> +
> + if (pm)
> + return pm_generic_suspend(dev);
pm_generic_suspend() checks both dev->driver and dev->driver->pm and returns
0 if either of them is NULL, so there should be no need to wrap the function.
> + else
> + return 0;
> +}
> +
> +static int spmi_pm_resume(struct device *dev)
> +{
> + const struct dev_pm_ops *pm = dev->driver ? dev->driver->pm : NULL;
> +
> + if (pm)
> + return pm_generic_resume(dev);
Same here
> + else
> + return 0;
> +}
> +#else
> +#define spmi_pm_suspend NULL
> +#define spmi_pm_resume NULL
> +#endif
[...]
> +/**
> + * spmi_controller_remove: Controller tear-down.
> + * @ctrl: controller to be removed.
> + *
> + * Controller added with the above API is torn down using this API.
> + */
> +int spmi_controller_remove(struct spmi_controller *ctrl)
The return type should be void. The function can't fail and nobody is going
to check the return value anyway.
> +{
> + int dummy;
> +
> + if (!ctrl)
> + return -EINVAL;
> +
> + dummy = device_for_each_child(&ctrl->dev, NULL,
> + spmi_ctrl_remove_device);
> + device_unregister(&ctrl->dev);
Should be device_del(). device_unregister() will do both device_del() and
put_device(). But usually you'd want to do something in between like release
resources used by the controller.
> + return 0;
> +}
> +EXPORT_SYMBOL_GPL(spmi_controller_remove);
> +
[...]
> +/**
> + * spmi_controller_alloc: Allocate a new SPMI controller
> + * @ctrl: associated controller
> + *
> + * Caller is responsible for either calling spmi_device_add() to add the
> + * newly allocated controller, or calling spmi_device_put() to discard it.
> + */
> +struct spmi_device *spmi_device_alloc(struct spmi_controller *ctrl);
> +
> +static inline void spmi_device_put(struct spmi_device *sdev)
For symmetry reasons it might make sense to call this spmi_device_free().
> +{
> + if (sdev)
> + put_device(&sdev->dev);
> +}
[...]
> +#define to_spmi_controller(d) container_of(d, struct spmi_controller, dev)
Should be a inline function for better type safety.
[...]
> +static inline void spmi_controller_put(struct spmi_controller *ctrl)
For symmetry reasons it might make sense to call this spmi_controller_free().
> +{
> + if (ctrl)
> + put_device(&ctrl->dev);
> +}
> +
[....]
> +struct spmi_driver {
> + struct device_driver driver;
> + int (*probe)(struct spmi_device *sdev);
> + int (*remove)(struct spmi_device *sdev);
The type of the remove function should be found. The Linux device model
doesn't really allow for device removal to fail.
> + void (*shutdown)(struct spmi_device *sdev);
> + int (*suspend)(struct spmi_device *sdev, pm_message_t pmesg);
> + int (*resume)(struct spmi_device *sdev);
The framework seems to support dev_pm_ops just fine, there should be no need
for legacy suspend/resume callbacks.
> +};
> +#define to_spmi_driver(d) container_of(d, struct spmi_driver, driver)
Inline function here as well
[...]
WARNING: multiple messages have this Message-ID (diff)
From: lars@metafoo.de (Lars-Peter Clausen)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v3 02/10] spmi: Linux driver framework for SPMI
Date: Tue, 29 Oct 2013 16:21:28 +0100 [thread overview]
Message-ID: <526FD278.8080102@metafoo.de> (raw)
In-Reply-To: <149bbfe89e37376cc176c3aeb6c1fab9e4fd2b91.1382985169.git.joshc@codeaurora.org>
Couple of high-level comments on the in-kernel API.
On 10/28/2013 07:12 PM, Josh Cartwright wrote:
> +#ifdef CONFIG_PM_SLEEP
> +static int spmi_pm_suspend(struct device *dev)
> +{
> + const struct dev_pm_ops *pm = dev->driver ? dev->driver->pm : NULL;
> +
> + if (pm)
> + return pm_generic_suspend(dev);
pm_generic_suspend() checks both dev->driver and dev->driver->pm and returns
0 if either of them is NULL, so there should be no need to wrap the function.
> + else
> + return 0;
> +}
> +
> +static int spmi_pm_resume(struct device *dev)
> +{
> + const struct dev_pm_ops *pm = dev->driver ? dev->driver->pm : NULL;
> +
> + if (pm)
> + return pm_generic_resume(dev);
Same here
> + else
> + return 0;
> +}
> +#else
> +#define spmi_pm_suspend NULL
> +#define spmi_pm_resume NULL
> +#endif
[...]
> +/**
> + * spmi_controller_remove: Controller tear-down.
> + * @ctrl: controller to be removed.
> + *
> + * Controller added with the above API is torn down using this API.
> + */
> +int spmi_controller_remove(struct spmi_controller *ctrl)
The return type should be void. The function can't fail and nobody is going
to check the return value anyway.
> +{
> + int dummy;
> +
> + if (!ctrl)
> + return -EINVAL;
> +
> + dummy = device_for_each_child(&ctrl->dev, NULL,
> + spmi_ctrl_remove_device);
> + device_unregister(&ctrl->dev);
Should be device_del(). device_unregister() will do both device_del() and
put_device(). But usually you'd want to do something in between like release
resources used by the controller.
> + return 0;
> +}
> +EXPORT_SYMBOL_GPL(spmi_controller_remove);
> +
[...]
> +/**
> + * spmi_controller_alloc: Allocate a new SPMI controller
> + * @ctrl: associated controller
> + *
> + * Caller is responsible for either calling spmi_device_add() to add the
> + * newly allocated controller, or calling spmi_device_put() to discard it.
> + */
> +struct spmi_device *spmi_device_alloc(struct spmi_controller *ctrl);
> +
> +static inline void spmi_device_put(struct spmi_device *sdev)
For symmetry reasons it might make sense to call this spmi_device_free().
> +{
> + if (sdev)
> + put_device(&sdev->dev);
> +}
[...]
> +#define to_spmi_controller(d) container_of(d, struct spmi_controller, dev)
Should be a inline function for better type safety.
[...]
> +static inline void spmi_controller_put(struct spmi_controller *ctrl)
For symmetry reasons it might make sense to call this spmi_controller_free().
> +{
> + if (ctrl)
> + put_device(&ctrl->dev);
> +}
> +
[....]
> +struct spmi_driver {
> + struct device_driver driver;
> + int (*probe)(struct spmi_device *sdev);
> + int (*remove)(struct spmi_device *sdev);
The type of the remove function should be found. The Linux device model
doesn't really allow for device removal to fail.
> + void (*shutdown)(struct spmi_device *sdev);
> + int (*suspend)(struct spmi_device *sdev, pm_message_t pmesg);
> + int (*resume)(struct spmi_device *sdev);
The framework seems to support dev_pm_ops just fine, there should be no need
for legacy suspend/resume callbacks.
> +};
> +#define to_spmi_driver(d) container_of(d, struct spmi_driver, driver)
Inline function here as well
[...]
next prev parent reply other threads:[~2013-10-29 15:21 UTC|newest]
Thread overview: 82+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-10-28 18:32 [PATCH v3 00/10] Add support for the System Power Management Interface (SPMI) Josh Cartwright
2013-10-28 18:32 ` Josh Cartwright
2013-10-28 18:12 ` [PATCH v3 10/10] rtc: pm8xxx: add support for pm8941 Josh Cartwright
2013-10-28 18:12 ` Josh Cartwright
2013-10-29 20:09 ` Stephen Boyd
2013-10-29 20:09 ` Stephen Boyd
2013-10-29 20:15 ` Greg Kroah-Hartman
2013-10-29 20:15 ` Greg Kroah-Hartman
2013-10-29 20:20 ` Stephen Boyd
2013-10-29 20:20 ` Stephen Boyd
2013-10-29 20:32 ` Greg Kroah-Hartman
2013-10-29 20:32 ` Greg Kroah-Hartman
2013-10-28 18:12 ` [PATCH v3 09/10] mfd: pm8x41: document device tree bindings Josh Cartwright
2013-10-28 18:12 ` Josh Cartwright
2013-10-29 14:18 ` Ivan T. Ivanov
2013-10-29 14:18 ` Ivan T. Ivanov
2013-10-29 15:05 ` Josh Cartwright
2013-10-29 15:05 ` Josh Cartwright
2013-10-29 15:31 ` Ivan T. Ivanov
2013-10-29 15:31 ` Ivan T. Ivanov
2013-10-28 18:12 ` [PATCH v3 08/10] mfd: pm8x41: add support for Qualcomm 8x41 PMICs Josh Cartwright
2013-10-28 18:12 ` Josh Cartwright
2013-10-29 0:40 ` Stephen Boyd
2013-10-29 0:40 ` Stephen Boyd
2013-10-29 15:56 ` Lee Jones
2013-10-29 15:56 ` Lee Jones
2013-10-29 16:03 ` Josh Cartwright
2013-10-29 16:03 ` Josh Cartwright
2013-10-28 18:12 ` [PATCH v3 06/10] spmi: document the PMIC arbiter SPMI bindings Josh Cartwright
2013-10-28 18:12 ` Josh Cartwright
2013-10-29 14:08 ` Ivan T. Ivanov
2013-10-29 14:08 ` Ivan T. Ivanov
2013-10-29 15:12 ` Josh Cartwright
2013-10-29 15:12 ` Josh Cartwright
2013-10-28 18:12 ` [PATCH v3 07/10] regmap: add SPMI support Josh Cartwright
2013-10-28 18:12 ` Josh Cartwright
2013-10-28 20:01 ` Mark Brown
2013-10-28 20:01 ` Mark Brown
2013-10-28 18:12 ` [PATCH v3 05/10] spmi: pmic_arb: add support for interrupt handling Josh Cartwright
2013-10-28 18:12 ` Josh Cartwright
2013-10-30 18:17 ` Stephen Boyd
2013-10-30 18:17 ` Stephen Boyd
2013-10-30 19:10 ` Josh Cartwright
2013-10-30 19:10 ` Josh Cartwright
2013-10-28 18:12 ` [PATCH v3 04/10] spmi: Add MSM PMIC Arbiter SPMI controller Josh Cartwright
2013-10-28 18:12 ` Josh Cartwright
2013-10-30 18:05 ` Stephen Boyd
2013-10-30 18:05 ` Stephen Boyd
2013-10-30 19:17 ` Josh Cartwright
2013-10-30 19:17 ` Josh Cartwright
2013-10-28 18:12 ` [PATCH v3 02/10] spmi: Linux driver framework for SPMI Josh Cartwright
2013-10-28 18:12 ` Josh Cartwright
2013-10-29 15:02 ` Ivan T. Ivanov
2013-10-29 15:02 ` Ivan T. Ivanov
2013-10-29 16:26 ` Josh Cartwright
2013-10-29 16:26 ` Josh Cartwright
2013-10-29 18:00 ` Ivan T. Ivanov
2013-10-29 18:00 ` Ivan T. Ivanov
2013-10-29 15:21 ` Lars-Peter Clausen [this message]
2013-10-29 15:21 ` Lars-Peter Clausen
2013-10-29 15:56 ` Josh Cartwright
2013-10-29 15:56 ` Josh Cartwright
2013-10-29 16:30 ` Stephen Boyd
2013-10-29 16:30 ` Stephen Boyd
2013-10-29 19:18 ` Lars-Peter Clausen
2013-10-29 19:18 ` Lars-Peter Clausen
2013-10-29 19:26 ` Lars-Peter Clausen
2013-10-29 19:26 ` Lars-Peter Clausen
2013-10-29 16:52 ` Stephen Boyd
2013-10-29 16:52 ` Stephen Boyd
2013-10-30 19:37 ` Josh Cartwright
2013-10-30 19:37 ` Josh Cartwright
2013-10-30 19:45 ` Stephen Boyd
2013-10-30 19:45 ` Stephen Boyd
2013-10-30 0:11 ` Russell King - ARM Linux
2013-10-30 0:11 ` Russell King - ARM Linux
2013-10-28 18:12 ` [PATCH v3 01/10] of: Add empty for_each_available_child_of_node() macro definition Josh Cartwright
2013-10-28 18:12 ` Josh Cartwright
2013-10-29 5:50 ` Rob Herring
2013-10-29 5:50 ` Rob Herring
2013-10-28 18:12 ` [PATCH v3 03/10] spmi: add generic SPMI controller binding documentation Josh Cartwright
2013-10-28 18:12 ` Josh Cartwright
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=526FD278.8080102@metafoo.de \
--to=lars@metafoo.de \
--cc=gavidov@codeaurora.org \
--cc=gregkh@linuxfoundation.org \
--cc=joshc@codeaurora.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-arm-msm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mbohan@codeaurora.org \
--cc=sdharia@codeaurora.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 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.