linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: iivanov@mm-sol.com (Ivan T. Ivanov)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v3 02/10] spmi: Linux driver framework for SPMI
Date: Tue, 29 Oct 2013 20:00:23 +0200	[thread overview]
Message-ID: <1383069623.14905.7.camel@localhost> (raw)
In-Reply-To: <20131029162615.GH20207@joshc.qualcomm.com>


Hi,

On Tue, 2013-10-29 at 11:26 -0500, Josh Cartwright wrote:
> On Tue, Oct 29, 2013 at 05:02:03PM +0200, Ivan T. Ivanov wrote:
> > On Mon, 2013-10-28 at 13:12 -0500, Josh Cartwright wrote: 
> > > From: Kenneth Heitke <kheitke@codeaurora.org>
> > > 
> > > System Power Management Interface (SPMI) is a specification
> > > developed by the MIPI (Mobile Industry Process Interface) Alliance
> > > optimized for the real time control of Power Management ICs (PMIC).
> > > 
> > > SPMI is a two-wire serial interface that supports up to 4 master
> > > devices and up to 16 logical slaves.
> > > 
> > > The framework supports message APIs, multiple busses (1 controller
> > > per bus) and multiple clients/slave devices per controller.
> > > 
> > > Signed-off-by: Kenneth Heitke <kheitke@codeaurora.org>
> > > Signed-off-by: Michael Bohan <mbohan@codeaurora.org>
> > > Signed-off-by: Josh Cartwright <joshc@codeaurora.org>
> [..]
> > > +static int spmi_drv_probe(struct device *dev)
> > > +{
> > > +	const struct spmi_driver *sdrv = to_spmi_driver(dev->driver);
> > > +	int err = 0;
> > > +
> > > +	if (sdrv->probe)
> > > +		err = sdrv->probe(to_spmi_device(dev));
> > > +
> > > +	return err;
> > > +}
> > > +
> > > +static int spmi_drv_remove(struct device *dev)
> > > +{
> > > +	const struct spmi_driver *sdrv = to_spmi_driver(dev->driver);
> > > +	int err = 0;
> > > +
> > > +	if (sdrv->remove)
> > > +		err = sdrv->remove(to_spmi_device(dev));
> > > +
> > > +	return err;
> > > +}
> > > +
> > > +static void spmi_drv_shutdown(struct device *dev)
> > > +{
> > > +	const struct spmi_driver *sdrv = to_spmi_driver(dev->driver);
> > > +
> > > +	if (sdrv->shutdown)
> > 
> > If driver for device is not loaded this will cause kernel NULL
> > pointer dereference.
> 
> Indeed.  I'll fix this.
> 
> > > +static int of_spmi_register_devices(struct spmi_controller *ctrl)
> > > +{
> > > +	struct device_node *node;
> > > +	int err;
> > > +
> > > +	dev_dbg(&ctrl->dev, "of_spmi_register_devices\n");
> > > +
> > > +	if (!ctrl->dev.of_node)
> > > +		return -ENODEV;
> > > +
> > > +	dev_dbg(&ctrl->dev, "looping through children\n");
> > > +
> > > +	for_each_available_child_of_node(ctrl->dev.of_node, node) {
> > > +		struct spmi_device *sdev;
> > > +		u32 reg[2];
> > > +
> > > +		dev_dbg(&ctrl->dev, "adding child %s\n", node->full_name);
> > > +
> > > +		err = of_property_read_u32_array(node, "reg", reg, 2);
> > > +		if (err) {
> > > +			dev_err(&ctrl->dev,
> > > +				"node %s does not have 'reg' property\n",
> > > +				node->full_name);
> > > +			continue;
> > 
> > Shouldn't this be a fatal error?
> 
> Fatal in what way?  It is fatal in the sense that this particular child
> node is skipped, but other children can still be enumerated. 

Oh, I have missed this.

>  Are you
> suggesting that we bail completely when we hit a wrongly-described
> child?

Please ignore my comment.

> 
> > > +		}
> > > +
> > > +		if (reg[1] != SPMI_USID) {
> > > +			dev_err(&ctrl->dev,
> > > +				"node %s contains unsupported 'reg' entry\n",
> > > +				node->full_name);
> > > +			continue;
> > > +		}
> > > +
> > > +		if (reg[0] > 0xF) {
> > > +			dev_err(&ctrl->dev,
> > > +				"invalid usid on node %s\n",
> > > +				node->full_name);
> > > +			continue;
> > > +		}
> > > +
> > > +		dev_dbg(&ctrl->dev, "read usid %02x\n", reg[0]);
> > > +
> > > +		sdev = spmi_device_alloc(ctrl);
> > > +		if (!sdev)
> > > +			continue;
> > > +
> > > +		sdev->dev.of_node = node;
> > > +		sdev->usid = (u8) reg[0];
> > > +
> > > +		err = spmi_device_add(sdev);
> > > +		if (err) {
> > > +			dev_err(&sdev->dev,
> > > +				"failure adding device. status %d\n", err);
> > > +			spmi_device_put(sdev);
> > > +			continue;

There is no need from this 'continue' here.

> > > +		}
> > > +	}
> > > +
> > > +	return 0;
> > > +}
> > > +
> > > +int spmi_controller_add(struct spmi_controller *ctrl)
> > > +{
> > > +	int ret;
> > > +
> > > +	/* Can't register until after driver model init */
> > > +	if (WARN_ON(!spmi_bus_type.p))
> > > +		return -EAGAIN;
> > > +
> > > +	ret = device_add(&ctrl->dev);
> > > +	if (ret)
> > > +		return ret;
> > > +
> > > +	if (IS_ENABLED(CONFIG_OF))
> > > +		of_spmi_register_devices(ctrl);
> > 
> > Check for error code here?
> 
> And do what with it? 

This was related to my previous comment, which is not valid.

>  Maybe instead, I should make
> of_spmi_register_devices() return void.

Sound reasonable to me and will be the same as i2c bus.

Regards,
Ivan

> 

  reply	other threads:[~2013-10-29 18:00 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 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 [this message]
2013-10-29 15:21   ` Lars-Peter Clausen
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
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 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 03/10] spmi: add generic SPMI controller binding documentation 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=1383069623.14905.7.camel@localhost \
    --to=iivanov@mm-sol.com \
    --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).