[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAOesGMhGT30QN2LeVp2sgzY0BjbguW=iw3x1PH8RVB-Rj-GZNQ@mail.gmail.com>
Date: Wed, 4 Jun 2014 09:23:43 -0700
From: Olof Johansson <olof@...om.net>
To: Thomas Gleixner <tglx@...utronix.de>
Cc: Stephen Rothwell <sfr@...b.auug.org.au>,
Ingo Molnar <mingo@...e.hu>, "H. Peter Anvin" <hpa@...or.com>,
Peter Zijlstra <peterz@...radead.org>,
"linux-next@...r.kernel.org" <linux-next@...r.kernel.org>,
LKML <linux-kernel@...r.kernel.org>,
Pawel Moll <pawel.moll@....com>,
Stephen Boyd <sboyd@...eaurora.org>,
John Stultz <john.stultz@...aro.org>,
Linus Torvalds <torvalds@...ux-foundation.org>
Subject: Re: linux-next: build failure after merge of the tip tree
On Wed, Jun 4, 2014 at 3:49 AM, Thomas Gleixner <tglx@...utronix.de> wrote:
> On Wed, 4 Jun 2014, Stephen Rothwell wrote:
>
>> Hi all,
>>
>> After merging the tip tree, today's linux-next build (arm
>> multi_v7_defconfig) failed like this:
>>
>>
>> drivers/clocksource/versatile.c: In function 'versatile_sched_clock_init':
>> drivers/clocksource/versatile.c:37:2: error: implicit declaration of function 'setup_sched_clock' [-Werror=implicit-function-declaration]
>>
>> Caused by commit c04ae71c9c26 ("sched_clock: Remove deprecated
>> setup_sched_clock() API") from the tip tree. The usage was only added
>> to Linus' tree today by commit 220e2a8d22cd ("clocksource: Sched clock
>> source for Versatile Express") (but this commit has been in linux-next
>> since May 22 at least).
>>
>> I have reverted the tip tree commit for today.
>
> Dammit. Why the heck can ARM folks not route their stuff through the
> relevant maintainers? Because ARM is a different universe with
> different rules or what?
We talked about this as late as February this year. It's has been a
long-standing issue that we've struggled with how we should manage.
When I talked to you about it (irqchip drivers at the time), you said
you were in general fine with us merging driver patches when someone
times out waiting on you to review/merge a patch. My concern at the
time is that while we can look at the code of the patch and review
that, we don't have the larger picture of what's going on in the
subsystem. Which is what caused problems here, I'd say.
So, we'll dial back and stop taking these patches through our tree
without an explicit ack or shared branch from you (or Daniel on
clocksource). Not a problem at all.
> Of course this crap is already in Linus next branch, so it essentially
> blocks me from sending my pending timers/core branch.
We obviously never intended to cause any problems like these, and I
apologize for that. On the other hand, it would have been a lot easier
to handle had the code on your end landed a bit sooner than in the
middle of the merge window.
> Patch below. Linus, can you please apply this?
>
> I've ranted about this before. It's not the first time that ARM breaks
> stuff I maintain.
>
> Again: Send your stuff against drivers/clocksource and drivers/irqchip
> to the maintainers.
>
> I'm happy to provide you a separate branch to pull that stuff from me,
> if you have dependencies on that, but I really don't want to see any
> of this again, ever.
>
> Yours seriously grumpy
Not much I can say besides what's above and that I owe you a few beers
at the next conference.
-Olof
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists