All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andrew Morton <akpm@linux-foundation.org>
To: Mark Brown <broonie@opensource.wolfsonmicro.com>
Cc: Liam Girdwood <lrg@slimlogic.co.uk>,
	Samuel Ortiz <sameo@openedhand.com>,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH 1/2] mfd: Core support for the WM8400 AudioPlus HiFi CODEC and PMU
Date: Wed, 17 Sep 2008 19:28:36 -0700	[thread overview]
Message-ID: <20080917192836.ef3545d2.akpm@linux-foundation.org> (raw)
In-Reply-To: <1221558194-15505-1-git-send-email-broonie@opensource.wolfsonmicro.com>

On Tue, 16 Sep 2008 10:43:13 +0100 Mark Brown <broonie@opensource.wolfsonmicro.com> wrote:

> The WM8400 is a highly integrated audio CODEC and power management unit
> optimised for use in mobile multimedia applications.  This patch adds
> core support for the WM8400 to the MFD subsystem.
> 
> Both I2C and SPI access are supported by the hardware but currently only
> I2C access is implemented.  The code is structured to allow SPI support
> to be slotted in later.
> 

Various ankle-biting comments, just to show I read it:

>
> ...
>
> +#include <linux/bug.h>
> +#include <linux/i2c.h>
> +#include <linux/kernel.h>
> +#include <linux/mfd/wm8400-private.h>
> +#include <linux/mfd/wm8400-audio.h>
> +
> +static struct
> +{

hm, checkpatch chews a couple minutes CPU time then misses this error.

static struct {

please.

> +	u16  readable;    /* Mask of readable bits */
> +	u16  writable;    /* Mask of writable bits */
> +	u16  vol;         /* Mask of volatile bits */
> +	int  is_codec;    /* Register controlled by codec reset */
> +	u16  default_val; /* Value on reset */
> +} reg_data[] =
> +{

} reg_data[] = {

would be conventional, too.

> +	{ 0xFFFF, 0xFFFF, 0x0000, 0, 0x6172 }, /* R0 */
> +	{ 0x7000, 0x0000, 0x8000, 0, 0x0000 }, /* R1 */
> +	{ 0xFF17, 0xFF17, 0x0000, 0, 0x0000 }, /* R2 */
> +	{ 0xEBF3, 0xEBF3, 0x0000, 1, 0x6000 }, /* R3 */
> +	{ 0x3CF3, 0x3CF3, 0x0000, 1, 0x0000 }, /* R4  */
>
> ...
>
> +/**
> + * wm8400_reg_read - Single register read
> + *
> + * @wm8400: Pointer to wm8400 control structure
> + * @reg:    Register to read
> + *
> + * @return  Read value
> + */
> +u16 wm8400_reg_read(struct wm8400 *wm8400, u8 reg)
> +{
> +	u16 val;
> +
> +	mutex_lock(&wm8400->io_lock);
> +
> +	wm8400_read(wm8400, reg, 1, &val);
> +
> +	mutex_unlock(&wm8400->io_lock);
> +
> +	return val;
> +}
> +EXPORT_SYMBOL_GPL(wm8400_reg_read);

Is it just me, or do all the useless newlines there look silly?  sigh.

> +int wm8400_block_read(struct wm8400 *wm8400, u8 reg, int count, u16 *data)
> +{
> +	int ret;
> +
> +	mutex_lock(&wm8400->io_lock);
> +
> +	ret = wm8400_read(wm8400, reg, count, data);
> +
> +	mutex_unlock(&wm8400->io_lock);
> +
> +	return ret;
> +}
> +EXPORT_SYMBOL_GPL(wm8400_block_read);
> +
>
> ...
>
> +static void wm8400_release(struct wm8400 *wm8400)
> +{
> +	int i;
> +
> +	for (i = 0; i < ARRAY_SIZE(wm8400->regulators); i++)
> +		if (wm8400->regulators[i].name)
> +			platform_device_unregister(&wm8400->regulators[i]);
> +}
> +
> +#if defined(CONFIG_I2C) || defined(CONFIG_I2C_MODULE)

Is CONFIG_I2C=n worth supporting?  Is anyone likely to test and
maintain that combination?

> +static int wm8400_i2c_read(void *io_data, char reg, int count, u16 *dest)
> +{
> +	struct i2c_client *i2c = io_data;
> +	struct i2c_msg xfer[2];
> +	int ret;
> +
> +	/* Write register */
> +	xfer[0].addr = i2c->addr;
> +	xfer[0].flags = 0;
> +	xfer[0].len = 1;
> +	xfer[0].buf = &reg;
> +
> +	/* Read data */
> +	xfer[1].addr = i2c->addr;
> +	xfer[1].flags = I2C_M_RD;
> +	xfer[1].len = count * sizeof(u16);
> +	xfer[1].buf = (u8 *)dest;
> +
> +	ret = i2c_transfer(i2c->adapter, xfer, 2);
> +	if (ret == 2)
> +		ret = 0;
> +	else if (ret >= 0)
> +		ret = -EIO;
> +
> +	return ret;
> +}
> +
> +static int wm8400_i2c_write(void *io_data, char reg, int count, const u16 *src)
> +{
> +	struct i2c_client *i2c = io_data;
> +	u8 *msg;
> +	int ret;
> +
> +	/* We add 1 byte for device register - ideally I2C would gather. */
> +	msg = kmalloc((count * sizeof(u16)) + 1, GFP_KERNEL);
> +	if (msg == NULL)
> +		return -ENOMEM;
> +
> +	msg[0] = reg;
> +	memcpy(&msg[1], src, count * sizeof(u16));
> +
> +	ret = i2c_master_send(i2c, msg, (count * sizeof(u16)) + 1);
> +
> +	if (ret == (count * 2) + 1)
> +		ret = 0;
> +	else if (ret >= 0)
> +		ret = -EIO;
> +
> +	kfree(msg);
> +
> +	return ret;
> +}

Always freaks me out to see read/write methods returning `int' instead
of `ssize_t'.  i2c weirdness, iirc.

>
> ...
>
> +struct wm8400 {
> +	struct device *dev;
> +
> +	int (*read_dev)(void *data, char reg, int count, u16 *dst);
> +	int (*write_dev)(void *data, char reg, int count, const u16 *src);
> +
> +	struct mutex io_lock;
> +	void *io_data;
> +
> +	u16 reg_cache[WM8400_REGISTER_COUNT];

Should this be __be16?

> +	struct platform_device regulators[6];
> +};
> +
>
> ...
>
> +#define WM8400_LINE_CMP_VTHD_MASK               0x000F  /* LINE_CMP_VTHD - [3:0] */
> +#define WM8400_LINE_CMP_VTHD_SHIFT                   0  /* LINE_CMP_VTHD - [3:0] */
> +#define WM8400_LINE_CMP_VTHD_WIDTH                   4  /* LINE_CMP_VTHD - [3:0] */
> +

This patch adds an amazing 1733 #defines, of which only a few
percent are used.  Oh well.


  parent reply	other threads:[~2008-09-18  2:29 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-09-16  9:42 [PATCH 0/2] WM8400 support v2 Mark Brown
2008-09-16  9:43 ` [PATCH 1/2] mfd: Core support for the WM8400 AudioPlus HiFi CODEC and PMU Mark Brown
2008-09-16  9:43   ` [PATCH 2/2] regulator: Add WM8400 regulator support Mark Brown
2008-09-18  2:28   ` Andrew Morton [this message]
2008-09-18 10:29     ` [PATCH 1/2] mfd: Core support for the WM8400 AudioPlus HiFi CODEC and PMU Mark Brown
2008-09-22 18:33   ` Samuel Ortiz
2008-09-23  0:27     ` Liam Girdwood
  -- strict thread matches above, loose matches on Subject: below --
2008-09-10 18:28 [PATCH 0/2] WM8400 support Mark Brown
2008-09-10 18:28 ` [PATCH 1/2] mfd: Core support for the WM8400 AudioPlus HiFi CODEC and PMU Mark Brown
2008-09-10 18:47   ` Liam Girdwood
2008-09-10 19:13     ` Mark Brown
2008-09-10 19:38       ` Liam Girdwood
2008-09-11 10:02         ` Mark Brown
2008-09-12 10:54   ` Samuel Ortiz
2008-09-12 12:05     ` Mark Brown

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=20080917192836.ef3545d2.akpm@linux-foundation.org \
    --to=akpm@linux-foundation.org \
    --cc=broonie@opensource.wolfsonmicro.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=lrg@slimlogic.co.uk \
    --cc=sameo@openedhand.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.