linux-kernel - Re: linux-next: build failure after merge of the tip tree

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <alpine.DEB.2.10.1406041134070.3319@nanos>
Date:	Wed, 4 Jun 2014 12:49:27 +0200 (CEST)
From:	Thomas Gleixner <tglx@...utronix.de>
To:	Stephen Rothwell <sfr@...b.auug.org.au>
cc:	Ingo Molnar <mingo@...e.hu>, "H. Peter Anvin" <hpa@...or.com>,
	Peter Zijlstra <peterz@...radead.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>,
	Olof Johansson <olof@...om.net>,
	Linus Torvalds <torvalds@...ux-foundation.org>
Subject: Re: linux-next: build failure after merge of the tip tree

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?

Of course this crap is already in Linus next branch, so it essentially
blocks me from sending my pending timers/core branch.

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

      tglx

------------>
Subject: clocksource: versatile: Use sched_clock_register()
From: Thomas Gleixner <tglx@...utronix.de>
Date: Wed, 04 Jun 2014 12:34:15 +0200

The newly merged versatile sched clock support uses a deprecated
interface. Of course that patch got routed through the ARM tree
instead of going through the relevant maintainer tree.

Use the proper interface so we can get rid of the cruft.

Signed-off-by: Thomas Gleixner <tglx@...utronix.de>
---
diff --git a/drivers/clocksource/versatile.c b/drivers/clocksource/versatile.c
index e4c50ad..2798e74 100644
--- a/drivers/clocksource/versatile.c
+++ b/drivers/clocksource/versatile.c
@@ -20,7 +20,7 @@
 
 static void __iomem *versatile_sys_24mhz;
 
-static u32 notrace versatile_sys_24mhz_read(void)
+static u64 notrace versatile_sys_24mhz_read(void)
 {
 	return readl(versatile_sys_24mhz);
 }
@@ -34,7 +34,7 @@ static void __init versatile_sched_clock_init(struct device_node *node)
 
 	versatile_sys_24mhz = base + SYS_24MHZ;
 
-	setup_sched_clock(versatile_sys_24mhz_read, 32, 24000000);
+	sched_clock_register(versatile_sys_24mhz_read, 32, 24000000);
 }
 CLOCKSOURCE_OF_DECLARE(versatile, "arm,vexpress-sysreg",
-		versatile_sched_clock_init);
+		       versatile_sched_clock_init);
--
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/