From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S261976AbVDLFrq (ORCPT ); Tue, 12 Apr 2005 01:47:46 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S262022AbVDLFrJ (ORCPT ); Tue, 12 Apr 2005 01:47:09 -0400 Received: from az33egw01.freescale.net ([192.88.158.102]:9864 "EHLO az33egw01.freescale.net") by vger.kernel.org with ESMTP id S261976AbVDLFm4 convert rfc822-to-8bit (ORCPT ); Tue, 12 Apr 2005 01:42:56 -0400 In-Reply-To: <1113272915.5388.37.camel@gaston> References: <1113272915.5388.37.camel@gaston> Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=ISO-8859-1; format=flowed Message-Id: Content-Transfer-Encoding: 8BIT Cc: "Kumar Gala" , "Andrew Morton" , "Linux Kernel list" , "linuxppc-dev list" , "linuxppc-embedded" , "Jason McMullan" From: Kumar Gala Subject: Re: [PATCH] ppc32: refactor FPU exception handling Date: Tue, 12 Apr 2005 00:42:36 -0500 To: "Benjamin Herrenschmidt" X-Mailer: Apple Mail (2.619.2) Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Ben, Sorry about that, we have had some back and forth on this on the ppc embedded list. Not sure I understand your concern about the duplication of the fast exception return path? Jason's patch pretty much just moved code out of head.S into fpu.S so we dont duplicate it between head.S and head_44x.S & head_fsl_booke.S - kumar On Apr 11, 2005, at 9:28 PM, Benjamin Herrenschmidt wrote: > On Mon, 2005-04-11 at 17:02 -0500, Kumar Gala wrote: > > Andrew, > > > > Moved common FPU exception handling code out of head.S so it can be > used > > by several of the sub-architectures that might of a full PowerPC > FPU.  > > > > Also, uses new CONFIG_PPC_FPU define to fix alignment exception > > handling for floating point load/store instructions to only occur if > we > > have a hardware FPU. > > > > Signed-off-by: Jason McMullan > > Signed-off-by: Kumar Gala > > > > Andrew, please hold on this patch, it hasn't been properly discussed > with the relevant maintainer, that is Paul Mackerras. > > I can see matter for debate in there, like the whole duplication of the > fast exception return path... > > It's also touching quite sensitive bits of kernel code (head.S) that > needs careful auditing and testing before beeing pushed upstream. > > Ben.