PPC_FPU, ALTIVEC: enable_kernel_fp, put_vr, get_vr

PPC_FPU, ALTIVEC: enable_kernel_fp, put_vr, get_vr

[Randy Dunlap]

Hi,

kernel test robot reports:

>> drivers/cpufreq/pmac32-cpufreq.c:262:2: error: implicit declaration of function 'enable_kernel_fp' [-Werror,-Wimplicit-function-declaration]
           enable_kernel_fp();
           ^

when
# CONFIG_PPC_FPU is not set
CONFIG_ALTIVEC=y

I see at least one other place that does not handle that
combination well, here:

../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);
      |   ^~~~~~


Should the code + Kconfigs/Makefiles handle that kind of
kernel config or should ALTIVEC always mean PPC_FPU as well?

I have patches to fix the build errors with the config as
reported but I don't know if that's the right thing to do...

thanks.
-- 
~Randy

PPC_FPU, ALTIVEC: enable_kernel_fp, put_vr, get_vr

[Randy Dunlap]

Hi,

kernel test robot reports:

>> drivers/cpufreq/pmac32-cpufreq.c:262:2: error: implicit declaration of function 'enable_kernel_fp' [-Werror,-Wimplicit-function-declaration]
           enable_kernel_fp();
           ^

when
# CONFIG_PPC_FPU is not set
CONFIG_ALTIVEC=y

I see at least one other place that does not handle that
combination well, here:

../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);
      |   ^~~~~~


Should the code + Kconfigs/Makefiles handle that kind of
kernel config or should ALTIVEC always mean PPC_FPU as well?

I have patches to fix the build errors with the config as
reported but I don't know if that's the right thing to do...

thanks.
-- 
~Randy

Re: PPC_FPU, ALTIVEC: enable_kernel_fp, put_vr, get_vr

[Christophe Leroy]

Le 17/04/2021 à 22:17, Randy Dunlap a écrit :
> Hi,
> 
> kernel test robot reports:
> 
>>> drivers/cpufreq/pmac32-cpufreq.c:262:2: error: implicit declaration of function 'enable_kernel_fp' [-Werror,-Wimplicit-function-declaration]
>             enable_kernel_fp();
>             ^
> 
> when
> # CONFIG_PPC_FPU is not set
> CONFIG_ALTIVEC=y
> 
> I see at least one other place that does not handle that
> combination well, here:
> 
> ../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);
>        |   ^~~~~~
> 
> 
> Should the code + Kconfigs/Makefiles handle that kind of
> kernel config or should ALTIVEC always mean PPC_FPU as well?

As far as I understand, Altivec is completely independant of FPU in Theory. So it should be possible 
to use Altivec without using FPU.

However, until recently, it was not possible to de-activate FPU support on book3s/32. I made it 
possible in order to reduce unneccessary processing on processors like the 832x that has no FPU.
As far as I can see in cputable.h/.c, 832x is the only book3s/32 without FPU, and it doesn't have 
ALTIVEC either.

So we can in the future ensure that Altivec can be used without FPU support, but for the time being 
I think it is OK to force selection of FPU when selecting ALTIVEC in order to avoid build failures.

> 
> I have patches to fix the build errors with the config as
> reported but I don't know if that's the right thing to do...
> 

Lets see them.

Christophe

Re: PPC_FPU, ALTIVEC: enable_kernel_fp, put_vr, get_vr

[Segher Boessenkool]

On Sun, Apr 18, 2021 at 06:24:29PM +0200, Christophe Leroy wrote:
> Le 17/04/2021 à 22:17, Randy Dunlap a écrit :
> >Should the code + Kconfigs/Makefiles handle that kind of
> >kernel config or should ALTIVEC always mean PPC_FPU as well?
> 
> As far as I understand, Altivec is completely independant of FPU in Theory. 

And, as far as the hardware is concerned, in practice as well.

> So it should be possible to use Altivec without using FPU.

Yup.

