public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Mark Brown <broonie@opensource.wolfsonmicro.com>
To: Pali Roh?r <pali.rohar@gmail.com>
Cc: linux-main <linux-kernel@vger.kernel.org>,
	linux-omap <linux-omap@vger.kernel.org>,
	Samuel Ortiz <sameo@linux.intel.com>,
	Aliaksei Katovich <aliaksei.katovich@nokia.com>,
	Vladimir Zapolskiy <vz@mleia.com>,
	Felipe Contreras <felipe.contreras@gmail.com>,
	Anton Vorontsov <cbouatmailru@gmail.com>,
	Joerg Reisenweber <joerg@openmoko.org>,
	Sebastian Reichel <sre@debian.org>,
	???????????? ???????????????? <freemangordon@abv.bg>
Subject: Re: RFC 2: bq2415x_charger driver
Date: Fri, 27 Jan 2012 16:24:55 +0000	[thread overview]
Message-ID: <20120127162455.GA18353@sirena.org.uk> (raw)
In-Reply-To: <3531484.T8K8kTguQQ@pali>

On Fri, Jan 27, 2012 at 03:40:43AM +0100, Pali Roh?r wrote:

> +static char *bq2415x_rev_name[] = {
> +	"1.0",
> +	"1.1",
> +	"1.2",
> +	"1.3",
> +	"1.4",
> +	"1.5",
> +	"1.6",
> +	"1.7",

Looks like you can just store this as a number?

> +struct bq2415x_device {
> +	struct device *dev;
> +	struct bq2415x_platform_data *platform_data;

You should take a copy of the platform data so it can be marked
initdata.

> +static DEFINE_MUTEX(bq2415x_id_mutex);
> +static DEFINE_MUTEX(bq2415x_timer_mutex);
> +static DEFINE_MUTEX(bq2415x_type_mutex);
> +static DEFINE_MUTEX(bq2415x_i2c_mutex);

Why are these global?

> +/* i2c read functions */
> +
> +static int bq2415x_i2c_read(struct bq2415x_device *bq, u8 reg)
> +{
> +	struct i2c_client *client = to_i2c_client(bq->dev);

You could save a bunch of code by moving all this I2C register I/O over
to regmap.

> +		case BQ2415X_BOOST_MODE_ENABLE:
> +			return bq2415x_i2c_write_bit(bq, BQ2415X_REG_CONTROL, 1, BQ2415X_BIT_OPA_MODE);

Keep things under 80 columns - see CodingStyle.

> +	if (client->addr == 0x6b) {

> +	} else if (client->addr == 0x6a) {

This looks like a switch statement.

> +	switch (chip) {
> +		case BQUNKNOWN:
> +			return bq2415x_rev_name[8];

Magic numbers ahoy...

> +static int bq2415x_vender_code(struct bq2415x_device *bq)
> +{
> +	int ret = bq2415x_exec_command(bq, BQ2415X_VENDER_CODE);
> +	if (ret < 0)
> +		return 0;
> +	else /* convert to binary */
> +		return (ret & 0x1) + ((ret >> 1) & 0x1) * 10 + ((ret >> 2) & 0x1) * 100;

Just print it as hex?

> +static int bq2415x_set_weak_battery_voltage(struct bq2415x_device *bq, int mV)
> +{
> +	int val = mV/100 + (mV%100 > 0 ? 1 : 0) - 34;

This could probably be written more clearly?

> +static int bq2415x_get_charge_current_sense_voltage(struct bq2415x_device *bq)
> +{
> +	/* TODO */
> +	return -ENOSYS;
> +}

Just don't provide things that aren't there, the frameworks should do
appropriate handling.

> +static enum power_supply_property bq2415x_power_supply_props[] = {
> +	/* TODO */
> +	POWER_SUPPLY_PROP_STATUS,
> +	POWER_SUPPLY_PROP_MODEL_NAME,

TODO?

> +static int bq2415x_power_supply_set_mode(struct bq2415x_device *bq, enum bq2415x_mode mode)
> +{
> +	int ret = 0;
> +
> +	switch (mode) {
> +
> +		case BQ2415X_MODE_NONE: /* N/A */

CodingStyle for the indentation.

> +			if (mode == BQ2415X_MODE_NONE) {
> +				dev_info(bq->dev, "mode: N/A\n");
> +				ret = bq2415x_set_current_limit(bq, 100);
> +			} else if (mode == BQ2415X_MODE_HOST_CHARGER) {
> +				dev_info(bq->dev, "mode: Host/HUB charger\n");
> +				ret = bq2415x_set_current_limit(bq, 500);
> +			} else {
> +				dev_info(bq->dev, "mode: Dedicated charger\n");
> +				ret = bq2415x_set_current_limit(bq, 1800);
> +			}

This should be a switch statement.

> +		case BQ2415X_MODE_BOOST: /* Boost mode */
> +			dev_info(bq->dev, "mode: Boost\n");

Is dev_info() really appropriate for this stuff?

> +			break;
> +
> +	}

No default case?

> +static void bq2415x_power_supply_set_charger_type(int type, void *data)

> +	if (type == 0)
> +		bq->charger_mode = BQ2415X_MODE_NONE;
> +	else if (type == 1)
> +		bq->charger_mode = BQ2415X_MODE_HOST_CHARGER;
> +	else if (type == 2)
> +		bq->charger_mode = BQ2415X_MODE_DEDICATED_CHARGER;
> +	else
> +		return;

Switch statement.  I never understood why this is such a common idiom...

> +		switch (error) {
> +			case 0: /* No error */
> +				break;
> +			case 6: /* Timer expired */
> +				dev_info(bq->dev, "Timer expired\n");
> +				break;

Should we really be logging this at anything more than dev_dbg()?

> +			case 7: /* N/A */
> +				bq2415x_power_supply_error(bq, "Unknow error");
> +				return;

Typo: unknown.

> +			case 5: /* Termal shutdown (too hot) */
> +				bq2415x_power_supply_error(bq, "Termal shutdown (too hot)");

Typo: thermal.

> +static int bq2415x_power_supply_get_property(struct power_supply *psy, enum power_supply_property psp, union power_supply_propval *val)

CodingStyle - wrapping (lots of this in the driver.

  reply	other threads:[~2012-01-27 16:25 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-12-05 22:35 [PATCH] mfd: add bq2415x charger driver Felipe Contreras
2011-12-05 22:51 ` Felipe Contreras
2011-12-05 23:05 ` Pali Rohár
2011-12-06  0:12   ` Felipe Contreras
2011-12-06  7:25     ` Pali Rohár
2011-12-06 10:58       ` Felipe Contreras
2011-12-06 13:27         ` Pali Rohár
2011-12-06 14:11           ` Felipe Contreras
2011-12-06 15:19             ` Pali Rohár
2011-12-06 11:25       ` Mark Brown
2011-12-06  2:17 ` Sebastian Reichel
2011-12-06  2:49   ` Felipe Contreras
2011-12-06 13:21     ` Sebastian Reichel
2011-12-06 13:50       ` Felipe Contreras
2011-12-06 13:34     ` Pali Rohár
2011-12-06 11:31 ` Mark Brown
2011-12-06 11:43   ` Felipe Contreras
2011-12-06 11:46     ` Mark Brown
2011-12-07 21:03 ` RFC: bq2415x_charger driver Pali Rohár
2011-12-07 21:25   ` Vladimir Zapolskiy
2011-12-07 21:40     ` Pali Rohár
2012-01-27  2:40   ` RFC 2: " Pali Rohár
2012-01-27 16:24     ` Mark Brown [this message]
2012-01-27 18:33       ` Pali Rohár
2012-01-27 19:22         ` Mark Brown
2012-01-27 20:40     ` Sebastian Reichel

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=20120127162455.GA18353@sirena.org.uk \
    --to=broonie@opensource.wolfsonmicro.com \
    --cc=aliaksei.katovich@nokia.com \
    --cc=cbouatmailru@gmail.com \
    --cc=felipe.contreras@gmail.com \
    --cc=freemangordon@abv.bg \
    --cc=joerg@openmoko.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-omap@vger.kernel.org \
    --cc=pali.rohar@gmail.com \
    --cc=sameo@linux.intel.com \
    --cc=sre@debian.org \
    --cc=vz@mleia.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox