Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S933191AbbLVP53 (ORCPT ); Tue, 22 Dec 2015 10:57:29 -0500 Received: from pandora.arm.linux.org.uk ([78.32.30.218]:42908 "EHLO pandora.arm.linux.org.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752616AbbLVP52 (ORCPT ); Tue, 22 Dec 2015 10:57:28 -0500 Date: Tue, 22 Dec 2015 15:57:13 +0000 From: Russell King - ARM Linux To: Stefano Stabellini Cc: jaccon.bastiaansen@gmail.com, arnd@arndb.de, catalin.marinas@arm.com, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, xen-devel@lists.xenproject.org, will.deacon@arm.com Subject: Re: [PATCH RESEND v4] arm: remove !CPU_V6 and !GENERIC_ATOMIC64 build dependencies for XEN Message-ID: <20151222155713.GN8644@n2100.arm.linux.org.uk> References: <20151222144605.GJ8644@n2100.arm.linux.org.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2211 Lines: 46 On Tue, Dec 22, 2015 at 03:45:19PM +0000, Stefano Stabellini wrote: > The code builds, but of course it could not actually run on CPU_V6. But > the use case for me is building drivers/xen/grant-table.c, which can > only run on CPU_V7 anyway, so it is not a problem. What I'm concerned about in this case is if you try to use instructions which are not supported by the CPU, even in assembly, the assembler will barf. So, if we're building an ARMv6 + ARMv7 kernel, and you try to use LDREXB in generic code, even though you may intend it to only be executed on ARMv7, the assembler will error out. We used to be able to work around that by passing -Wa,-march=armv7 to the compiler for specific files, which would then tell the assembler to accept ARMv7 instructions, but modern GCC output .arch pseudo-ops which override the command line. So now the only way to do it is to override the assemblers selected archtecture using .arch pseudo-ops in the assembly code. So, what I'm saying is that dropping the !ARMv6 dependency is not as simple as it would seem, and I'm nervous about including any such patches this close to Christmas and the merge window. I've recently been through a run of "apply this patch, no it's wrong, drop it, apply the next version, no it's still wrong, drop it again." So, today is the last day I'm accepting _known_ good patches into my tree for the 4.5 merge window. This is not yet a known good patch because it hasn't been through several iterations of testing - and I don't want to be adding and removing patches from my tree over Christmas. I'd rather leave my tree in a known good state before Christmas so that those who want to fiddle with the kernel over the holiday break can do so without having the hassle of trees containing partially tested patches. -- RMK's Patch system: http://www.arm.linux.org.uk/developer/patches/ FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up according to speedtest.net. -- 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/