From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from server1.serv-net.de (31.204.203.213.rev.inetbone.net [213.203.204.31]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by ozlabs.org (Postfix) with ESMTP id 52687685ED for ; Sat, 22 Oct 2005 04:28:09 +1000 (EST) From: Rupert Eibauer To: Kumar Gala Date: Fri, 21 Oct 2005 20:43:16 +0200 References: <200510211417.49651.rupert@ces.ch> <200510211711.02997.rupert@ces.ch> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Message-Id: <200510212043.18615.rupert@ces.ch> Cc: linuxppc-dev@ozlabs.org Subject: Re: [PATCH][RFT] please use this one List-Id: Linux on PowerPC Developers Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , On Friday 21 October 2005 17:23, Kumar Gala wrote: > > On Oct 21, 2005, at 10:11 AM, Rupert Eibauer wrote: > > > On Friday 21 October 2005 16:28, Kumar Gala wrote: > > > >> The concept of PPC_HIGH_BATS is already some what handled with > >> CPU_FTR_HAS_HIGH_BATS. I recommend you use this feature instead of > >> introducing another one as well as a compile time option. > >> > > > > CPU_FTR_HAS_HIGH_BATS only clears the high bats, but does > > not attempt to use them. My patch will use them. > > I understand, I'm suggesting you expand CPU_FTR_HAS_HIGH_BATS to > include your additional functionality. How do you mean that exactly? Do you mean making the feature always-on (not selectable in Kconfig)? Having CONFIG_PPC_LARGE_BATS and CONFIG_HIGH_PATS always-on would be ok for me, but for PHYS_64BIT should be left up to the platform to decide if it should be presented to the user or not. Do you think the other two features, CPU_FTR_BIG_PHYS and CPU_FTR_LARGE_BATS should be merged into one bit? They could for now, because there is no processor supporting only one of them. Rupert > > - kumar