All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mark Brown <broonie@opensource.wolfsonmicro.com>
To: Joe Perches <joe@perches.com>
Cc: "alsa-devel@alsa-project.org" <alsa-devel@alsa-project.org>,
	Takashi Iwai <tiwai@suse.de>,
	Peter Ujfalusi <peter.ujfalusi@nokia.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Peter Hsiang <Peter.Hsiang@maxim-ic.com>,
	Jesse Marroquin <Jesse.Marroquin@maxim-ic.com>,
	Liam Girdwood <lrg@slimlogic.co.uk>
Subject: Re: [PATCH] sound/soc: rename vol to volatile_register as appropriate
Date: Wed, 13 Oct 2010 13:33:01 +0100	[thread overview]
Message-ID: <20101013123301.GL6424@rakim.wolfsonmicro.main> (raw)
In-Reply-To: <1286971846.1117.191.camel@Joe-Laptop>

On Wed, Oct 13, 2010 at 05:10:45AM -0700, Joe Perches wrote:
> Rename the declaration and uses of variables
> named vol to volatile_register to avoid name
> clash with the much more common use of vol
> for volume.

Are any of the contexts actually ambiguous?  I have to say I don't find
this useful.  If the register I/O code knows anything about volumes I'd
say we've probably messed up somewhere.

> > > static struct {
> > > 	bool readable;
> > > 	bool writable,
> > > 	bool vol;
> > > } etc...

> > The readable and writable fields are being used as bitmasks:

> No, they are being declared as bitmasks.
> writable is used once as bool, readable isn't used at all.

They're being used in the table initialisation.

> > | +       { 0x1F, 0x1F, 1 }, /* 03 battery voltage */

> > so this discards data which we may wish to use in future.

> It's not used as bitmask now, what use would there
> be in the future for it as a bitmask?

Examples would include validating I/O operations done by drivers, or
supporting fancy cache handling that pays attention to things per bit.

> > vol is traditionally used for this throughout the subsystem.  It's
> > unfortuante that volatile is a keyword.

> As far as I see, your description of vol being
> used throughout the subsystem is not true.

I'm sorry?  It's used as the field name for volatility in all the
drivers I can remember that use a table to look volatility up in
register properties.

WARNING: multiple messages have this Message-ID (diff)
From: Mark Brown <broonie@opensource.wolfsonmicro.com>
To: Joe Perches <joe@perches.com>
Cc: Peter Hsiang <Peter.Hsiang@maxim-ic.com>,
	Jaroslav Kysela <perex@perex.cz>, Takashi Iwai <tiwai@suse.de>,
	Liam Girdwood <lrg@slimlogic.co.uk>,
	Peter Ujfalusi <peter.ujfalusi@nokia.com>,
	"alsa-devel@alsa-project.org" <alsa-devel@alsa-project.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Jesse Marroquin <Jesse.Marroquin@maxim-ic.com>
Subject: Re: [PATCH] sound/soc: rename vol to volatile_register as appropriate
Date: Wed, 13 Oct 2010 13:33:01 +0100	[thread overview]
Message-ID: <20101013123301.GL6424@rakim.wolfsonmicro.main> (raw)
In-Reply-To: <1286971846.1117.191.camel@Joe-Laptop>

On Wed, Oct 13, 2010 at 05:10:45AM -0700, Joe Perches wrote:
> Rename the declaration and uses of variables
> named vol to volatile_register to avoid name
> clash with the much more common use of vol
> for volume.

Are any of the contexts actually ambiguous?  I have to say I don't find
this useful.  If the register I/O code knows anything about volumes I'd
say we've probably messed up somewhere.

> > > static struct {
> > > 	bool readable;
> > > 	bool writable,
> > > 	bool vol;
> > > } etc...

> > The readable and writable fields are being used as bitmasks:

> No, they are being declared as bitmasks.
> writable is used once as bool, readable isn't used at all.

They're being used in the table initialisation.

> > | +       { 0x1F, 0x1F, 1 }, /* 03 battery voltage */

> > so this discards data which we may wish to use in future.

> It's not used as bitmask now, what use would there
> be in the future for it as a bitmask?

Examples would include validating I/O operations done by drivers, or
supporting fancy cache handling that pays attention to things per bit.

> > vol is traditionally used for this throughout the subsystem.  It's
> > unfortuante that volatile is a keyword.

> As far as I see, your description of vol being
> used throughout the subsystem is not true.

