From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751386AbdBXTVQ (ORCPT ); Fri, 24 Feb 2017 14:21:16 -0500 Received: from mail-pf0-f196.google.com ([209.85.192.196]:34945 "EHLO mail-pf0-f196.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751297AbdBXTVG (ORCPT ); Fri, 24 Feb 2017 14:21:06 -0500 Date: Sat, 25 Feb 2017 04:20:56 +0900 From: Stafford Horne To: Stefan Kristiansson Cc: Jonas Bonn , linux@roeck-us.net, openrisc@lists.librecores.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH v4 05/24] openrisc: head: refactor out tlb flush into it's own function Message-ID: <20170224192056.GO2449@lianli.shorne-pla.net> References: <8c9b7db0de3d64c9a6fcd12622636d4aa6a8c30c.1487910170.git.shorne@gmail.com> <20170224105422.GA21431@chokladfabriken.org> <20170224135401.GB21431@chokladfabriken.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20170224135401.GB21431@chokladfabriken.org> User-Agent: Mutt/1.7.1 (2016-10-04) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Feb 24, 2017 at 03:54:02PM +0200, Stefan Kristiansson wrote: > On Fri, Feb 24, 2017 at 01:48:10PM +0100, Jonas Bonn wrote: > > On 02/24/2017 11:54 AM, Stefan Kristiansson wrote: > > >eOn Fri, Feb 24, 2017 at 10:57:19AM +0100, Jonas Bonn wrote: > > >>On 02/24/2017 05:32 AM, Stafford Horne wrote: > > >>>From: Stefan Kristiansson > > >>> > > >>>This brings it inline with the other setup oprations done like the cache > > >>>enables _ic_enable and _dc_enable. Also, this is going to make it > > >>>easier to initialize additional cpu's when smp is introduced. > > >>This patch confuses me. The TLB flush is moved to a point after MMU's are > > >>enabled. The TLB flush should happen before enabling the MMU, shouldn't it? > > >> > > >It still happens before the MMUs are enabled, the patch only refactors the code > > >out into a function that is called from the place where it was open coded > > >before. > > > > Right. What's the point of moving it then? > > > > As the commit message mentions, it's a preparation patch for initialisation > of secondary cpus, which also will call this function. > > Perhaps this patch should be bundled with those patches. > Thanks for replying on this patch, I think keeping this patch here is ok. Since part of the theme of this series is preparing for SMP (which will be another big series) I think its ok have any non SMP specific work into here. Its going to make my life a bit easier going forward. Also, as this is good refactor to get it structurally in sync with other initializations I think its not completely out of place. -Stafford