All of lore.kernel.org
 help / color / mirror / Atom feed
From: mturquette@ti.com (Turquette, Mike)
To: linux-arm-kernel@lists.infradead.org
Subject: announcing the clk-next branch
Date: Wed, 25 Apr 2012 08:15:29 -0700	[thread overview]
Message-ID: <CAJOA=zOpuX3ccKWGf5h-L0ibjujYeSe1v8bz8oMEkYLQT=rPmA@mail.gmail.com> (raw)
In-Reply-To: <20120425124258.GY24211@n2100.arm.linux.org.uk>

On Wed, Apr 25, 2012 at 5:42 AM, Russell King - ARM Linux
<linux@arm.linux.org.uk> wrote:
> On Wed, Apr 25, 2012 at 02:38:28PM +0200, Sascha Hauer wrote:
>> On Tue, Apr 24, 2012 at 06:32:20PM -0700, Turquette, Mike wrote:
>> > Hi all,
>> >
>> > The clock patches that I have signed-off on and picked from the list
>> > are all rebased on top of 3.4-rc4. ?They can be found here:
>> >
>> > git://git.linaro.org/people/mturquette/linux.git clk-next
>>
>> Thanks Mike!
>>
>> >
>> > If the branch is missing anything that I have ACK'd then please let me know.
>>
>> You haven't acked it, but for i.MX I need two patches from Viresh I'd
>> like to base on:
>>
>> [PATCH V3 1/8] CLKDEV: Add helper routines to allocate and add clkdevs for given struct clk *
>> [PATCH V3 2/8] clk: add a fixed factor clock
>>
>> Also I need the patch implementing managed clk_get which currently sits
>> in Russells tree.
>
> Well, some of this stuff is already committed in my tree. ?There's total
> confusion at the moment over who's looking after clk API stuff - I'm
> listed as the official maintainer for linux/clk.h and clkdev, but Mike
> is clearly the guy doing all the common stuff.
>
> What would not be a good idea is to have the same patches committed
> independently into two different trees.

What is the best solution here?

I can base my branch on top of one of yours if the goal is to have
clk-next be a one-stop-shop for folks trying to port their platforms
over to the new struct clk.

On the other hand maybe the platform folks that are trying to convert
to struct clk should just base their work on top of your for-next
branch and my clk-next, merged locally.

In the mean time I'll go through my branch today and see which patches
collide with ones you have already merged.  My branch is quite small
(less than two dozen patches) so removing collisions will be easy.

Regards,
Mike

  reply	other threads:[~2012-04-25 15:15 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-04-25  1:32 announcing the clk-next branch Turquette, Mike
2012-04-25 12:38 ` Sascha Hauer
2012-04-25 12:42   ` Russell King - ARM Linux
2012-04-25 15:15     ` Turquette, Mike [this message]
2012-04-26  3:56 ` Viresh Kumar
2012-04-30 14:41   ` Arnd Bergmann
2012-04-30 16:16     ` viresh kumar
2012-04-30 16:37       ` Arnd Bergmann
2012-04-30 16:40         ` viresh kumar
2012-04-30 17:00           ` Arnd Bergmann
2012-04-27  4:10 ` Viresh Kumar
2012-04-27  6:14 ` Viresh Kumar
2012-04-27  7:09   ` Shawn Guo
2012-04-27 17:54     ` Turquette, Mike
2012-04-28  4:52       ` Shawn Guo
2012-04-30 14:43       ` Arnd Bergmann

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='CAJOA=zOpuX3ccKWGf5h-L0ibjujYeSe1v8bz8oMEkYLQT=rPmA@mail.gmail.com' \
    --to=mturquette@ti.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.