All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mark Brown <broonie@kernel.org>
To: "Opensource [Anthony Olech]" <anthony.olech.opensource@diasemi.com>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	David Dajun Chen <david.chen@diasemi.com>
Subject: Re: [RFC V1] drivers/base/regmap: Implementation for regmap_multi_reg_write
Date: Sat, 1 Mar 2014 13:03:27 +0900	[thread overview]
Message-ID: <20140301040327.GL29849@sirena.org.uk> (raw)
In-Reply-To: <24DF37198A1E704D9811D8F72B87EB51BCFDE02F@NB-EX-MBX02.diasemi.com>

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

On Fri, Feb 28, 2014 at 03:58:34PM +0000, Opensource [Anthony Olech] wrote:

> The algorithm for splitting up into smaller _multi_reg_writes is easy enough,
> so if the calling device driver created a set of (reg,val) pairs for a multi reg
> write operation then surely the intention is for the individual pieces to be
> handled as multi reg writes.

Right, that's what should eventually happen - what I'm saying is it's OK
to defer the hard parts for later if they're not needed right now (in
much the same way that the API was added without an actual multi write
implementation).

> > > +	for (i = 0, n = 0, switched = false, base = regs; i < num_regs;
> > > +								i++, n++) {
> > Don't put all this stuff in the for (), just put the iteration in the for ().

> all those variables are a fundamental part of the loop, but I will change it.

It's still ugly and hard to read, look at the line wrapping...  the
normal thing is to have preconditions that aren't part of the actual
iteration process immediately before the loop statement.

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

      reply	other threads:[~2014-03-01  4:03 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-02-27 11:28 [RFC V1] drivers/base/regmap: Implementation for regmap_multi_reg_write Opensource [Anthony Olech]
2014-02-28  3:37 ` Mark Brown
2014-02-28 15:58   ` Opensource [Anthony Olech]
2014-03-01  4:03     ` Mark Brown [this message]

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=20140301040327.GL29849@sirena.org.uk \
    --to=broonie@kernel.org \
    --cc=anthony.olech.opensource@diasemi.com \
    --cc=david.chen@diasemi.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=linux-kernel@vger.kernel.org \
    /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.