From: Mark Brown <broonie@opensource.wolfsonmicro.com>
To: Arnd Bergmann <arnd@arndb.de>
Cc: Stephen Warren <swarren@wwwdotorg.org>,
Laxman Dewangan <ldewangan@nvidia.com>,
lrg@ti.com, rob.herring@calxeda.com, grant.likely@secretlab.ca,
linus.walleij@linaro.org, lee.jones@linaro.org,
devicetree-discuss@lists.ozlabs.org, linux-doc@vger.kernel.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH V3 2/3] regulator: dt: regulator match by regulator-compatible
Date: Thu, 21 Jun 2012 17:14:59 +0100 [thread overview]
Message-ID: <20120621161459.GY4037@opensource.wolfsonmicro.com> (raw)
In-Reply-To: <201206211450.35713.arnd@arndb.de>
[-- Attachment #1: Type: text/plain, Size: 1632 bytes --]
On Thu, Jun 21, 2012 at 02:50:35PM +0000, Arnd Bergmann wrote:
> It seems that the drivers that are changed to use this could also try to
> describe the individual regulators completely, by moving the contents
> of e.g. ab8500_regulator_info into the device tree, but having the string
> identifier with an in-kernel table makes sense when there is only one
> such table.
I'm not that big a fan of moving all the data into device tree as it
means that you need even more parsing code and you need to update the
device trees for every board out there every time you want to add
support for a new feature which doesn't seem like a win. Right now with
the DT kept in the kernel it's not so bad but if we ever do start
distributing it separately it becomes more of an issue.
I'm also not sure if the tooling works well for allowing people to
include standard DTs for chips and add new properties to nodes for the
board specific configuration, though I think I've seen a few things
which suggested that was dealt with reasonably well.
It also means that the driver becomes useless on non-DT systems; while
for something like ab85xx which is specific to a SoC that's not a
problem it's a serious drawback for devices which may be used on other
architectures (or older ARM systems for that matter). I'm quite worried
by this tendency to try to just dump all our data structures into DT -
it's similar to the issues with some of the MFDs just wanting to drop in
the current Linux subdivision of the device even though that's often
just reflecting our current internal structures which do change even
without worrying about other OSs.
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
next prev parent reply other threads:[~2012-06-21 16:14 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-06-20 12:23 [PATCH V3 0/3] regulator: dt: add policy to match regulator with prop "regulator-compatible" Laxman Dewangan
2012-06-20 12:23 ` [PATCH V3 1/3] ARM: dts: db8500: add property "regulator-compatible" regulator node Laxman Dewangan
2012-06-20 18:48 ` Stephen Warren
2012-06-20 12:23 ` [PATCH V3 2/3] regulator: dt: regulator match by regulator-compatible Laxman Dewangan
2012-06-20 19:24 ` Arnd Bergmann
2012-06-20 19:46 ` Mark Brown
2012-06-20 19:51 ` Stephen Warren
2012-06-20 23:37 ` Mark Brown
2012-06-20 20:40 ` Arnd Bergmann
2012-06-20 21:01 ` Stephen Warren
2012-06-20 23:35 ` Mark Brown
2012-06-21 14:50 ` Arnd Bergmann
2012-06-21 16:14 ` Mark Brown [this message]
2012-06-21 17:17 ` Arnd Bergmann
2012-06-21 17:31 ` Stephen Warren
2012-06-21 21:03 ` Arnd Bergmann
2012-06-21 22:52 ` Mark Brown
2012-06-21 19:45 ` Mark Brown
[not found] ` <20120621194544.GZ4037-yzvPICuk2AATkU/dhu1WVueM+bqZidxxQQ4Iyu8u01E@public.gmane.org>
2012-06-21 21:53 ` Mitch Bradley
2012-06-21 22:36 ` Mark Brown
2012-06-20 23:15 ` Mark Brown
[not found] ` <20120620194609.GA4037-yzvPICuk2AATkU/dhu1WVueM+bqZidxxQQ4Iyu8u01E@public.gmane.org>
2012-06-22 6:13 ` Thierry Reding
2012-06-22 8:42 ` Mark Brown
2012-06-22 8:59 ` Thierry Reding
2012-06-22 9:12 ` Mark Brown
2012-06-26 9:02 ` Laxman Dewangan
2012-06-26 9:12 ` Mark Brown
2012-06-26 10:13 ` Lee Jones
2012-07-04 23:48 ` Linus Walleij
2012-07-05 7:16 ` Lee Jones
2012-06-20 12:23 ` [PATCH V3 3/3] regulator: dt: add policy to have property "regulator-compatible" Laxman Dewangan
2012-06-20 18:52 ` Stephen Warren
2012-07-03 19:25 ` Mark Brown
2012-07-04 7:03 ` Laxman Dewangan
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=20120621161459.GY4037@opensource.wolfsonmicro.com \
--to=broonie@opensource.wolfsonmicro.com \
--cc=arnd@arndb.de \
--cc=devicetree-discuss@lists.ozlabs.org \
--cc=grant.likely@secretlab.ca \
--cc=ldewangan@nvidia.com \
--cc=lee.jones@linaro.org \
--cc=linus.walleij@linaro.org \
--cc=linux-doc@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=lrg@ti.com \
--cc=rob.herring@calxeda.com \
--cc=swarren@wwwdotorg.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).