> However, until recently, it was not possible to de-activate FPU support on 
> book3s/32. I made it possible in order to reduce unneccessary processing on 
> processors like the 832x that has no FPU.

The processor has to implement FP to be compliant to any version of
PowerPC, as far as I know?  So that is all done by emulation, including
all the registers?  Wow painful.

> As far as I can see in cputable.h/.c, 832x is the only book3s/32 without 
> FPU, and it doesn't have ALTIVEC either.

602 doesn't have double-precision hardware, also no 64-bit FP registers.
But that CPU was never any widely used :-)

> So we can in the future ensure that Altivec can be used without FPU 
> support, but for the time being I think it is OK to force selection of FPU 
> when selecting ALTIVEC in order to avoid build failures.

It is useful to allow MSR[VEC,FP]=1,0 but yeah there are no CPUs that
have VMX (aka AltiVec) but that do not have FP.  I don't see how making
that artificial dependency buys anything, but maybe it does?

> >I have patches to fix the build errors with the config as
> >reported but I don't know if that's the right thing to do...

Neither do we, we cannot see those patches :-)


Segher

Re: PPC_FPU, ALTIVEC: enable_kernel_fp, put_vr, get_vr

[Randy Dunlap]

On 4/18/21 10:46 AM, Segher Boessenkool wrote:
> On Sun, Apr 18, 2021 at 06:24:29PM +0200, Christophe Leroy wrote:
>> Le 17/04/2021 à 22:17, Randy Dunlap a écrit :
>>> Should the code + Kconfigs/Makefiles handle that kind of
>>> kernel config or should ALTIVEC always mean PPC_FPU as well?
>>
>> As far as I understand, Altivec is completely independant of FPU in Theory. 
> 
> And, as far as the hardware is concerned, in practice as well.
> 
>> So it should be possible to use Altivec without using FPU.
> 
> Yup.
> 
>> However, until recently, it was not possible to de-activate FPU support on 
>> book3s/32. I made it possible in order to reduce unneccessary processing on 
>> processors like the 832x that has no FPU.
> 
> The processor has to implement FP to be compliant to any version of
> PowerPC, as far as I know?  So that is all done by emulation, including
> all the registers?  Wow painful.
> 
>> As far as I can see in cputable.h/.c, 832x is the only book3s/32 without 
>> FPU, and it doesn't have ALTIVEC either.
> 
> 602 doesn't have double-precision hardware, also no 64-bit FP registers.
> But that CPU was never any widely used :-)
> 
>> So we can in the future ensure that Altivec can be used without FPU 
>> support, but for the time being I think it is OK to force selection of FPU 
>> when selecting ALTIVEC in order to avoid build failures.
> 
> It is useful to allow MSR[VEC,FP]=1,0 but yeah there are no CPUs that
> have VMX (aka AltiVec) but that do not have FP.  I don't see how making
> that artificial dependency buys anything, but maybe it does?
> 
>>> I have patches to fix the build errors with the config as
>>> reported but I don't know if that's the right thing to do...
> 
> Neither do we, we cannot see those patches :-)

Sure.  I'll post them later today.
They keep FPU and ALTIVEC as independent (build) features.

-- 
~Randy

Re: PPC_FPU, ALTIVEC: enable_kernel_fp, put_vr, get_vr

[Michael Ellerman]

