Received: by 2002:a25:8b91:0:0:0:0:0 with SMTP id j17csp6319956ybl; Wed, 15 Jan 2020 02:40:31 -0800 (PST) X-Google-Smtp-Source: APXvYqzr2MSJU6BYgU9Zt7YZRnFsniimULUJ1p/2n1GmzXDmANgGm4fBMvRIildv/Ic9jb/N1imo X-Received: by 2002:aca:c386:: with SMTP id t128mr21030077oif.32.1579084827200; Wed, 15 Jan 2020 02:40:27 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1579084827; cv=none; d=google.com; s=arc-20160816; b=V00LT3EiNTjBTsq22x1JTGPAJcePd0G94IYxxVG4zinM8pEI2dO03Fi51F9VrYp9q4 LyOnFvKDURY2vJw7GyAqHY1vV+C8BQb8cV4XOZZ+gKmNvYhQ/TpxifGXlyLgIiS6UPuN h3nwTFKSZp+rDTHAS8YynsN4AF/+vXNQZ1jtqdkluCIUcZ1mh/5qOZyiGlkxzx7nj0Pf fed+HLpGj9Q1CLE2VKQY6xbilnb42lBmXu3sITLW+YE84MRoZA2oAYctRKHlDKZ+NIHI 39N7bRZqRJWiurm0spEuNsrjYmGfDJ0MuFz+rscTt1ItRhwPVt2kAhJMBUWP4Hb2uUUU A5Sg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version; bh=QPOZMPuD9cnDtoBOW5Kihw7wzCHrb/ZPuv7Mj6/jvH8=; b=Wk1FAsX1Ol35zi+rd1iGpLsHVp/30p/X9h5vC8kurq742ac5IH/BZCSu1WsRKlQ0/Q tIIaDv6Vppj2VQaGGmPKFbndx6hIqvDgiKTPh4yZs0NjAEi+qX2zEWrvkeOYa9olyKfg UPklKJiVpkJ9W8ppd2qgqxriUq1LXtk5mQkb0E4DMSaIar6MHDooPnVI7x+p0jju+lbo ufJowD0+/GdwoNgmEGbQorqqv8mL+RCT9An4INFJvjtqdK2jLH3boddL2md412Jkp96X IzWcoWCtVSPNIEllgGRKb4jVT6rll83wWnW47kP4sdjuNndxzniEg9ab4s4UkTvu2ToL 5XKw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id n11si9691640otk.290.2020.01.15.02.40.14; Wed, 15 Jan 2020 02:40:27 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729809AbgAOKjS (ORCPT + 99 others); Wed, 15 Jan 2020 05:39:18 -0500 Received: from mout.kundenserver.de ([212.227.126.130]:53007 "EHLO mout.kundenserver.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1729674AbgAOKjR (ORCPT ); Wed, 15 Jan 2020 05:39:17 -0500 Received: from mail-qk1-f181.google.com ([209.85.222.181]) by mrelayeu.kundenserver.de (mreue009 [212.227.15.129]) with ESMTPSA (Nemesis) id 1MfYHQ-1jK98e08lM-00fy1R for ; Wed, 15 Jan 2020 11:39:16 +0100 Received: by mail-qk1-f181.google.com with SMTP id z76so15167024qka.2 for ; Wed, 15 Jan 2020 02:39:15 -0800 (PST) X-Gm-Message-State: APjAAAUJyMhBrQCb0ijJ8fpQNRTuEJo+3tAKmD1eXCmZhyRomtJGdmp/ LdIuISTlBIw3TxcxH/f5Hs+nBNFEaA/VXtuqkYQ= X-Received: by 2002:a05:620a:a5b:: with SMTP id j27mr26649069qka.286.1579084754892; Wed, 15 Jan 2020 02:39:14 -0800 (PST) MIME-Version: 1.0 References: <1578989048-10162-1-git-send-email-peng.fan@nxp.com> <20200114081751.3wjbbnaem7lbnn3v@pengutronix.de> In-Reply-To: From: Arnd Bergmann Date: Wed, 15 Jan 2020 11:38:58 +0100 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH] soc: imx: Makefile: only build soc-imx8 when CONFIG_ARM64 To: Peng Fan Cc: =?UTF-8?Q?Uwe_Kleine=2DK=C3=B6nig?= , Abel Vesa , Anson Huang , "festevam@gmail.com" , "s.hauer@pengutronix.de" , "linux-kernel@vger.kernel.org" , dl-linux-imx , "kernel@pengutronix.de" , Leonard Crestez , "shawnguo@kernel.org" , "linux-arm-kernel@lists.infradead.org" Content-Type: text/plain; charset="UTF-8" X-Provags-ID: V03:K1:M3WXBTgV7oMTr+ED3aDHzGcAQ7MNA0LQ1Ok0eXXCAQeJYZNjUcH u6YYu43a5itPzEAYlsVDYi16F9M7J3DH6oroFFGlZEubH8Vt2ER2T9iYZ732VBhpAi2pEyh Cn6eUyBFh9bkjnhom3Ptkvxnc70hgpY6OzswkrudMK9AEMumoHtpicOl8l9ONgioLDniBMH GcUavoBL2+/o9cuGNq1Eg== X-Spam-Flag: NO X-UI-Out-Filterresults: notjunk:1;V03:K0:g7rIzxU9364=:aiDvK4QEbUHTuBstitYR80 rJ4AFfMet/s6XKoSTLd5mT4qq8I/yjPADNQniWWN1dhogNAiQZG9Q5DY1NQ9RLhxVbrpE9goU 7Vs5e7lEXzu2JyD3X9JAaHTGPE5MHeLsYbgtEHenZFcJiWlLW6QuGbpGf4MF9UY570+ElDOp+ J8DssLcBf8xdgpYJyliP7lGE0+vKKaCanyRXvf4JwVn842vdiTWNKLxsTPz8SmqUgVpdzaJRn u1C7hH/+PYppfbuzANbCh3qa3KMbd0N7yPEKmFTBR757GwPlASluJlRKeQZoPiLBdNQgOmUuy rW2H/v6/lzwDlZQPQxc+AOtiBRFpc0YF9EFOilR7m4BTBBzTvyAI1XzJ53SZJVh8V964VhaWN Lv5rfJg3yhTzl0+kLiANPFeNQVTwakrEGKMAfaUpNDiW9mj2ShxUWybPv3l9RTmh7kNm4Qwdu 16O3whp4c6eWKD9VT11WLz8UN0bHqkRVdi7HAx7645KbiFJtjxS3yK6zkqLg+eSvcwJYHRBoe UdLVTjAMjmw2L1pcQbh9EixR0O0wrfV/4K1vcul1MLTX+Z/zYfXO2akCqlM3jKZiaSKbtIALd 6TZVvF9IsUxkFoz8CUI1hoJyipR7Suo5DEYr9piH0ASMANdu1CwyS97WGmwtlEuUvQVksQ8bz MyaNMcwhoeHKLYImPuaS3spBt/qx7YkxzPX64ygpNvVqR+VpeOYE14QIbiFqB6iE6pmUJ5asg UXh06Yiv+MjmlaB0g7TyPIre5xMs4oJAYyBMt9R8WxBXGlu3veWM92dN1mL/hmOYPUSwTtSp6 h4+tAvIvUbiX1ziWP51ma6A1sVQ2AXAfC93JRTWS7tMo00M+CjuqcMLLNHT8cf6kd1dsGKavn 613JtaWo7GNXZRYgR11g== Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Jan 15, 2020 at 3:38 AM Peng Fan wrote: > > Subject: Re: [PATCH] soc: imx: Makefile: only build soc-imx8 when CONFIG_ARM64 > > On Tue, Jan 14, 2020 at 9:32 AM Peng Fan wrote: > > > > Subject: Re: [PATCH] soc: imx: Makefile: only build soc-imx8 when > > > > > > There is no SOC_IMX8 currently. Need to introduce one in > > > arch/arm64/Kconfig.platforms. But I not see other vendors introduce > > > options like SOC_XX. Is this the right direction to add one in > > > Kconfig.platforms? > > > > I think it would be more consistent with the other platforms to have a symbol > > in drivers/soc/imx/Kconfig to control whether we build that driver. > > Ok, I'll add Kconfig entry in drivers/soc/imx/Kconfig for various i.MX SoCs. I was thinking of one entry for this driver. > > For some SoCs, we also allow running 32-bit kernels, so it would not be wrong > > to allow enabling the symbol on 32-bit ARM as well, but this is probably > > something where you want to consider the bigger picture to see if you want > > to support that configuration or not. > > Does the current upstream kernel support 32bit kernels on ARM64 platforms > without vendor specific stuff. I recalled that several years ago, NXP people > tried to upstream 32bit kernel support, but rejected by you. We have at least some Broadcom SoCs that are supported this way. As long as you can use the same dtb file on a regular multi_v7_defconfig I see no problem with doing this. What I would like to avoid though are ports that require extra code in arch/arm/mach-* that is not needed for the 64-bit target, or ports to 64-bit hardware that only run in 32-bit mode. > So Is there any plan to support 32bit kernel on AARCH64 in upstream > kernel? > Or any suggestions? I don't think there should be 32-bit kernel running in aarch64-ilp32 mode. This was discussed way back when the aarch64-ilp32 user space patches first appeared. Generally speaking you are usually better off running an aarch64 kernel using aarch32 user space, but there may be reasons for running an ARMv8 aarch32 kernel on the same hardware and there is no technical reason why this shouldn't work for a clean port. We never really supported ARMv8-aarch32 in arch/arm/ as a separate target, but usually building an ARMv7 kernel is close enough to ARMv8-aarch32 that things just work. If you would like to help out making ARMv7VE and ARMv8-aarch64 proper targets for arch/arm/, let me know and we can discuss what parts are missing. Arnd