From: Jean Delvare <khali@linux-fr.org>
To: Mark Brown <broonie@opensource.wolfsonmicro.com>
Cc: Greg KH <greg@kroah.com>, Grant Likely <grant@secretlab.ca>,
Ben Dooks <ben-linux@fluff.org>,
Dimitris Papastamos <dp@opensource.wolfsonmicro.com>,
Liam Girdwood <lrg@ti.com>, Samuel Oritz <sameo@linux.intel.com>,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH 4/4] regulator: Convert tps65023 to use regmap API
Date: Sun, 17 Jul 2011 17:53:44 +0200 [thread overview]
Message-ID: <20110717175344.1d1bf16a@endymion.delvare> (raw)
In-Reply-To: <20110715131748.GD10026@opensource.wolfsonmicro.com>
Hi Mark,
On Fri, 15 Jul 2011 22:17:51 +0900, Mark Brown wrote:
> On Fri, Jul 15, 2011 at 02:58:48PM +0200, Jean Delvare wrote:
> > On Fri, 15 Jul 2011 21:16:50 +0900, Mark Brown wrote:
>
> > > Does that sound reasonable to you?
>
> > Yes, no objection.
>
> BTW, if this does sound reasonable are you OK with adding your ack for
> the I2C bus interface patch or are there any updates you want me to do?
I did not review the patch carefully, so I can't ask for updates. As
none of "my" drivers will use it, I don't really feel qualified (nor
interested, honestly) to review it.
I don't quite get why you put the i2c bindings into
drivers/i2c/i2c-regmap.c. This means that Ben and I end up being the
maintainers of that file, while it's your thing. And this module is a
user of i2c, not a provider, so it doesn't really belong there anyway.
Same goes with spi. And what's the rationale for putting the regmap core
under drivers/base?
What's wrong with the more direct approach:
drivers/regmap/regmap-core.c
drivers/regmap/regmap-i2c.c
drivers/regmap/regmap-spi.c
?
At least you would have everything in one place and under your control.
With your current plan, every update is likely to spawn
cross-subsystems, which always results in delays and conflicts.
Now if you have a good reason for the current design, that's OK with
me, I can live with that. Simply it seems more complex than needed.
Also, your Kconfig setup is such that all bindings will be selected as
soon as any driver needs one. And the selection (module vs. built-in)
will be aligned on the core setting (e.g. CONFIG_I2C) rather than the
drivers which use it. I'd rather have e.g. REGULATOR_TPS65023 select
REGMAP_I2C, and in turn have REGMAP_I2C select REGMAP. This should
address the issues I pointed out.
--
Jean Delvare
next prev parent reply other threads:[~2011-07-17 15:54 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-07-15 6:22 [PATCH 0/4] regmap: Generic I2C and SPI register map library Mark Brown
2011-07-15 6:23 ` [PATCH 1/4] regmap: Add generic non-memory mapped register access API Mark Brown
2011-07-15 6:23 ` [PATCH 2/4] regmap: Add I2C bus support Mark Brown
2011-07-15 6:23 ` [PATCH 3/4] regmap: Add SPI " Mark Brown
2011-07-15 6:23 ` [PATCH 4/4] regulator: Convert tps65023 to use regmap API Mark Brown
2011-07-15 10:31 ` Jean Delvare
2011-07-15 12:16 ` Mark Brown
2011-07-15 12:58 ` Jean Delvare
2011-07-15 13:10 ` Mark Brown
2011-07-15 13:17 ` Mark Brown
2011-07-17 15:53 ` Jean Delvare [this message]
2011-07-18 0:00 ` Grant Likely
2011-07-18 9:44 ` Mark Brown
-- strict thread matches above, loose matches on Subject: below --
2011-07-18 10:04 [PATCH 0/4] regmap: Generic I2C and SPI register map library Mark Brown
2011-07-18 10:07 ` [PATCH 1/4] regmap: Add generic non-memory mapped register access API Mark Brown
2011-07-18 10:07 ` [PATCH 4/4] regulator: Convert tps65023 to use regmap API Mark Brown
2011-07-16 2:48 [PATCH 0/4] regmap: Generic I2C and SPI register map library Mark Brown
2011-07-16 2:48 ` [PATCH 1/4] regmap: Add generic non-memory mapped register access API Mark Brown
2011-07-16 2:48 ` [PATCH 4/4] regulator: Convert tps65023 to use regmap API Mark Brown
2011-07-09 4:49 [PATCH 0/4] regmap: Generic I2C and SPI register map library Mark Brown
2011-07-09 4:50 ` [PATCH 1/4] regmap: Add generic non-memory mapped register access API Mark Brown
2011-07-09 4:50 ` [PATCH 4/4] regulator: Convert tps65023 to use regmap API Mark Brown
2011-07-15 2:53 ` Grant Likely
2011-07-15 4:48 ` Mark Brown
2011-07-15 18:29 ` Grant Likely
2011-07-16 1:47 ` Mark Brown
2011-07-16 2:06 ` Grant Likely
2011-07-16 2:13 ` 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=20110717175344.1d1bf16a@endymion.delvare \
--to=khali@linux-fr.org \
--cc=ben-linux@fluff.org \
--cc=broonie@opensource.wolfsonmicro.com \
--cc=dp@opensource.wolfsonmicro.com \
--cc=grant@secretlab.ca \
--cc=greg@kroah.com \
--cc=linux-kernel@vger.kernel.org \
--cc=lrg@ti.com \
--cc=sameo@linux.intel.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
all inboxes | Powered by JetHome®