linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: mporter@linaro.org (Matt Porter)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 2/4] mfd: bcm590xx: add support for second i2c slave address space
Date: Thu, 17 Apr 2014 18:26:16 -0400	[thread overview]
Message-ID: <20140417222616.GK23695@beef> (raw)
In-Reply-To: <20140417065753.GC28725@lee--X1>

On Thu, Apr 17, 2014 at 07:57:53AM +0100, Lee Jones wrote:
> > > s/regmap/Regmap
> > 
> > It's consistently written regmap in all the documentation and so on :)
> 
> Furry muff; but the comments still stand for the acronyms.
> 
> > > addmap{0,1} doesn't quite sit right with me.
> > 
> > > REVISIT: Ah, it's address-map, rather than add map. Okay, not as bad
> > > as I first thought, but still, is there a better naming convention you
> > > could use?
> > 
> > addrmap or something?
> 
> Right, that was what I was thinking. However, I prefer something along
> the lines of 'i2c' and 'i2c_sec' or 'client' and 'client_slv' etc.

FWIW, the reason it's addmap{0,1} is that the datasheet has documents
ADDMAP=0 and the first bank of registers and ADDMAP=1 as the second bank
of registers. I adopted that to match the docs for the part.

I guess we could do i2c and i2c_sec, I'll just have to put a comment
correlating it to the h/w. Calling it 'slv' implies something else
so we should avoid that here. The notion of a "secondary" i2c device
is completely a Linux I2C subsystem fabrication which wouldn't exist
if it allowed multiple slave addresses per device. From a h/w
perspective there is really no primary and secondary relationship.

I'm fine with i2c/i2c_sec or addrmap0/1 and I will just comment to
correlate with the datasheet..pick one.

-Matt
> 
> -- 
> Lee Jones
> Linaro STMicroelectronics Landing Team Lead
> Linaro.org ? Open source software for ARM SoCs
> Follow Linaro: Facebook | Twitter | Blog

  reply	other threads:[~2014-04-17 22:26 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-04-14 18:50 [PATCH 0/4] Support additional regulators on BCM590xx Matt Porter
2014-04-14 18:50 ` [PATCH 1/4] mfd: bcm590xx: update binding with additional BCM59056 regulators Matt Porter
2014-04-14 18:50 ` [PATCH 2/4] mfd: bcm590xx: add support for second i2c slave address space Matt Porter
2014-04-16 11:06   ` Lee Jones
2014-04-16 21:31     ` Mark Brown
2014-04-17  6:57       ` Lee Jones
2014-04-17 22:26         ` Matt Porter [this message]
2014-04-22  8:21           ` Lee Jones
2014-04-23 22:01             ` Matt Porter
2014-04-23 22:05               ` Matt Porter
2014-04-28  9:29                 ` Lee Jones
2014-04-17 22:30     ` Matt Porter
2014-04-14 18:50 ` [PATCH 3/4] regulator: bcm590xx: add support for regulators on secondary i2c slave Matt Porter
2014-04-14 19:59   ` Mark Brown
2014-04-14 18:50 ` [PATCH 4/4] ARM: dts: bcm590xx: add support for GPLDO and VBUS regulators Matt Porter

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=20140417222616.GK23695@beef \
    --to=mporter@linaro.org \
    --cc=linux-arm-kernel@lists.infradead.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).