Received: by 2002:ac0:a5a6:0:0:0:0:0 with SMTP id m35-v6csp1722991imm; Thu, 27 Sep 2018 01:13:35 -0700 (PDT) X-Google-Smtp-Source: ACcGV61Si5WWBLJRPucA5RcAgBx93tvShNQt0RwSN8AfWjT4414ubEkTSAQD8E8sC+ks5EQaw2sm X-Received: by 2002:a63:1566:: with SMTP id 38-v6mr9034631pgv.383.1538036015044; Thu, 27 Sep 2018 01:13:35 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1538036015; cv=none; d=google.com; s=arc-20160816; b=Vd4E3UU8W7nLipkd7dBn3AZlcTX9HaQAOF0/TEG1mijOk8iG3Ew5XPlW6z3+ScgJZU TPLVpYm3lbV4UHzc9wCp5AJHPG7r95Y7Yv0g1oKAqI32PN69cpAQYU/QegrjF9NmVfOb djlOXWxkUhSxs+xYyKa5ErwDaqOLNCrx/I0Fbk6pbjecRenata+dRKZwwOaZ+oMuECYM 4E+ihjPiV4P8ZXXkuRkRIvoLmwwydGXEtljj8F16hSMdmwtKNAv+DwL2iA+e02CaHoyT a8FRNJjX/AM8lrXL+jFThjvJZuVSVaZHL1GjxYUz3S2+UX7fKMJMfvB1Ns16lP2Rfig9 Y7OQ== 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; bh=/qv9sE0Qm1OC4lFkYxmiapck87Vo/EQgaGYsyEAVC/c=; b=pKQsxHedKum8erkY5Gywm0ZJ4RXuWOFwZcpEXvSlKxP3UhgqliuY50twLU25+6uO6V hNlJZOWd9uKZ5VyNr+KC6UvquO6AWQtoBbpbHJwGGBDHhyo5nGIR1iYSdkjoqsw7akhZ r8kKfTjEm2iAPhw3xrZkqtD6ExLsHe1Au0gQRNp0hXngGUHlvoz1gXsEG0vlDuViYNWV kl4sGMJZY2jM9X+0iK0vIZeHHt8N7+4K7aE92tnVQE7s8WYrwI1yJqOM2HPv9QNKsjNN WtNyQh26XYhEWfSI274c3rB3EkmNGZ3KBvwsfk2ivP1HaSrgsIzrzk3XfLeTEXCodNlp SzVA== 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 x10-v6si6162pll.88.2018.09.27.01.13.19; Thu, 27 Sep 2018 01:13:35 -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 S1727241AbeI0O31 (ORCPT + 99 others); Thu, 27 Sep 2018 10:29:27 -0400 Received: from smtp2200-217.mail.aliyun.com ([121.197.200.217]:41688 "EHLO smtp2200-217.mail.aliyun.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726760AbeI0O30 (ORCPT ); Thu, 27 Sep 2018 10:29:26 -0400 X-Alimail-AntiSpam: AC=CONTINUE;BC=0.07442137|-1;CH=green;FP=0|0|0|0|0|-1|-1|-1;HT=e02c03307;MF=ren_guo@c-sky.com;NM=1;PH=DS;RN=20;RT=20;SR=0;TI=SMTPD_---.CwTEhM2_1538035902; Received: from localhost(mailfrom:ren_guo@c-sky.com fp:SMTPD_---.CwTEhM2_1538035902) by smtp.aliyun-inc.com(10.147.41.121); Thu, 27 Sep 2018 16:11:42 +0800 Date: Thu, 27 Sep 2018 16:11:42 +0800 From: Guo Ren To: Peter Zijlstra Cc: akpm@linux-foundation.org, arnd@arndb.de, daniel.lezcano@linaro.org, davem@davemloft.net, gregkh@linuxfoundation.org, jason@lakedaemon.net, marc.zyngier@arm.com, mark.rutland@arm.com, mchehab+samsung@kernel.org, robh@kernel.org, robh+dt@kernel.org, tglx@linutronix.de, linux-kernel@vger.kernel.org, linux-arch@vger.kernel.org, devicetree@vger.kernel.org, c-sky_gcc_upstream@c-sky.com, gnu-csky@mentor.com, green.hu@gmail.com, palmer@sifive.com Subject: Re: [PATCH V5 06/30] csky: Cache and TLB routines Message-ID: <20180927081138.GA308@guoren> References: <7cd7abcd2acf5c61435589338ff80a75a13173ca.1537789737.git.ren_guo@c-sky.com> <20180925072407.GA6999@hirez.programming.kicks-ass.net> <20180927052737.GA28407@guoren> <20180927070859.GC5254@hirez.programming.kicks-ass.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20180927070859.GC5254@hirez.programming.kicks-ass.net> 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 Thu, Sep 27, 2018 at 09:08:59AM +0200, Peter Zijlstra wrote: > On Thu, Sep 27, 2018 at 01:27:38PM +0800, Guo Ren wrote: > > On Tue, Sep 25, 2018 at 09:24:07AM +0200, Peter Zijlstra wrote: > > > On Mon, Sep 24, 2018 at 10:36:22PM +0800, Guo Ren wrote: > > > > diff --git a/arch/csky/abiv1/inc/abi/cacheflush.h b/arch/csky/abiv1/inc/abi/cacheflush.h > > > > new file mode 100644 > > > > index 0000000..f0de49c > > > > --- /dev/null > > > > +++ b/arch/csky/abiv1/inc/abi/cacheflush.h > > > > > +#define flush_cache_range(mm,start,end) cache_wbinv_range(start, end) > > > ^^^ should be vma > > Yes, I'll change it to: > > #define flush_cache_range(mm,start,end) cache_wbinv_all() > > > > I'll improve it later after test. > > That's not what I meant; I meant you need something like: > > #define flush_cache_range(vma, start, end) cache_wbinv_range(start, end) If you remove the tlb_start_vma in my tlb.h, I want to use cache_wbinv_all() is more safe. And I'll improve it in future. My cache_wbinv_range(start, end) won't care vma->mm's asid and they just use current asid in mmu reg. If current_mm != vma->mm, then flush_cache_range will be broken. Perhaps, I need improve flush_cache_range first ... > > The first argument is a vma, not an mm. Yes, vma! My fault :-P > > > Also, I'll be shortly removing this: > > > > > > https://lkml.kernel.org/r/20180913092812.071989585@infradead.org > > Ok, I'll follow the rules. > > > > > > diff --git a/arch/csky/abiv2/inc/abi/cacheflush.h b/arch/csky/abiv2/inc/abi/cacheflush.h > > > > new file mode 100644 > > > > index 0000000..756beb7 > > > > --- /dev/null > > > > +++ b/arch/csky/abiv2/inc/abi/cacheflush.h > > > > @@ -0,0 +1,40 @@ > > > > > +#define flush_cache_range(vma, start, end) do { } while (0) > > > ^^^ like here.. > > #define flush_cache_range(vma, start, end) \ > > do { \ > > if (vma->vm_flags & VM_EXEC) \ > > icache_inv_all(); \ > > } > > > > Hmm ? > > > > For v2, which IIUC is PIPT (as opposed to v1 which is VIPT), what you > had was correct. I'll improve icache_inv_all() with flush_range() in future. > > I was merely pointing out that the flush_cache_range() definition was > inconsitent between v1 and v2; v1 using @mm and v2 using @vma for the > first argument. Must be vma, you are right. And I know it's a vma in mind, but fault in code. Thx for your review. Best Regards Guo Ren