From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-15.3 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_CR_TRAILER,INCLUDES_PATCH, MAILING_LIST_MULTI,NICE_REPLY_A,SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id CE760C433ED for ; Tue, 20 Apr 2021 04:56:23 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 8EE62613B0 for ; Tue, 20 Apr 2021 04:56:23 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229950AbhDTE4x (ORCPT ); Tue, 20 Apr 2021 00:56:53 -0400 Received: from pegase1.c-s.fr ([93.17.236.30]:3843 "EHLO pegase1.c-s.fr" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229553AbhDTE4p (ORCPT ); Tue, 20 Apr 2021 00:56:45 -0400 Received: from localhost (mailhub1-int [192.168.12.234]) by localhost (Postfix) with ESMTP id 4FPWb91nFPz9vBKZ; Tue, 20 Apr 2021 06:55:33 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at c-s.fr Received: from pegase1.c-s.fr ([192.168.12.234]) by localhost (pegase1.c-s.fr [192.168.12.234]) (amavisd-new, port 10024) with ESMTP id ie5cxGwG9F7s; Tue, 20 Apr 2021 06:55:33 +0200 (CEST) Received: from messagerie.si.c-s.fr (messagerie.si.c-s.fr [192.168.25.192]) by pegase1.c-s.fr (Postfix) with ESMTP id 4FPWb90hkBz9vBKT; Tue, 20 Apr 2021 06:55:33 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by messagerie.si.c-s.fr (Postfix) with ESMTP id C58218B7D6; Tue, 20 Apr 2021 06:55:33 +0200 (CEST) X-Virus-Scanned: amavisd-new at c-s.fr Received: from messagerie.si.c-s.fr ([127.0.0.1]) by localhost (messagerie.si.c-s.fr [127.0.0.1]) (amavisd-new, port 10023) with ESMTP id wk-bweOaRv6E; Tue, 20 Apr 2021 06:55:33 +0200 (CEST) Received: from [192.168.4.90] (unknown [192.168.4.90]) by messagerie.si.c-s.fr (Postfix) with ESMTP id 3642D8B7CB; Tue, 20 Apr 2021 06:55:33 +0200 (CEST) Subject: Re: PPC_FPU, ALTIVEC: enable_kernel_fp, put_vr, get_vr To: Randy Dunlap , Michael Ellerman , Segher Boessenkool Cc: PowerPC , LKML References: <7107fcae-5c7a-ac94-8d89-326f2cd4cd33@infradead.org> <8b1cb0a2-ed3a-7da0-a73a-febbda528703@csgroup.eu> <20210418174648.GN26583@gate.crashing.org> <87sg3mct3x.fsf@mpe.ellerman.id.au> From: Christophe Leroy Message-ID: <1f337b4c-940e-110c-d0a2-2ad95cfb2dc8@csgroup.eu> Date: Tue, 20 Apr 2021 06:55:32 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: fr Content-Transfer-Encoding: 8bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Le 19/04/2021 à 23:39, Randy Dunlap a écrit : > On 4/19/21 6:16 AM, Michael Ellerman wrote: >> Randy Dunlap writes: > >>> Sure. I'll post them later today. >>> They keep FPU and ALTIVEC as independent (build) features. >> >> Those patches look OK. >> >> But I don't think it makes sense to support that configuration, FPU=n >> ALTVEC=y. No one is ever going to make a CPU like that. We have enough >> testing surface due to configuration options, without adding artificial >> combinations that no one is ever going to use. >> >> IMHO :) >> >> So I'd rather we just make ALTIVEC depend on FPU. > > That's rather simple. See below. > I'm doing a bunch of randconfig builds with it now. > > --- > From: Randy Dunlap > Subject: [PATCH] powerpc: make ALTIVEC depend PPC_FPU > > On a kernel config with ALTIVEC=y and PPC_FPU not set/enabled, > there are build errors: > > drivers/cpufreq/pmac32-cpufreq.c:262:2: error: implicit declaration of function 'enable_kernel_fp' [-Werror,-Wimplicit-function-declaration] > enable_kernel_fp(); > ../arch/powerpc/lib/sstep.c: In function 'do_vec_load': > ../arch/powerpc/lib/sstep.c:637:3: error: implicit declaration of function 'put_vr' [-Werror=implicit-function-declaration] > 637 | put_vr(rn, &u.v); > | ^~~~~~ > ../arch/powerpc/lib/sstep.c: In function 'do_vec_store': > ../arch/powerpc/lib/sstep.c:660:3: error: implicit declaration of function 'get_vr'; did you mean 'get_oc'? [-Werror=implicit-function-declaration] > 660 | get_vr(rn, &u.v); > | ^~~~~~ > > In theory ALTIVEC is independent of PPC_FPU but in practice nobody > is going to build such a machine, so make ALTIVEC require PPC_FPU > by depending on PPC_FPU. > > Signed-off-by: Randy Dunlap > Reported-by: kernel test robot > Cc: Michael Ellerman > Cc: linuxppc-dev@lists.ozlabs.org > Cc: Christophe Leroy > Cc: Segher Boessenkool > Cc: lkp@intel.com > --- > arch/powerpc/platforms/86xx/Kconfig | 1 + > arch/powerpc/platforms/Kconfig.cputype | 2 ++ > 2 files changed, 3 insertions(+) > > --- linux-next-20210416.orig/arch/powerpc/platforms/86xx/Kconfig > +++ linux-next-20210416/arch/powerpc/platforms/86xx/Kconfig > @@ -4,6 +4,7 @@ menuconfig PPC_86xx > bool "86xx-based boards" > depends on PPC_BOOK3S_32 > select FSL_SOC > + select PPC_FPU > select ALTIVEC > help > The Freescale E600 SoCs have 74xx cores. > --- linux-next-20210416.orig/arch/powerpc/platforms/Kconfig.cputype > +++ linux-next-20210416/arch/powerpc/platforms/Kconfig.cputype > @@ -186,6 +186,7 @@ config E300C3_CPU > config G4_CPU > bool "G4 (74xx)" > depends on PPC_BOOK3S_32 > + select PPC_FPU > select ALTIVEC > > endchoice > @@ -309,6 +310,7 @@ config PHYS_64BIT > > config ALTIVEC > bool "AltiVec Support" > + depends on PPC_FPU Shouldn't we do it the other way round ? In extenso make ALTIVEC select PPC_FPU and avoid the two selects that are above ? > depends on PPC_BOOK3S_32 || PPC_BOOK3S_64 || (PPC_E500MC && PPC64) > help > This option enables kernel support for the Altivec extensions to the >