Re: [PATCH v3 02/10] spmi: Linux driver framework for SPMI

[Josh Cartwright]

Hey Lars-

Thanks for the feedback.  CC'ing Ivan, since he had the same feedback
regarding the PM callbacks.

On Tue, Oct 29, 2013 at 04:21:28PM +0100, Lars-Peter Clausen wrote:
> 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

Sounds good.  I'll drop these.

> > +/**
> > + * 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.

Alright.

> > +{
> > +	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.

I'm not sure I understand your suggestion here.  If put_device() isn't
called here, wouldn't we be leaking the controller?  What resources
would I want to be releasing here that aren't released as part of the
controller's release() function?

> > +	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().

Except that it doesn't necessarily free() the underlying device, so I
find that more confusing.

> > +{
> > +	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.

Sounds good.  Will change the to_spmi_*() macros.

> [...]
> > +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.

Yep.  Will drop.

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/