All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Ivan T. Ivanov" <iivanov@mm-sol.com>
To: Josh Cartwright <joshc@codeaurora.org>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	linux-arm-msm@vger.kernel.org,
	Gilad Avidov <gavidov@codeaurora.org>,
	linux-kernel@vger.kernel.org,
	Michael Bohan <mbohan@codeaurora.org>,
	Sagar Dharia <sdharia@codeaurora.org>,
	linux-arm-kernel@lists.infradead.org
Subject: Re: [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

> 

WARNING: multiple messages have this Message-ID (diff)
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: 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 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
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 [this message]
2013-10-29 18:00         ` Ivan T. Ivanov
2013-10-29 15:21   ` Lars-Peter Clausen
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 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 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

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=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.