I'm sorry?  It's used as the field name for volatility in all the
drivers I can remember that use a table to look volatility up in
register properties.

  reply	other threads:[~2010-10-13 12:33 UTC|newest]

Thread overview: 62+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-09-29  2:34 [PATCH] ASoC: Add max98088 CODEC driver Peter Hsiang
2010-09-29  2:34 ` Peter Hsiang
2010-09-29  3:37 ` Mark Brown
2010-09-29  3:37   ` Mark Brown
2010-09-29 21:42   ` Peter Hsiang
2010-09-29 21:42     ` Peter Hsiang
2010-09-29 22:18     ` Mark Brown
2010-09-29 22:18       ` Mark Brown
2010-09-30  0:52       ` Peter Hsiang
2010-09-30  0:58         ` Mark Brown
2010-09-30  0:58           ` Mark Brown
2010-09-30  1:20           ` Peter Hsiang
2010-09-30 17:23           ` user space control app driver interface for sound soc Peter Hsiang
2010-09-30 20:31             ` Mark Brown
2010-09-30 21:55               ` Peter Hsiang
2010-09-30 22:09                 ` Mark Brown
2010-09-30 23:10                   ` Peter Hsiang
2010-09-30 23:34                     ` Mark Brown
2010-10-01  1:56                       ` Peter Hsiang
2010-10-01  2:37                         ` Mark Brown
2010-10-01  6:56                           ` Clemens Ladisch
2010-10-01  7:12                             ` Mark Brown
2010-10-01 13:42                               ` Takashi Iwai
2010-10-01 17:35                                 ` Mark Brown
2010-10-01 21:57                                 ` Peter Hsiang
2010-10-03  9:09                                   ` Takashi Iwai
2010-10-13  1:20 ` [PATCH] ASoC: Add max98088 CODEC driver Peter Hsiang
2010-10-13  1:47   ` Joe Perches
2010-10-13  8:24     ` Mark Brown
2010-10-13  8:24       ` Mark Brown
2010-10-13 12:10       ` [PATCH] sound/soc: rename vol to volatile_register as appropriate Joe Perches
2010-10-13 12:33         ` Mark Brown [this message]
2010-10-13 12:33           ` Mark Brown
2010-10-13 12:55           ` Joe Perches
2010-10-13 15:11             ` Mark Brown
2010-10-13 15:11               ` Mark Brown
2010-10-13 15:27               ` Joe Perches
2010-10-13 15:29                 ` Mark Brown
2010-10-13 15:29                   ` Mark Brown
2010-10-13 15:35                   ` Joe Perches
2010-10-13 19:10                   ` [RFC PATCH] sound/soc/codecs/wm8962.c: Use register index, save 100kb text Joe Perches
2010-10-13 19:40                     ` Mark Brown
2010-10-13 19:40                       ` Mark Brown
2010-10-13 20:06                       ` Joe Perches
2010-10-13 20:29                         ` Mark Brown
2010-10-13 20:29                           ` Mark Brown
2010-10-13 15:19           ` [PATCH] sound/soc/codecs/wm8994.c: Remove unused vol Joe Perches
2010-10-15 10:08             ` Liam Girdwood
2010-10-15 10:08               ` Liam Girdwood
2010-10-15 10:39             ` Mark Brown
2010-10-15 10:39               ` Mark Brown
2010-10-13 10:32   ` [PATCH] ASoC: Add max98088 CODEC driver Mark Brown
2010-10-13 10:32     ` Mark Brown
2010-10-14  3:18     ` Peter Hsiang
2010-10-14  3:18       ` Peter Hsiang
2010-10-14  3:30   ` Peter Hsiang
2010-10-15 10:04     ` Liam Girdwood
2010-10-15 10:04       ` Liam Girdwood
2010-10-15 10:55     ` Mark Brown
2010-10-15 10:55       ` Mark Brown
2010-10-15 17:23       ` Peter Hsiang
2010-10-15 17:23         ` Peter Hsiang

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=20101013123301.GL6424@rakim.wolfsonmicro.main \
    --to=broonie@opensource.wolfsonmicro.com \
    --cc=Jesse.Marroquin@maxim-ic.com \
    --cc=Peter.Hsiang@maxim-ic.com \
    --cc=alsa-devel@alsa-project.org \
    --cc=joe@perches.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=lrg@slimlogic.co.uk \
    --cc=peter.ujfalusi@nokia.com \
    --cc=tiwai@suse.de \
    /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.