From: broonie@opensource.wolfsonmicro.com (Mark Brown)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 2/2] regulator: Add Freescale's MC34708 regulators
Date: Fri, 20 Apr 2012 12:42:01 +0100 [thread overview]
Message-ID: <20120420114201.GA3259@opensource.wolfsonmicro.com> (raw)
In-Reply-To: <1334853521-23792-2-git-send-email-paul.liu@linaro.org>
On Fri, Apr 20, 2012 at 12:38:41AM +0800, Ying-Chun Liu (PaulLiu) wrote:
> +static const int mc34708_sw1A[] = {
> + 650000, 662500, 675000, 687500, 700000, 712500,
Replace these by direct calculations, using tables is both less
efficient and less clear.
> + mc34708_lock(priv->mc34708);
> + ret = mc34708_reg_rmw(priv->mc34708, mc34708_regulators[id].reg,
> + mc34708_regulators[id].enable_bit,
> + mc34708_regulators[id].enable_bit);
> + mc34708_unlock(priv->mc34708);
Having to open code this locking in every single driver is a bit
painful; just have the default register I/O operations do the locking
and introduce additional unlocked versions if needed.
All this stuff could be factored out if you were using regmap.
> +EXPORT_SYMBOL_GPL(mc34708_regulator_list_voltage);
No, this stuff should only be accessed via the ops. Why are you doing
this?
> +int
> +mc34708_get_best_voltage_index(struct regulator_dev *rdev,
> + int min_uV, int max_uV)
> +{
You're reimplementing core functionality here, or it'd be even better to
use calculations.
> +static int mc34708_regulator_get_voltage(struct regulator_dev *rdev)
> +{
Why is this not get_voltage_sel?
> +static struct regulator_ops mc34708_regulator_ops = {
> + .enable = mc34708_regulator_enable,
> + .disable = mc34708_regulator_disable,
> + .is_enabled = mc34708_regulator_is_enabled,
> + .list_voltage = mc34708_regulator_list_voltage,
> + .set_voltage = mc34708_regulator_set_voltage,
> + .get_voltage = mc34708_regulator_get_voltage,
> +};
> +EXPORT_SYMBOL_GPL(mc34708_regulator_ops);
No. What are you doing this for?
> +int
> +mc34708_fixed_regulator_set_voltage(struct regulator_dev *rdev, int min_uV,
> + int max_uV, unsigned *selector)
This function makes no sense...
> +int mc34708_sw_regulator_is_enabled(struct regulator_dev *rdev)
> +{
> + return 1;
> +}
Why are you doing this - this function is redundant.
> + ret = mc34708_reg_rmw(mc34708, MC34708_SW12OP,
> + MC34708_SW12OP_SW1AMODE_M |
> + MC34708_SW12OP_SW2MODE_M,
> + MC34708_SW12OP_SW1AMODE_VALUE |
> + MC34708_SW12OP_SW2MODE_VALUE);
> + if (ret)
> + goto err_free;
> +
> + ret = mc34708_reg_rmw(mc34708, MC34708_SW345OP,
> + MC34708_SW345OP_SW3MODE_M |
> + MC34708_SW345OP_SW4AMODE_M |
> + MC34708_SW345OP_SW4BMODE_M |
> + MC34708_SW345OP_SW5MODE_M,
> + MC34708_SW345OP_SW3MODE_VALUE |
> + MC34708_SW345OP_SW4AMODE_VALUE |
> + MC34708_SW345OP_SW4BMODE_VALUE |
> + MC34708_SW345OP_SW5MODE_VALUE);
> + if (ret)
> + goto err_free;
If this needs to be done unconditionally shouldn't it be being donei in
the MFD core driver?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20120420/5db8aecc/attachment-0001.sig>
WARNING: multiple messages have this Message-ID (diff)
From: Mark Brown <broonie@opensource.wolfsonmicro.com>
To: "Ying-Chun Liu (PaulLiu)" <paul.liu@linaro.org>
Cc: linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, linaro-dev@lists.linaro.org,
patches@linaro.org, Robin Gong <B38343@freescale.com>,
Liam Girdwood <lrg@ti.com>, Samuel Ortiz <sameo@linux.intel.com>,
Shawn Guo <shawn.guo@linaro.org>
Subject: Re: [PATCH 2/2] regulator: Add Freescale's MC34708 regulators
Date: Fri, 20 Apr 2012 12:42:01 +0100 [thread overview]
Message-ID: <20120420114201.GA3259@opensource.wolfsonmicro.com> (raw)
In-Reply-To: <1334853521-23792-2-git-send-email-paul.liu@linaro.org>
[-- Attachment #1: Type: text/plain, Size: 2699 bytes --]
On Fri, Apr 20, 2012 at 12:38:41AM +0800, Ying-Chun Liu (PaulLiu) wrote:
> +static const int mc34708_sw1A[] = {
> + 650000, 662500, 675000, 687500, 700000, 712500,
Replace these by direct calculations, using tables is both less
efficient and less clear.
> + mc34708_lock(priv->mc34708);
> + ret = mc34708_reg_rmw(priv->mc34708, mc34708_regulators[id].reg,
> + mc34708_regulators[id].enable_bit,
> + mc34708_regulators[id].enable_bit);
> + mc34708_unlock(priv->mc34708);
Having to open code this locking in every single driver is a bit
painful; just have the default register I/O operations do the locking
and introduce additional unlocked versions if needed.
All this stuff could be factored out if you were using regmap.
> +EXPORT_SYMBOL_GPL(mc34708_regulator_list_voltage);
No, this stuff should only be accessed via the ops. Why are you doing
this?
> +int
> +mc34708_get_best_voltage_index(struct regulator_dev *rdev,
> + int min_uV, int max_uV)
> +{
You're reimplementing core functionality here, or it'd be even better to
use calculations.
> +static int mc34708_regulator_get_voltage(struct regulator_dev *rdev)
> +{
Why is this not get_voltage_sel?
> +static struct regulator_ops mc34708_regulator_ops = {
> + .enable = mc34708_regulator_enable,
> + .disable = mc34708_regulator_disable,
> + .is_enabled = mc34708_regulator_is_enabled,
> + .list_voltage = mc34708_regulator_list_voltage,
> + .set_voltage = mc34708_regulator_set_voltage,
> + .get_voltage = mc34708_regulator_get_voltage,
> +};
> +EXPORT_SYMBOL_GPL(mc34708_regulator_ops);
No. What are you doing this for?
> +int
> +mc34708_fixed_regulator_set_voltage(struct regulator_dev *rdev, int min_uV,
> + int max_uV, unsigned *selector)
This function makes no sense...
> +int mc34708_sw_regulator_is_enabled(struct regulator_dev *rdev)
> +{
> + return 1;
> +}
Why are you doing this - this function is redundant.
> + ret = mc34708_reg_rmw(mc34708, MC34708_SW12OP,
> + MC34708_SW12OP_SW1AMODE_M |
> + MC34708_SW12OP_SW2MODE_M,
> + MC34708_SW12OP_SW1AMODE_VALUE |
> + MC34708_SW12OP_SW2MODE_VALUE);
> + if (ret)
> + goto err_free;
> +
> + ret = mc34708_reg_rmw(mc34708, MC34708_SW345OP,
> + MC34708_SW345OP_SW3MODE_M |
> + MC34708_SW345OP_SW4AMODE_M |
> + MC34708_SW345OP_SW4BMODE_M |
> + MC34708_SW345OP_SW5MODE_M,
> + MC34708_SW345OP_SW3MODE_VALUE |
> + MC34708_SW345OP_SW4AMODE_VALUE |
> + MC34708_SW345OP_SW4BMODE_VALUE |
> + MC34708_SW345OP_SW5MODE_VALUE);
> + if (ret)
> + goto err_free;
If this needs to be done unconditionally shouldn't it be being donei in
the MFD core driver?
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
next prev parent reply other threads:[~2012-04-20 11:42 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-04-19 16:38 [PATCH 1/2] mfd: Add Freescale's PMIC MC34708 support Ying-Chun Liu (PaulLiu)
2012-04-19 16:38 ` Ying-Chun Liu (PaulLiu)
2012-04-19 16:38 ` [PATCH 2/2] regulator: Add Freescale's MC34708 regulators Ying-Chun Liu (PaulLiu)
2012-04-19 16:38 ` Ying-Chun Liu (PaulLiu)
2012-04-20 11:42 ` Mark Brown [this message]
2012-04-20 11:42 ` Mark Brown
2012-04-20 6:35 ` [PATCH 1/2] mfd: Add Freescale's PMIC MC34708 support Lothar Waßmann
2012-04-20 6:35 ` Lothar Waßmann
2012-04-20 7:40 ` Robert Schwebel
2012-04-20 7:40 ` Robert Schwebel
2012-04-20 9:20 ` Mark Brown
2012-04-20 9:20 ` Mark Brown
2012-04-22 23:32 ` Marc Reilly
2012-04-22 23:32 ` Marc Reilly
2012-07-04 7:37 ` Uwe Kleine-König
2012-07-04 7:37 ` Uwe Kleine-König
2012-07-04 13:44 ` Shawn Guo
2012-07-04 13:44 ` Shawn Guo
2012-07-05 5:48 ` Ying-Chun Liu (PaulLiu)
2012-07-05 5:48 ` Ying-Chun Liu (PaulLiu)
2012-07-05 6:46 ` Ying-Chun Liu (PaulLiu)
2012-07-05 6:46 ` Ying-Chun Liu (PaulLiu)
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=20120420114201.GA3259@opensource.wolfsonmicro.com \
--to=broonie@opensource.wolfsonmicro.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 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.