mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Arnd Bergmann <arnd@arndb.de>
To: Mark Brown <broonie@opensource.wolfsonmicro.com>
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:17:45 +0000	[thread overview]
Message-ID: <201206211717.46142.arnd@arndb.de> (raw)
In-Reply-To: <20120621161459.GY4037@opensource.wolfsonmicro.com>

On Thursday 21 June 2012, Mark Brown wrote:
>   Show Details
>   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.

Right. It's certainly a trade-off. If a company makes 100 SoCs that
all have similar-but-different regulators, then it should be clear
win to have the driver be very abstract and fed with DT data for
configuragtion.

> 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 should never be necessary to add board-specific properties in the
nodes that describe the SoC specific bits. What I was referring to
is just moving the data that currently resides in the regulator
driver into DT.

	Arnd

  reply	other threads:[~2012-06-21 17:20 UTC|newest]

Thread overview: 33+ 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
2012-06-21 17:17                 ` Arnd Bergmann [this message]
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]                     ` <4FE397E5.1070707@firmworks.com>
2012-06-21 22:36                       ` Mark Brown
2012-06-20 23:15         ` Mark Brown
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=201206211717.46142.arnd@arndb.de \
    --to=arnd@arndb.de \
    --cc=broonie@opensource.wolfsonmicro.com \
    --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

Powered by JetHome