public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Mark Brown <broonie@opensource.wolfsonmicro.com>
To: Laxman Dewangan <ldewangan@nvidia.com>
Cc: gregkh@linuxfoundation.org, lrg@ti.com, linux-kernel@vger.kernel.org
Subject: Re: [PATCH V1 1/4] regmap: add function for set/clear bits
Date: Mon, 7 May 2012 11:55:59 +0100	[thread overview]
Message-ID: <20120507105558.GG4415@opensource.wolfsonmicro.com> (raw)
In-Reply-To: <1336376139-1048-2-git-send-email-ldewangan@nvidia.com>

[-- Attachment #1: Type: text/plain, Size: 1058 bytes --]

On Mon, May 07, 2012 at 01:05:36PM +0530, Laxman Dewangan wrote:
> Add regmap_set_bits() and regmap_clear_bits() for
> setting/clearing bits.
> Although this can be achieve by regmap_update_bits() but
> having these functions gives good readability in driver
> code which uses regmap apis.

I'm not convinced about these for readability in the first place but...

> +int regmap_set_bits(struct regmap *map, unsigned int reg, unsigned int bits)
> +{
> +	bool change;
> +	return _regmap_update_bits(map, reg, bits, bits, &change);
> +}
> +EXPORT_SYMBOL_GPL(regmap_set_bits);

...clearly they should just be static inlines in the header file,
there's nothing in the actual function.

For readability I find moving the operation being done to the register
value into the function name tends to make it less obvious when scanning
the code what the actual change is (since with a bunch of operations
there's a lot of repeated text on the line and a fairly small amount of
text for the actual change) and can lead to the two operations following
one after another.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

  reply	other threads:[~2012-05-07 10:56 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-05-07  7:35 [PATCH V1 0/4] regulator: tps62360: add cache support and settling time Laxman Dewangan
2012-05-07  7:35 ` [PATCH V1 1/4] regmap: add function for set/clear bits Laxman Dewangan
2012-05-07 10:55   ` Mark Brown [this message]
2012-05-07  7:35 ` [PATCH V1 2/4] regulator: tps62360: enable register cache Laxman Dewangan
2012-05-07 11:13   ` Mark Brown
2012-05-07  7:35 ` [PATCH V1 3/4] regulator: tps62360: use efficient function Laxman Dewangan
2012-05-07  7:35 ` [PATCH V1 4/4] regulator: tps62360: Provide settling time for voltage change Laxman Dewangan
2012-05-07 11:23   ` Mark Brown
2012-05-07 12:42     ` Laxman Dewangan
2012-05-07 14:22       ` Mark Brown
2012-05-07 14:45         ` Laxman Dewangan
2012-05-07 14:51           ` 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=20120507105558.GG4415@opensource.wolfsonmicro.com \
    --to=broonie@opensource.wolfsonmicro.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=ldewangan@nvidia.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=lrg@ti.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