From: Mark Brown <broonie@opensource.wolfsonmicro.com>
To: Sangbeom Kim <sbkim73@samsung.com>
Cc: lrg@ti.com, sameo@linux.intel.com, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v3 RESEND] regulator: Add S5M8767A regulator driver
Date: Thu, 29 Dec 2011 10:57:30 +0000 [thread overview]
Message-ID: <20111229105729.GF2909@opensource.wolfsonmicro.com> (raw)
In-Reply-To: <1325112925-9140-1-git-send-email-sbkim73@samsung.com>
On Thu, Dec 29, 2011 at 07:55:25AM +0900, Sangbeom Kim wrote:
> +static int s5m8767_get_voltage_sel(struct regulator_dev *rdev)
> +{
...
> + if (rdev->desc && rdev->desc->ops && rdev->desc->ops->list_voltage)
> + return rdev->desc->ops->list_voltage(rdev, val);
> +
> + return val;
> +}
This looks really strange - get_voltage_sel() should return a selector
but the return value of list_voltage() is a voltage.
> +static int s5m8767_reg_disable_suspend(struct regulator_dev *rdev)
> +{
> + struct s5m8767_info *s5m8767 = rdev_get_drvdata(rdev);
> + int ret, reg;
> + int mask = 0, pattern = 0;
> + int reg_id = s5m8767_get_reg_id(rdev);
> +
> + switch (reg_id) {
> + case S5M8767_LDO1 ... S5M8767_LDO28:
> + mask = 0xc0;
> + pattern = 0xc0;
> + break;
> + case S5M8767_BUCK1 ... S5M8767_BUCK9:
> + mask = 0xc0;
> + pattern = 0xc0;
> + break;
> + }
Looks like mask and pattern are always the same? Shouldn't this return
an error if reg_id is out of bounds?
> + ret = s5m8767_get_register(rdev, ®);
> + if (ret)
> + return ret;
> +
> + return s5m_reg_update(s5m8767->iodev, reg, ~pattern, mask);
The above looks like it's going to update the same registers as the
regular enable and disable which isn't right, this function is for
updating suspend mode configuration.
> +static int s5m8767_set_voltage_time_sel(struct regulator_dev *rdev,
> + unsigned int old_sel,
> + unsigned int new_sel)
> +{
> + s5m_reg_read(s5m8767->iodev, reg, &val);
> + val = val & mask;
> +
> + if (old_sel < new_sel)
> + return DIV_ROUND_UP(desc->step * (i - val),
> + s5m8767->ramp_delay);
> + else
> + return 0;
Why does this function need to read from the hardware? It's not
reading a ramp configuration from the hardware and the start and finish
selectors are both supplied as arguments.
> + size = sizeof(struct regulator_dev *) * S5M8767_REG_MAX;
> + s5m8767->rdev = kzalloc(size, GFP_KERNEL);
> + if (!s5m8767->rdev) {
> + kfree(s5m8767);
You shouldn't mix devm_ and regular functions.
> + return -ENOMEM;
> + }
Why not use devm_kzalloc() for this too?
> + s5m8767->num_regulators = pdata->num_regulators;
Just pass in fixed size arrays of regulator configurations - the core
can handle unconfigured regulators.
> + do {
> + ret = s5m_reg_read(s5m8767->iodev, reg, &val);
> + if (ret)
> + return ret;
> +
> + s5m_reg_update(s5m8767->iodev, reg,
> + ((val & 0x3f) | 0x40), 0xff);
> + reg++;
> + if ((reg == S5M8767_REG_LDO9CTRL) ||
> + (reg == S5M8767_REG_LDO11CTRL) ||
> + (reg == S5M8767_REG_LDO13CTRL) ||
> + (reg == S5M8767_REG_LDO17CTRL))
> + reg++;
> + } while (reg <= S5M8767_REG_LDO16CTRL);
What does this do?
> + if (s5m8767->buck2_ramp || s5m8767->buck3_ramp
> + || s5m8767->buck4_ramp) {
> + if (s5m8767->ramp_delay < 15)
> + s5m_reg_update(s5m8767->iodev, S5M8767_REG_DVSRAMP,
> + s5m8767->ramp_delay - 1, 0xf0);
> + else if (s5m8767->ramp_delay == 15)
> + s5m_reg_update(s5m8767->iodev, S5M8767_REG_DVSRAMP,
> + 0xc0, 0xf0);
> + else if (s5m8767->ramp_delay == 25)
> + s5m_reg_update(s5m8767->iodev, S5M8767_REG_DVSRAMP,
> + 0xd0, 0xf0);
> + else if (s5m8767->ramp_delay == 50)
> + s5m_reg_update(s5m8767->iodev, S5M8767_REG_DVSRAMP,
> + 0xe0, 0xf0);
> + else if (s5m8767->ramp_delay == 100)
> + s5m_reg_update(s5m8767->iodev, S5M8767_REG_DVSRAMP,
> + 0xf0, 0xf0);
> + else
> + s5m_reg_update(s5m8767->iodev, S5M8767_REG_DVSRAMP,
> + 0x90, 0xf0);
> + }
This looks like a switch statement.
next prev parent reply other threads:[~2011-12-29 10:57 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-12-28 22:55 [PATCH v3 RESEND] regulator: Add S5M8767A regulator driver Sangbeom Kim
2011-12-29 10:57 ` Mark Brown [this message]
2011-12-30 5:50 ` Sangbeom Kim
2011-12-30 10:37 ` Mark Brown
2012-01-02 1:30 ` Sangbeom Kim
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=20111229105729.GF2909@opensource.wolfsonmicro.com \
--to=broonie@opensource.wolfsonmicro.com \
--cc=linux-kernel@vger.kernel.org \
--cc=lrg@ti.com \
--cc=sameo@linux.intel.com \
--cc=sbkim73@samsung.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.