All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ashish Jangam <ashish.jangam@kpitcummins.com>
To: Mark Brown <broonie@opensource.wolfsonmicro.com>
Cc: Liam Girdwood <lrg@ti.com>, Samuel Ortiz <sameo@linux.intel.com>,
	David Dajun Chen <dchen@diasemi.com>,
	<linux-kernel@vger.kernel.org>
Subject: Re: [Patch v3 2/7] Regulator: DA9055 Regulator driver
Date: Mon, 29 Oct 2012 17:37:58 +0530	[thread overview]
Message-ID: <1351512478.17695.14.camel@dhruva> (raw)
In-Reply-To: <20121027215850.GI4564@opensource.wolfsonmicro.com>

On Sat, 2012-10-27 at 22:59 +0100, Mark Brown wrote:
> On Thu, Oct 11, 2012 at 03:39:24PM +0530, Ashish Jangam wrote:
> 
> > This is the Regulator patch for the DA9055 PMIC and has got dependency on
> > the DA9055 MFD core.
> 
> Always submit patches with subject lines appropriate for the subsystem,
> this helps get your patch noticed.  People do things like search their
> mailboxes for subsystem prefixes when looking for things they need to
> review.
In subject line apart from "regulator" I will introduce "next" too. 
> 
> > This patch support all of the DA9055 regulators. The output voltages are
> > fully programmable through I2C interface only. The platform data with regulation
> > constraints is passed down from the board to the regulator.
> > 
> > +	switch (mode) {
> > +	case REGULATOR_MODE_FAST:
> > +		val = DA9055_BUCK_MODE_SYNC << info->mode.shift;
> > +		break;
> > +	case REGULATOR_MODE_NORMAL:
> > +		val = DA9055_BUCK_MODE_AUTO << info->mode.shift;
> > +		break;
> > +	case REGULATOR_MODE_IDLE:
> > +	case REGULATOR_MODE_STANDBY:
> > +		val = DA9055_BUCK_MODE_SLEEP << info->mode.shift;
> > +		break;
> 
> _IDLE and _STANDBY should have different effects if they're both
> implemented; pick one.  From the rest of the code it looks like it
> should be _STANDBY.
Yes, _STANDBY should be picked only.  
> 
> > +	switch (mode) {
> > +	case REGULATOR_MODE_NORMAL:
> > +	case REGULATOR_MODE_FAST:
> > +		val = DA9055_LDO_MODE_SYNC;
> > +		break;
> > +	case REGULATOR_MODE_IDLE:
> > +	case REGULATOR_MODE_STANDBY:
> > +		val = DA9055_LDO_MODE_SLEEP;
> > +	}
> 
> Similarly here.  You're also missing a break;
Ok, will fix this.
> 
> > +	/* Get the voltage for the activer register set A/B */
> > +	if (ret == DA9055_REGUALTOR_SET_A)
> > +		ret = da9055_reg_read(regulator->da9055, volt.reg_a);
> > +	else
> > +		ret = da9055_reg_read(regulator->da9055, volt.reg_b);
> > +
> > +	if (ret < 0)
> > +		return ret;
> > +
> > +	sel = ((ret & volt.v_mask) - volt.v_offset);
> 
> Why not just use the register values directly and refuse to write ones
> That are too low?  This would simplify things a little as you'd only
> need to check 
If I understood it correctly, v_offset should be used to check register
values as seen in the below sample code snippet
sel = ret & mask;
if (sel <= v_offset)
	return 0;
else
	return sel
> 
> > +	/* Set the voltage */
> > +	if (ret == DA9055_REGUALTOR_SET_A)
> > +		return da9055_regulator_set_voltage_bits(rdev, info->volt.reg_a,
> > +							 selector);
> > +
> > +	return da9055_regulator_set_voltage_bits(rdev, info->volt.reg_b,
> > +						 selector);
> 
> This is confusingly written - it should be either a switch or an if/else
> really.
if/else seems to be sensible here.
> 
> > +	/* Select register set B for suspend voltage ramping. */
> > +	ret = da9055_reg_update(regulator->da9055, info->conf.reg,
> > +				info->conf.sel_mask, DA9055_SEL_REG_B);
> > +	if (ret < 0)
> > +		return ret;
> 
> This doesn't seem like it plays nicely with the GPIO selection in normal
> set_voltage() - does it need to check to see if register set B might be
> used in normal operation and refuse to run if it could?
Thanks for catching this. Need to add condition to check if GPIO is
selected. 
> 
> > +	for (i = 0; i < ARRAY_SIZE(da9055_regulator_info); i++) {
> > +		info = &da9055_regulator_info[i];
> > +		if (info->reg_desc.id == id)
> > +			return info;
> > +		}
> > +
> 
> The indentation here is *very* messed up.  I'd suggest not omitting any
> braces.
Ok, will fix indentation and put braces around if condition.



  reply	other threads:[~2012-10-29 12:08 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-10-11 10:09 [Patch v3 2/7] Regulator: DA9055 Regulator driver Ashish Jangam
2012-10-23 10:02 ` Ashish Jangam
2012-10-23 11:05   ` Mark Brown
2012-10-27 21:59 ` Mark Brown
2012-10-29 12:07   ` Ashish Jangam [this message]
2012-10-29 14:52     ` Mark Brown
  -- strict thread matches above, loose matches on Subject: below --
2012-10-11  6:36 Ashish Jangam
2012-10-11 10:02 ` Ashish Jangam

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=1351512478.17695.14.camel@dhruva \
    --to=ashish.jangam@kpitcummins.com \
    --cc=broonie@opensource.wolfsonmicro.com \
    --cc=dchen@diasemi.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=lrg@ti.com \
    --cc=sameo@linux.intel.com \
    /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.