From: Matt Porter <mporter@linaro.org>
To: Lee Jones <lee.jones@linaro.org>
Cc: Mark Brown <broonie@kernel.org>,
Devicetree List <devicetree@vger.kernel.org>,
Samuel Ortiz <sameo@linux.intel.com>,
Liam Girdwood <lgirdwood@gmail.com>,
Tim Kryger <tim.kryger@linaro.org>,
Markus Mayer <markus.mayer@linaro.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
Linux ARM Kernel List <linux-arm-kernel@lists.infradead.org>
Subject: Re: [PATCH 2/4] mfd: bcm590xx: add support for second i2c slave address space
Date: Wed, 23 Apr 2014 18:05:00 -0400 [thread overview]
Message-ID: <20140423220500.GA1127@beef> (raw)
In-Reply-To: <20140423220126.GC4164@beef>
On Wed, Apr 23, 2014 at 06:01:26PM -0400, Matt Porter wrote:
> On Tue, Apr 22, 2014 at 09:21:39AM +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.
> >
> > Let's stick method fabricated by the I2C subsystem. It may seem strange
> > from a h/w perspective, but it is the way we (you) have coded it, as
> > the first parameter of i2c_new_dummy() is the 'managing' (primary,
> > parent, master, whatever) device, so '_sec' would suit as an
> > identifying appendage for the resultant device.
>
> That works, I'll also switch to addrmap_[pri|sec] which touches the
> regulator driver as well. That will keep the relationship between device
> and regmap clear.
Misspoke...I'm switching regmap[0|1] to regmap_[pri|sec] to keep that
synced with i2c_[pri|sec]
-Matt
next prev parent reply other threads:[~2014-04-23 22:05 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
[not found] ` <1397501428-8857-1-git-send-email-mporter-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
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
[not found] ` <1397501428-8857-3-git-send-email-mporter-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
2014-04-16 11:06 ` Lee Jones
2014-04-16 21:31 ` Mark Brown
[not found] ` <20140416213141.GD12304-GFdadSzt00ze9xe1eoZjHA@public.gmane.org>
2014-04-17 6:57 ` Lee Jones
2014-04-17 22:26 ` Matt Porter
2014-04-22 8:21 ` Lee Jones
2014-04-23 22:01 ` Matt Porter
2014-04-23 22:05 ` Matt Porter [this message]
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=20140423220500.GA1127@beef \
--to=mporter@linaro.org \
--cc=broonie@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=lee.jones@linaro.org \
--cc=lgirdwood@gmail.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=markus.mayer@linaro.org \
--cc=sameo@linux.intel.com \
--cc=tim.kryger@linaro.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).