Received: by 10.213.65.68 with SMTP id h4csp215377imn; Mon, 26 Mar 2018 19:40:58 -0700 (PDT) X-Google-Smtp-Source: AG47ELvu4INJd8kM40V1ZOy28K/44BlJyt5E0+Y3PPue3Qim/DzKct2+T59WsHRfd/TtbVF1GEoF X-Received: by 2002:a17:902:20e6:: with SMTP id v35-v6mr43089515plg.226.1522118458128; Mon, 26 Mar 2018 19:40:58 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1522118458; cv=none; d=google.com; s=arc-20160816; b=Ice2OP6lVDiD1BZV/4Lnvc0hL36XJDhA9Z9sonNczV71EdkGlzatHcjTz2VtCJXqVl K1PK/TI23/WzWo7qlY5aps3bkgYCzU5rvXHh/PKrcm+yvt5+vm182uoZ6S1sQYN+DaMh U/2PwLpVd4r33bmP/DzwRl5TaPOwTbyC9SlBR04wJ1iHLw6Yx9jwhPNLoXEoG20RAL2Q Nj/1zqRFZJsn6zEPe+a1yiwM0hK5tJhBA2ynaxiEb+4m3jNJRA8ushqHTwO4ekY+22Yg tnVjsBENK2PU+snEED5i6IQbyHFT/MWg0Mu7pA0eyOlk1YX//o40POlG/tPNMlQxWmIr JE/w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:arc-authentication-results; bh=n9jtjQMz+uYLaBXE1zWp9ZIH0xXzKGqx4xq7aIf/Wlk=; b=NQICCjc10X57G5O2KPeC9F6RkIzyQrjLLSyqI8rHpi9mpXyaAU4d+BIMBjNasNC/oF NeohfCOreT516ekMNWd49Xv881b8L6vQUVMjhxbBehKpG9WNmEqvooS23Ux8DoUk/1yw XCEUlmGhIGsWnwcDNPZCQA8okdsKogkoZrC4a0lz2tD4/kjf6xhauJqd7D4bjlTJbbhe 4BI2LxgbzNjK7AT7APvb0lqTFDvOcn+TUAjHW3ISEz1OW3133uXzfBdd3C/e2EzuIXlw Xproh6oP9LltQVEsckupldKctpXTPon50KDp5YIUqBFqtTfHeXZhIAL0KuyeX8D1VA+t B+1Q== 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 m11-v6si209205pls.337.2018.03.26.19.40.44; Mon, 26 Mar 2018 19:40:58 -0700 (PDT) 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 S1752305AbeC0Cjm (ORCPT + 99 others); Mon, 26 Mar 2018 22:39:42 -0400 Received: from smtp2200-217.mail.aliyun.com ([121.197.200.217]:47610 "EHLO smtp2200-217.mail.aliyun.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752027AbeC0Cjk (ORCPT ); Mon, 26 Mar 2018 22:39:40 -0400 X-Alimail-AntiSpam: AC=CONTINUE;BC=0.08084413|-1;CH=green;FP=0|0|0|0|0|-1|-1|-1;HT=e02c03301;MF=ren_guo@c-sky.com;NM=1;PH=DS;RN=10;RT=10;SR=0;TI=SMTPD_---.BSY93rB_1522118369; Received: from localhost(mailfrom:ren_guo@c-sky.com fp:223.93.147.148) by smtp.aliyun-inc.com(10.147.40.7); Tue, 27 Mar 2018 10:39:29 +0800 Date: Tue, 27 Mar 2018 10:39:29 +0800 From: Guo Ren To: Arnd Bergmann Cc: linux-arch , Linux Kernel Mailing List , Thomas Gleixner , Daniel Lezcano , Jason Cooper , c-sky_gcc_upstream@c-sky.com, gnu-csky@mentor.com, thomas.petazzoni@bootlin.com, wbx@uclibc-ng.org Subject: Re: [PATCH 15/19] csky: Build infrastructure Message-ID: <20180327023927.GA11454@guoren> References: <20180320131342.GA31542@guoren> <20180321124137.GA21320@guoren> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Mar 26, 2018 at 03:00:00PM +0200, Arnd Bergmann wrote: > Ok, I understand the part about ck610 being incompatible, but I'm > still not sure about the 8xx ones: Do you mean it's impossible to > have one kernel that runs across all of them for some other reason, > or is it something you haven't allowed because you see no use for it? Sorry, Csky gcc need "-mcpu=ck807" or "-mcpu=ck810" or "-mcpu=ck860" to determine the back-end policy. So I must seperate them with different vmlinux. > This is basically the same question as above: For c610, using the fixed > value is sufficient, because it's incompatible with the others. But if you want > to run the same kernel on both ck810 and ck860, then it needs some form > of runtime detection. Sorry, currently no runtime detection. But I agree with you that one vmlinux for all cpus is a good design for compat. > On other architectures, the L1_CACHE_BYTES constant is the maximum > possible cache line size, and the cache flush function uses the actual size The same with above, we don't detect cpus on runtime. So we just make it simple here. > Ok. Just make sure that the DT always has this information as well, > so this can be changed in the future when desired, without having to > make incompatible changes to the devicetree binary files. Ok Best Regards Guo Ren