linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: broonie@opensource.wolfsonmicro.com (Mark Brown)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v3 0/2] Device tree support for TWL regulators
Date: Mon, 27 Feb 2012 14:03:56 +0000	[thread overview]
Message-ID: <20120227140356.GF3191@opensource.wolfsonmicro.com> (raw)
In-Reply-To: <4F4B8A85.7060603@ti.com>

On Mon, Feb 27, 2012 at 02:52:05PM +0100, Cousson, Benoit wrote:
> On 2/27/2012 2:41 PM, Mark Brown wrote:
> >On Mon, Feb 27, 2012 at 06:01:20PM +0530, Rajendra Nayak wrote:

> >Please can you guys come up with a single unified series for this stuff
> >- I'll hold off on applying anything to allow you to do this.

> The issue is that the initial TWL regulator series from Rajendra
> will depend on the twl core DT support I have that depends on the
> irq_domain series from Grant...

Really?  That's the first I've heard of any such dependency here.  Is it
a build time dependency or is it just something that's required to make
the code actually spring into life?  It looks like it's the latter but
you're saying there's an actual dependency.

There's also more than that, there's also at least Tero submitting some
other stuff separately (and his stuff won't play with DT...) and I think
Peter also.  It really fees like there's a bunch of people working on
different things without talking to each other here.

> So I guess, it will be easy for us to split the regulator patches
> from the DTS ones to have at least the driver changes merged by you.
> Then Tony might be able to pull all the DTS in one series and thus
> avoid the various merge conflict that will happen since most OMAP
> drivers are hacking the same DTS files.

> Does that make sense? Or do you think it will be even worst
> separating the patches?

Unless there's a compile time dependency I don't think we need to
refactor anything here, what I'm seeing at the minute looks OK from a
merge point of view except that there appears to be a lack of
coordination between the various serieses.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20120227/edc21336/attachment.sig>

  reply	other threads:[~2012-02-27 14:03 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-02-27 10:35 [PATCH v3 0/2] Device tree support for TWL regulators Rajendra Nayak
2012-02-27 10:36 ` [PATCH v3 1/2] regulator: twl: adapt twl-regulator driver to dt Rajendra Nayak
2012-02-27 10:36 ` [PATCH v3 2/2] arm/dts: twl: Pass regulator data from dt Rajendra Nayak
2012-02-27 12:15 ` [PATCH v3 0/2] Device tree support for TWL regulators Peter Ujfalusi
2012-02-27 12:31   ` Rajendra Nayak
2012-02-27 13:41     ` Mark Brown
2012-02-27 13:52       ` Cousson, Benoit
2012-02-27 14:03         ` Mark Brown [this message]
2012-02-27 14:21           ` Cousson, Benoit
2012-02-27 14:53             ` Mark Brown
2012-02-28  5:41               ` Rajendra Nayak
2012-02-28 10:18                 ` Mark Brown
2012-02-27 22:17         ` Grant Likely
2012-02-27 22:24           ` Cousson, Benoit
  -- strict thread matches above, loose matches on Subject: below --
2012-02-23 11:35 Rajendra Nayak

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=20120227140356.GF3191@opensource.wolfsonmicro.com \
    --to=broonie@opensource.wolfsonmicro.com \
    --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).