linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
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
[...]

  parent reply	other threads:[~2013-10-29 15:21 UTC|newest]

Thread overview: 41+ 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:12 ` [PATCH v3 05/10] spmi: pmic_arb: add support for interrupt handling Josh Cartwright
2013-10-30 18:17   ` Stephen Boyd
2013-10-30 19:10     ` Josh Cartwright
2013-10-28 18:12 ` [PATCH v3 08/10] mfd: pm8x41: add support for Qualcomm 8x41 PMICs Josh Cartwright
2013-10-29  0:40   ` Stephen Boyd
2013-10-29 15:56   ` Lee Jones
2013-10-29 16:03     ` Josh Cartwright
2013-10-28 18:12 ` [PATCH v3 10/10] rtc: pm8xxx: add support for pm8941 Josh Cartwright
2013-10-29 20:09   ` Stephen Boyd
2013-10-29 20:15     ` Greg Kroah-Hartman
2013-10-29 20:20       ` Stephen Boyd
2013-10-29 20:32         ` Greg Kroah-Hartman
2013-10-28 18:12 ` [PATCH v3 07/10] regmap: add SPMI support Josh Cartwright
2013-10-28 20:01   ` Mark Brown
2013-10-28 18:12 ` [PATCH v3 09/10] mfd: pm8x41: document device tree bindings Josh Cartwright
2013-10-29 14:18   ` Ivan T. Ivanov
2013-10-29 15:05     ` Josh Cartwright
2013-10-29 15:31       ` Ivan T. Ivanov
2013-10-28 18:12 ` [PATCH v3 03/10] spmi: add generic SPMI controller binding documentation Josh Cartwright
2013-10-28 18:12 ` [PATCH v3 04/10] spmi: Add MSM PMIC Arbiter SPMI controller Josh Cartwright
2013-10-30 18:05   ` Stephen Boyd
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-29 15:02   ` Ivan T. Ivanov
2013-10-29 16:26     ` Josh Cartwright
2013-10-29 18:00       ` Ivan T. Ivanov
2013-10-29 15:21   ` Lars-Peter Clausen [this message]
2013-10-29 15:56     ` Josh Cartwright
2013-10-29 16:30       ` Stephen Boyd
2013-10-29 19:18         ` Lars-Peter Clausen
2013-10-29 19:26       ` Lars-Peter Clausen
2013-10-29 16:52   ` Stephen Boyd
2013-10-30 19:37     ` Josh Cartwright
2013-10-30 19:45       ` Stephen Boyd
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-29  5:50   ` Rob Herring
2013-10-28 18:12 ` [PATCH v3 06/10] spmi: document the PMIC arbiter SPMI bindings Josh Cartwright
2013-10-29 14:08   ` Ivan T. Ivanov
2013-10-29 15: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=linux-arm-kernel@lists.infradead.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).