From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-5.0 required=3.0 tests=DKIM_INVALID,DKIM_SIGNED, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SIGNED_OFF_BY,SPF_HELO_NONE, SPF_PASS,URIBL_BLOCKED,USER_AGENT_SANE_1 autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 01869C2BA2B for ; Fri, 10 Apr 2020 12:34:20 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id BE8FA20679 for ; Fri, 10 Apr 2020 12:34:19 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=fail reason="signature verification failed" (2048-bit key) header.d=armlinux.org.uk header.i=@armlinux.org.uk header.b="l4BUxrAo" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726669AbgDJMeS (ORCPT ); Fri, 10 Apr 2020 08:34:18 -0400 Received: from pandora.armlinux.org.uk ([78.32.30.218]:60780 "EHLO pandora.armlinux.org.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725926AbgDJMeR (ORCPT ); Fri, 10 Apr 2020 08:34:17 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=armlinux.org.uk; s=pandora-2019; h=Sender:In-Reply-To:Content-Type: MIME-Version:References:Message-ID:Subject:Cc:To:From:Date:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=E1lO6MOH92TXjApRphPPU5REy5FFZ6ZxwRqdljo4K0I=; b=l4BUxrAoEycXsvzjLPbLhvRWn YmPDjlzo97j79NsDCZtIMpz+tOfJ6KLwqm+t16Gc3OahvC/q8epEK3btHhPJNFVvr2sM8sdKkSn0O 4dqEY51qKb2+5UdFgeMYM+wTw0sXrrvHXl39ewXQXl5F0x5+LLa2OlyZWp7kIhy4tA3+R0NzIIOgN kItZyIUPPxOA1wiAS+fi/bo/hE4vTQXzskPL5uLJRtijka6wht30pxwQV3PLU/MYve1PNywLKPCPg CFQndh/X1J624Qe8ASBS0LUWvin4+mitfm5r9Ev/oGnDniUty9HF16ILDX85hnwTYHwUrPUbXS9b1 IcuRBqUUA==; Received: from shell.armlinux.org.uk ([2001:4d48:ad52:3201:5054:ff:fe00:4ec]:36520) by pandora.armlinux.org.uk with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.90_1) (envelope-from ) id 1jMsqM-0001Tt-Nz; Fri, 10 Apr 2020 13:33:10 +0100 Received: from linux by shell.armlinux.org.uk with local (Exim 4.92) (envelope-from ) id 1jMsqD-0003m7-Pl; Fri, 10 Apr 2020 13:33:01 +0100 Date: Fri, 10 Apr 2020 13:33:01 +0100 From: Russell King - ARM Linux admin To: Ard Biesheuvel Cc: Arnd Bergmann , Jian Cai , Linus Walleij , Peter Smith , Stefan Agner , David Howells , Mauro Carvalho Chehab , Manoj Gupta , Benjamin Gaignard , "Joel Fernandes (Google)" , clang-built-linux , Ilie Halip , Masahiro Yamada , Krzysztof Kozlowski , Bartosz Golaszewski , Sami Tolvanen , "Eric W. Biederman" , "Steven Rostedt (VMware)" , jiancai@google.com, Doug Anderson , Dan Williams , Linux ARM , Greg Kroah-Hartman , Nick Desaulniers , "linux-kernel@vger.kernel.org" , Patrick Bellasi , Masami Hiramatsu , Tejun Heo , Andrew Morton Subject: Re: [PATCH] ARM: do not assemble iwmmxt.S with LLVM toolchain Message-ID: <20200410123301.GX25745@shell.armlinux.org.uk> References: <20200409232728.231527-1-caij2003@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Apr 10, 2020 at 01:15:08PM +0200, Ard Biesheuvel wrote: > On Fri, 10 Apr 2020 at 11:56, Arnd Bergmann wrote: > > > > On Fri, Apr 10, 2020 at 1:28 AM Jian Cai wrote: > > > > > > iwmmxt.S contains XScale instructions LLVM ARM backend does not support. > > > Skip this file if LLVM integrated assemmbler or LLD is used to build ARM > > > kernel. > > > > > > Signed-off-by: Jian Cai > > > > It clearly makes sense to limit the Kconfig option to compilers that > > can actually build it. > > A few questions though: > > > > - Given that Armada XP with its PJ4B was still marketed until fairly > > recently[1], > > wouldn't it make sense to still add support for it? Is it a lot of work? > > > > The part of that file that the assembler chokes on hasn't been touched > by anyone since Nico added it 15+ years ago. It can only be built in > ARM mode, and it disassembles to the sequence below (the ld/st fe/fp > mnemonics are not document in recent versions of the ARM ARM, and > aren't understood by Clang either) For older CPUs, it doesn't matter what the latest ARM ARM says, the appropriate version of the ARM ARM is the one relevant for the CPU architecture. This is a mistake frequently made, and it's been pointed out by Arm Ltd in the past (before ARMv6 even came on the scene) that keeping older revisions is necessary if you want to be interested in the older architectures. However, there's an additional complication here: DEC's license from Arm Ltd back in the days of StrongARM allowed them to make changes to the architecture - that was passed over to Intel when they bought that part of DEC. Consequently, these "non-Arm vendor" cores contain extensions that are not part of the ARM ARM. iWMMXT is one such example, which first appeared in the Intel PXA270 SoC (an ARMv5 derived CPU). In fact, several of the features found in later versions of the ARM architecture came from DEC and Intel enhancements. If your compiler/assembler only implements what is in the latest ARM ARM, then it is not going to be suitable for these older CPUs and alternate vendor "ARM compatible" CPUs. > Instead of playing all these tricks with Kconfig, couldn't we simply > insert the bare opcodes and be done with it? That gets close to a GPL violation; the GPL requires that source code be in the preferred form for making modifications. Encoding raw opcodes can in no way be argued to be the preferred form. Arguing that raw opcodes is acceptable sets a precedent that makes it acceptable for other "works" to do the same, which makes arguments against firmware supplied as a hexdump null and void. Using macros to emulate the instructions and create the appropriate opcodes is an alternative; we already have that for some of the VFP code as early toolchains had no support for the VFP instructions. So no, bare opcodes are unacceptable. -- RMK's Patch system: https://www.armlinux.org.uk/developer/patches/ FTTC broadband for 0.8mile line in suburbia: sync at 10.2Mbps down 587kbps up From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-5.2 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SIGNED_OFF_BY, SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED,USER_AGENT_SANE_1 autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 24DEFC2BA2B for ; Fri, 10 Apr 2020 12:36:26 +0000 (UTC) Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id E4E9920769 for ; Fri, 10 Apr 2020 12:36:25 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="Dqyn95iO"; dkim=fail reason="signature verification failed" (2048-bit key) header.d=armlinux.org.uk header.i=@armlinux.org.uk header.b="l4BUxrAo" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org E4E9920769 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=armlinux.org.uk Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+infradead-linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20170209; h=Sender: Content-Transfer-Encoding:Content-Type:Cc:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References: Message-ID:Subject:To:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=yk2N5GB+Ijhp9KeSL0fl9cVkOKhPlSDanHRoa4jPynw=; b=Dqyn95iOSHi3Rm mJW/c58CEPaK51ELIH5/LBzWct2HPtGcHXjl7pHCczxcWxO3b68gaAlikizHfgJbgw6Y3WKYJsXNd Fp09yOdbIBDh97a0g+MpatWfxm3EVyY59He6piyuP3Y3EdHa9Ev8IrkjXiuKJ3ibF0D2DzES5/RuU KYpaaE5ys5a7SvxICbvLkmFhzPe0wLWUk4r44/JFVj5vdUtCi+//QdDTSPyAfQ0kj45O4+hx+GI/b /JsVWn35P2rTX+3XdZlCC90Mgu0qqatby5TcL2kAcPAANhZ+VakzpFoe6PumlnItzTMORqt6/YC5A EH2u7Hf3XUJlwM7SaOSw==; Received: from localhost ([127.0.0.1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1jMstS-00039K-28; Fri, 10 Apr 2020 12:36:22 +0000 Received: from pandora.armlinux.org.uk ([2001:4d48:ad52:3201:214:fdff:fe10:1be6]) by bombadil.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1jMstP-0000Ve-0O for linux-arm-kernel@lists.infradead.org; Fri, 10 Apr 2020 12:36:20 +0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=armlinux.org.uk; s=pandora-2019; h=Sender:In-Reply-To:Content-Type: MIME-Version:References:Message-ID:Subject:Cc:To:From:Date:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=E1lO6MOH92TXjApRphPPU5REy5FFZ6ZxwRqdljo4K0I=; b=l4BUxrAoEycXsvzjLPbLhvRWn YmPDjlzo97j79NsDCZtIMpz+tOfJ6KLwqm+t16Gc3OahvC/q8epEK3btHhPJNFVvr2sM8sdKkSn0O 4dqEY51qKb2+5UdFgeMYM+wTw0sXrrvHXl39ewXQXl5F0x5+LLa2OlyZWp7kIhy4tA3+R0NzIIOgN kItZyIUPPxOA1wiAS+fi/bo/hE4vTQXzskPL5uLJRtijka6wht30pxwQV3PLU/MYve1PNywLKPCPg CFQndh/X1J624Qe8ASBS0LUWvin4+mitfm5r9Ev/oGnDniUty9HF16ILDX85hnwTYHwUrPUbXS9b1 IcuRBqUUA==; Received: from shell.armlinux.org.uk ([2001:4d48:ad52:3201:5054:ff:fe00:4ec]:36520) by pandora.armlinux.org.uk with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.90_1) (envelope-from ) id 1jMsqM-0001Tt-Nz; Fri, 10 Apr 2020 13:33:10 +0100 Received: from linux by shell.armlinux.org.uk with local (Exim 4.92) (envelope-from ) id 1jMsqD-0003m7-Pl; Fri, 10 Apr 2020 13:33:01 +0100 Date: Fri, 10 Apr 2020 13:33:01 +0100 From: Russell King - ARM Linux admin To: Ard Biesheuvel Subject: Re: [PATCH] ARM: do not assemble iwmmxt.S with LLVM toolchain Message-ID: <20200410123301.GX25745@shell.armlinux.org.uk> References: <20200409232728.231527-1-caij2003@gmail.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20200410_053619_051873_FE4D3AAD X-CRM114-Status: GOOD ( 22.08 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Linus Walleij , Peter Smith , Stefan Agner , David Howells , Mauro Carvalho Chehab , Manoj Gupta , Benjamin Gaignard , "Joel Fernandes \(Google\)" , Jian Cai , Bartosz Golaszewski , Ilie Halip , Masahiro Yamada , Krzysztof Kozlowski , clang-built-linux , Sami Tolvanen , Masami Hiramatsu , Arnd Bergmann , "Steven Rostedt \(VMware\)" , jiancai@google.com, Doug Anderson , Dan Williams , Linux ARM , Greg Kroah-Hartman , Nick Desaulniers , "linux-kernel@vger.kernel.org" , Patrick Bellasi , "Eric W. Biederman" , Tejun Heo , Andrew Morton Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+infradead-linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Fri, Apr 10, 2020 at 01:15:08PM +0200, Ard Biesheuvel wrote: > On Fri, 10 Apr 2020 at 11:56, Arnd Bergmann wrote: > > > > On Fri, Apr 10, 2020 at 1:28 AM Jian Cai wrote: > > > > > > iwmmxt.S contains XScale instructions LLVM ARM backend does not support. > > > Skip this file if LLVM integrated assemmbler or LLD is used to build ARM > > > kernel. > > > > > > Signed-off-by: Jian Cai > > > > It clearly makes sense to limit the Kconfig option to compilers that > > can actually build it. > > A few questions though: > > > > - Given that Armada XP with its PJ4B was still marketed until fairly > > recently[1], > > wouldn't it make sense to still add support for it? Is it a lot of work? > > > > The part of that file that the assembler chokes on hasn't been touched > by anyone since Nico added it 15+ years ago. It can only be built in > ARM mode, and it disassembles to the sequence below (the ld/st fe/fp > mnemonics are not document in recent versions of the ARM ARM, and > aren't understood by Clang either) For older CPUs, it doesn't matter what the latest ARM ARM says, the appropriate version of the ARM ARM is the one relevant for the CPU architecture. This is a mistake frequently made, and it's been pointed out by Arm Ltd in the past (before ARMv6 even came on the scene) that keeping older revisions is necessary if you want to be interested in the older architectures. However, there's an additional complication here: DEC's license from Arm Ltd back in the days of StrongARM allowed them to make changes to the architecture - that was passed over to Intel when they bought that part of DEC. Consequently, these "non-Arm vendor" cores contain extensions that are not part of the ARM ARM. iWMMXT is one such example, which first appeared in the Intel PXA270 SoC (an ARMv5 derived CPU). In fact, several of the features found in later versions of the ARM architecture came from DEC and Intel enhancements. If your compiler/assembler only implements what is in the latest ARM ARM, then it is not going to be suitable for these older CPUs and alternate vendor "ARM compatible" CPUs. > Instead of playing all these tricks with Kconfig, couldn't we simply > insert the bare opcodes and be done with it? That gets close to a GPL violation; the GPL requires that source code be in the preferred form for making modifications. Encoding raw opcodes can in no way be argued to be the preferred form. Arguing that raw opcodes is acceptable sets a precedent that makes it acceptable for other "works" to do the same, which makes arguments against firmware supplied as a hexdump null and void. Using macros to emulate the instructions and create the appropriate opcodes is an alternative; we already have that for some of the VFP code as early toolchains had no support for the VFP instructions. So no, bare opcodes are unacceptable. -- RMK's Patch system: https://www.armlinux.org.uk/developer/patches/ FTTC broadband for 0.8mile line in suburbia: sync at 10.2Mbps down 587kbps up _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel