Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755425AbbFONiX (ORCPT ); Mon, 15 Jun 2015 09:38:23 -0400 Received: from metis.ext.pengutronix.de ([92.198.50.35]:59823 "EHLO metis.ext.pengutronix.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752139AbbFONiP (ORCPT ); Mon, 15 Jun 2015 09:38:15 -0400 Date: Mon, 15 Jun 2015 15:38:10 +0200 From: Uwe =?iso-8859-1?Q?Kleine-K=F6nig?= To: Russell King - ARM Linux Cc: Kevin Hilman , Ard Biesheuvel , linux-arm-msm@vger.kernel.org, Kumar Gala , Stephen Boyd , linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, Andy Gross , Lina Iyer Subject: Re: [PATCH v2 1/2] ARM: Add cpu_resume_arm() for firmwares that resume in ARM state Message-ID: <20150615133810.GA19996@pengutronix.de> References: <1433272378-8470-1-git-send-email-sboyd@codeaurora.org> <1433272378-8470-2-git-send-email-sboyd@codeaurora.org> <20150615063324.GY18985@pengutronix.de> <20150615110136.GJ7557@n2100.arm.linux.org.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20150615110136.GJ7557@n2100.arm.linux.org.uk> User-Agent: Mutt/1.5.21 (2010-09-15) X-SA-Exim-Connect-IP: 2001:67c:670:100:1d::c0 X-SA-Exim-Mail-From: ukl@pengutronix.de X-SA-Exim-Scanned: No (on metis.ext.pengutronix.de); SAEximRunCond expanded to false X-PTX-Original-Recipient: linux-kernel@vger.kernel.org Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 3210 Lines: 68 Hello Russell, On Mon, Jun 15, 2015 at 12:01:36PM +0100, Russell King - ARM Linux wrote: > On Mon, Jun 15, 2015 at 08:33:25AM +0200, Uwe Kleine-K?nig wrote: > > Hello, > > > + .arm > > > +ENTRY(cpu_resume_arm) > > > + THUMB( badr r9, 1f ) @ Kernel is entered in ARM. > > > + THUMB( bx r9 ) @ If this is a Thumb-2 kernel, > > > + THUMB( .thumb ) @ switch to Thumb now. > > > + THUMB(1: ) > > > ENTRY(cpu_resume) > > > ARM_BE8(setend be) @ ensure we are in BE mode > > > #ifdef CONFIG_ARM_VIRT_EXT > > this patch is in next as 51ac91b7f6b11b0da55ac93885ee7b864865bcb1 and > > breaks efm32_defconfig. The exact error message is: > > > > AS arch/arm/kernel/sleep.o > > arch/arm/kernel/sleep.S: Assembler messages: > > arch/arm/kernel/sleep.S:121: Error: selected processor does not support ARM opcodes > > arch/arm/kernel/sleep.S:123: Error: bad instruction `badr r9,1f' > > arch/arm/kernel/sleep.S:124: Error: attempt to use an ARM instruction on a Thumb-only processor -- `bx r9' > > scripts/Makefile.build:294: recipe for target 'arch/arm/kernel/sleep.o' failed > > make[3]: *** [arch/arm/kernel/sleep.o] Error 1 > > Don't get me wrong, the build testing which goes on is really great, but > there's now a problem with all this. > > There needs to be coordination between the people doing the build tests > to ensure that we don't "tire out" those who read the emails with different > groups of people reporting the same problem days after it was first > discovered, and even worse, days after it's been fixed. > > The worst thing to do is to report build regressions on Monday for a tree > which was created on Thursday - by the time Monday comes around, projects > such as the 0-day builder have had plenty of time to find them. > > Remember, the linux-next tree which is published on Friday (Austrailian > time) is a result of git trees snapshotted around midnight on Thursday. > > So, if you're going to build an old linux-next tree, before you report any > problems, please check whether other build systems have already reported > them. If you've gone to the trouble of tracking down the commit which > caused it, and therefore the likely git tree, check whether a fix has > already been merged. Or maybe wait until the post-weekend linux-next is > published... > > (The problem you're referring to was fixed and pushed out on Friday - > which seems to be a regular thing that happens with problems you've > reported on Mondays...) I consulted Google (asking for the commit id) and checked the linux-arm-kernel list for reports which usually works well enough. But I understand your complaint, last time I introduced a build regression I got two automatic reports and three times the same fix into my mailbox. So I will try to be more careful in the future. Best regards Uwe -- Pengutronix e.K. | Uwe Kleine-K?nig | Industrial Linux Solutions | http://www.pengutronix.de/ | -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/