Randy Dunlap <rdunlap@infradead.org> writes:
> On 4/18/21 10:46 AM, Segher Boessenkool wrote:
>> On Sun, Apr 18, 2021 at 06:24:29PM +0200, Christophe Leroy wrote:
>>> Le 17/04/2021 à 22:17, Randy Dunlap a écrit :
>>>> Should the code + Kconfigs/Makefiles handle that kind of
>>>> kernel config or should ALTIVEC always mean PPC_FPU as well?
>>>
>>> As far as I understand, Altivec is completely independant of FPU in Theory. 
>> 
>> And, as far as the hardware is concerned, in practice as well.
>> 
>>> So it should be possible to use Altivec without using FPU.
>> 
>> Yup.
>> 
>>> However, until recently, it was not possible to de-activate FPU support on 
>>> book3s/32. I made it possible in order to reduce unneccessary processing on 
>>> processors like the 832x that has no FPU.
>> 
>> The processor has to implement FP to be compliant to any version of
>> PowerPC, as far as I know?  So that is all done by emulation, including
>> all the registers?  Wow painful.
>> 
>>> As far as I can see in cputable.h/.c, 832x is the only book3s/32 without 
>>> FPU, and it doesn't have ALTIVEC either.
>> 
>> 602 doesn't have double-precision hardware, also no 64-bit FP registers.
>> But that CPU was never any widely used :-)
>> 
>>> So we can in the future ensure that Altivec can be used without FPU 
>>> support, but for the time being I think it is OK to force selection of FPU 
>>> when selecting ALTIVEC in order to avoid build failures.
>> 
>> It is useful to allow MSR[VEC,FP]=1,0 but yeah there are no CPUs that
>> have VMX (aka AltiVec) but that do not have FP.  I don't see how making
>> that artificial dependency buys anything, but maybe it does?
>> 
>>>> I have patches to fix the build errors with the config as
>>>> reported but I don't know if that's the right thing to do...
>> 
>> Neither do we, we cannot see those patches :-)
>
> 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.

cheers

Re: PPC_FPU, ALTIVEC: enable_kernel_fp, put_vr, get_vr

[Randy Dunlap]

On 4/19/21 6:16 AM, Michael Ellerman wrote:
> Randy Dunlap <rdunlap@infradead.org> writes:
>> On 4/18/21 10:46 AM, Segher Boessenkool wrote:
>>> On Sun, Apr 18, 2021 at 06:24:29PM +0200, Christophe Leroy wrote:
>>>> Le 17/04/2021 à 22:17, Randy Dunlap a écrit :
>>>>> Should the code + Kconfigs/Makefiles handle that kind of
>>>>> kernel config or should ALTIVEC always mean PPC_FPU as well?
>>>>
>>>> As far as I understand, Altivec is completely independant of FPU in Theory. 
>>>
>>> And, as far as the hardware is concerned, in practice as well.
>>>
>>>> So it should be possible to use Altivec without using FPU.
>>>
>>> Yup.
>>>
>>>> However, until recently, it was not possible to de-activate FPU support on 
>>>> book3s/32. I made it possible in order to reduce unneccessary processing on 
>>>> processors like the 832x that has no FPU.
>>>
>>> The processor has to implement FP to be compliant to any version of
>>> PowerPC, as far as I know?  So that is all done by emulation, including
>>> all the registers?  Wow painful.
>>>
>>>> As far as I can see in cputable.h/.c, 832x is the only book3s/32 without 
>>>> FPU, and it doesn't have ALTIVEC either.
>>>
>>> 602 doesn't have double-precision hardware, also no 64-bit FP registers.
>>> But that CPU was never any widely used :-)
>>>
>>>> So we can in the future ensure that Altivec can be used without FPU 
>>>> support, but for the time being I think it is OK to force selection of FPU 
>>>> when selecting ALTIVEC in order to avoid build failures.
>>>
>>> It is useful to allow MSR[VEC,FP]=1,0 but yeah there are no CPUs that
>>> have VMX (aka AltiVec) but that do not have FP.  I don't see how making
>>> that artificial dependency buys anything, but maybe it does?
>>>
>>>>> I have patches to fix the build errors with the config as
>>>>> reported but I don't know if that's the right thing to do...
>>>
>>> Neither do we, we cannot see those patches :-)
>>
>> 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

Agreed.

> 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.
> 
> cheers

Makes sense and sounds good to me.

thanks.
-- 
~Randy

Re: PPC_FPU, ALTIVEC: enable_kernel_fp, put_vr, get_vr

[Randy Dunlap]

On 4/19/21 6:16 AM, Michael Ellerman wrote:
> Randy Dunlap <rdunlap@infradead.org> 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 <rdunlap@infradead.org>
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 <rdunlap@infradead.org>
Reported-by: kernel test robot <lkp@intel.com>
Cc: Michael Ellerman <mpe@ellerman.id.au>
Cc: linuxppc-dev@lists.ozlabs.org
Cc: Christophe Leroy <christophe.leroy@csgroup.eu>
Cc: Segher Boessenkool <segher@kernel.crashing.org>
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
 	depends on PPC_BOOK3S_32 || PPC_BOOK3S_64 || (PPC_E500MC && PPC64)
 	help
 	  This option enables kernel support for the Altivec extensions to the

Re: PPC_FPU, ALTIVEC: enable_kernel_fp, put_vr, get_vr

[Christophe Leroy]

Le 19/04/2021 à 23:39, Randy Dunlap a écrit :
> On 4/19/21 6:16 AM, Michael Ellerman wrote:
>> Randy Dunlap <rdunlap@infradead.org> 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 <rdunlap@infradead.org>
> 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 <rdunlap@infradead.org>
> Reported-by: kernel test robot <lkp@intel.com>
> Cc: Michael Ellerman <mpe@ellerman.id.au>
> Cc: linuxppc-dev@lists.ozlabs.org
> Cc: Christophe Leroy <christophe.leroy@csgroup.eu>
> Cc: Segher Boessenkool <segher@kernel.crashing.org>
> 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
> 

Re: PPC_FPU, ALTIVEC: enable_kernel_fp, put_vr, get_vr

[Michael Ellerman]

Christophe Leroy <christophe.leroy@csgroup.eu> writes:
> Le 19/04/2021 à 23:39, Randy Dunlap a écrit :
>> On 4/19/21 6:16 AM, Michael Ellerman wrote:
>>> Randy Dunlap <rdunlap@infradead.org> 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 <rdunlap@infradead.org>
>> 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 <rdunlap@infradead.org>
>> Reported-by: kernel test robot <lkp@intel.com>
>> Cc: Michael Ellerman <mpe@ellerman.id.au>
>> Cc: linuxppc-dev@lists.ozlabs.org
>> Cc: Christophe Leroy <christophe.leroy@csgroup.eu>
>> Cc: Segher Boessenkool <segher@kernel.crashing.org>
>> 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 ?

Yes, ALTIVEC should select PPC_FPU.

The latter is (generally) not user selectable, so there's no issue with
selecting it, whereas the reverse is not true.

For 64-bit Book3S I think we could just always enable ALTIVEC these
days. It's only Power5 that doesn't have it, and essentially no one is
running mainline on those AFAIK. But that can be done separately.

cheers

Re: PPC_FPU, ALTIVEC: enable_kernel_fp, put_vr, get_vr

[Randy Dunlap]

On 4/20/21 6:15 AM, Michael Ellerman wrote:
> Christophe Leroy <christophe.leroy@csgroup.eu> writes:
>> Le 19/04/2021 à 23:39, Randy Dunlap a écrit :
>>> On 4/19/21 6:16 AM, Michael Ellerman wrote:
>>>> Randy Dunlap <rdunlap@infradead.org> 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 <rdunlap@infradead.org>
>>> 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 <rdunlap@infradead.org>
>>> Reported-by: kernel test robot <lkp@intel.com>
>>> Cc: Michael Ellerman <mpe@ellerman.id.au>
>>> Cc: linuxppc-dev@lists.ozlabs.org
>>> Cc: Christophe Leroy <christophe.leroy@csgroup.eu>
>>> Cc: Segher Boessenkool <segher@kernel.crashing.org>
>>> 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 ?
> 
> Yes, ALTIVEC should select PPC_FPU.
> 
> The latter is (generally) not user selectable, so there's no issue with
> selecting it, whereas the reverse is not true.
> 
> For 64-bit Book3S I think we could just always enable ALTIVEC these
> days. It's only Power5 that doesn't have it, and essentially no one is
> running mainline on those AFAIK. But that can be done separately.

OK, I'll run that thru some tests today.

thanks.
-- 
~Randy