[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20101013151117.GM6424@rakim.wolfsonmicro.main>
Date: Wed, 13 Oct 2010 16:11:20 +0100
From: Mark Brown <broonie@...nsource.wolfsonmicro.com>
To: Joe Perches <joe@...ches.com>
Cc: Peter Hsiang <Peter.Hsiang@...im-ic.com>,
Jaroslav Kysela <perex@...ex.cz>, Takashi Iwai <tiwai@...e.de>,
Liam Girdwood <lrg@...mlogic.co.uk>,
Peter Ujfalusi <peter.ujfalusi@...ia.com>,
"alsa-devel@...a-project.org" <alsa-devel@...a-project.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
Jesse Marroquin <Jesse.Marroquin@...im-ic.com>
Subject: Re: [PATCH] sound/soc: rename vol to volatile_register as
appropriate
On Wed, Oct 13, 2010 at 05:55:48AM -0700, Joe Perches wrote:
> On Wed, 2010-10-13 at 13:33 +0100, Mark Brown wrote:
> > 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.
> Looking at the 2 register access routines where
> volatile_register/vol is used, I'd say those
> routines aren't useful at all and the checks
> should be inline instead.
If you check the code again you will notice that these functons are all
used in ops structures which presents obvious issues when trying to
replace with open coded checks. If we remove these functions then the
core won't be able to tell if it should read registers from the hardware
or from the cache.
> This sort of wrapper routine doesn't serve
> much of a purpose to me:
> static int wm8904_volatile_register(unsigned int reg)
I hope their usefulness is clear given the above.
> > 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.
> I did a grep for vol in sound, I found the uses
> where it was for volatile and patched them.
> Are there others? Perhaps, but I don't think so.
> Probably not in sound. Was there some other
> subsystem you meant? Maybe you have examples
> I missed?
You're missing the "for this" here, I believe. To reiterate what I said
originally as far as I can remember every ASoC driver which uses a table
to look up volatility uses this naming.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists