diff mbox

powerpc: define empty enable_kernel_vsx() when CONFIG_VSX=n

Message ID 1441735991-29199-1-git-send-email-tim.gardner@canonical.com (mailing list archive)
State Rejected
Headers show

Commit Message

Tim Gardner Sept. 8, 2015, 6:13 p.m. UTC 
From: Tim Gardner <tim.gardner@canonical.com>

commit 72cd7b44bc99 ("powerpc: Uncomment and make enable_kernel_vsx()
routine available") neglected to define an empty inline replacement for
enable_kernel_vsx() when CONFIG_VSX=n.

Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Paul Mackerras <paulus@samba.org>
Cc: Michael Ellerman <mpe@ellerman.id.au>
Cc: Leonidas Da Silva Barbosa <leosilva@linux.vnet.ibm.com>
Cc: Herbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
---
 arch/powerpc/include/asm/switch_to.h | 5 ++++-
 1 file changed, 4 insertions(+), 1 deletion(-)

Comments

Paul Mackerras Sept. 8, 2015, 10:47 p.m. UTC | #1 
On Tue, Sep 08, 2015 at 12:13:11PM -0600, tim.gardner@canonical.com wrote:
> From: Tim Gardner <tim.gardner@canonical.com>
> 
> commit 72cd7b44bc99 ("powerpc: Uncomment and make enable_kernel_vsx()
> routine available") neglected to define an empty inline replacement for
> enable_kernel_vsx() when CONFIG_VSX=n.

If code that wants to call enable_kernel_vsx() is getting compiled in
when CONFIG_VSX=n, that's a worry.  Is this patch motivated by an
actual compile failure?  If so what was the failure?

Paul.
Tim Gardner Sept. 8, 2015, 11:19 p.m. UTC | #2 
On 09/08/2015 04:47 PM, Paul Mackerras wrote:
> On Tue, Sep 08, 2015 at 12:13:11PM -0600, tim.gardner@canonical.com wrote:
>> From: Tim Gardner <tim.gardner@canonical.com>
>>
>> commit 72cd7b44bc99 ("powerpc: Uncomment and make enable_kernel_vsx()
>> routine available") neglected to define an empty inline replacement for
>> enable_kernel_vsx() when CONFIG_VSX=n.
> 
> If code that wants to call enable_kernel_vsx() is getting compiled in
> when CONFIG_VSX=n, that's a worry.  Is this patch motivated by an
> actual compile failure?  If so what was the failure?
> 
> Paul.
> 

I was having link failures after backporting 'crypto: nx' patches to a
4.2 based kernel. You may have a point in that the upstream Kconfig will
not allow those files to be compiled if CONFIG_VSX=n. I will check in my
morning if to see if I can reproduce the same link error in mainline.

rtg
Michael Ellerman Sept. 9, 2015, 2:13 a.m. UTC | #3 
On Tue, 2015-09-08 at 17:19 -0600, Tim Gardner wrote:
> On 09/08/2015 04:47 PM, Paul Mackerras wrote:
> > On Tue, Sep 08, 2015 at 12:13:11PM -0600, tim.gardner@canonical.com wrote:
> >> From: Tim Gardner <tim.gardner@canonical.com>
> >>
> >> commit 72cd7b44bc99 ("powerpc: Uncomment and make enable_kernel_vsx()
> >> routine available") neglected to define an empty inline replacement for
> >> enable_kernel_vsx() when CONFIG_VSX=n.
> > 
> > If code that wants to call enable_kernel_vsx() is getting compiled in
> > when CONFIG_VSX=n, that's a worry.  Is this patch motivated by an
> > actual compile failure?  If so what was the failure?
> 
> I was having link failures after backporting 'crypto: nx' patches to a
> 4.2 based kernel. You may have a point in that the upstream Kconfig will
> not allow those files to be compiled if CONFIG_VSX=n. I will check in my
> morning if to see if I can reproduce the same link error in mainline.

I suspect the problem is the "vmx" crypto actually.

$ git grep enable_kernel_vsx drivers/
drivers/crypto/vmx/aes.c:       enable_kernel_vsx();
drivers/crypto/vmx/aes.c:               enable_kernel_vsx();
drivers/crypto/vmx/aes.c:               enable_kernel_vsx();
drivers/crypto/vmx/aes_cbc.c:   enable_kernel_vsx();
drivers/crypto/vmx/aes_cbc.c:           enable_kernel_vsx();
drivers/crypto/vmx/aes_cbc.c:           enable_kernel_vsx();
drivers/crypto/vmx/aes_ctr.c:   enable_kernel_vsx();
drivers/crypto/vmx/aes_ctr.c:   enable_kernel_vsx();
drivers/crypto/vmx/aes_ctr.c:                   enable_kernel_vsx();
drivers/crypto/vmx/ghash.c:     enable_kernel_vsx();
drivers/crypto/vmx/ghash.c:                     enable_kernel_vsx();
drivers/crypto/vmx/ghash.c:                     enable_kernel_vsx();
drivers/crypto/vmx/ghash.c:                     enable_kernel_vsx();


That appears to all be controlled by CONFIG_CRYPTO_DEV_VMX_ENCRYPT, which
depends on CONFIG_CRYPTO_DEV_VMX, which depends on PPC64.

So that looks like it will break terribly if VSX is turned off.

We do have an automated test build with VSX turned off, but it doesn't have
CONFIG_CRYPTO_DEV_VMX enabled :/


Having said all that, why are you building a ppc64 kernel with VSX turned off?

cheers
Tim Gardner Sept. 9, 2015, 1:31 p.m. UTC | #4 
On 09/08/2015 08:13 PM, Michael Ellerman wrote:
> On Tue, 2015-09-08 at 17:19 -0600, Tim Gardner wrote:
>> On 09/08/2015 04:47 PM, Paul Mackerras wrote:
>>> On Tue, Sep 08, 2015 at 12:13:11PM -0600, tim.gardner@canonical.com wrote:
>>>> From: Tim Gardner <tim.gardner@canonical.com>
>>>>
>>>> commit 72cd7b44bc99 ("powerpc: Uncomment and make enable_kernel_vsx()
>>>> routine available") neglected to define an empty inline replacement for
>>>> enable_kernel_vsx() when CONFIG_VSX=n.
>>>
>>> If code that wants to call enable_kernel_vsx() is getting compiled in
>>> when CONFIG_VSX=n, that's a worry.  Is this patch motivated by an
>>> actual compile failure?  If so what was the failure?
>>
>> I was having link failures after backporting 'crypto: nx' patches to a
>> 4.2 based kernel. You may have a point in that the upstream Kconfig will
>> not allow those files to be compiled if CONFIG_VSX=n. I will check in my
>> morning if to see if I can reproduce the same link error in mainline.
>
> I suspect the problem is the "vmx" crypto actually.
>
> $ git grep enable_kernel_vsx drivers/
> drivers/crypto/vmx/aes.c:       enable_kernel_vsx();
> drivers/crypto/vmx/aes.c:               enable_kernel_vsx();
> drivers/crypto/vmx/aes.c:               enable_kernel_vsx();
> drivers/crypto/vmx/aes_cbc.c:   enable_kernel_vsx();
> drivers/crypto/vmx/aes_cbc.c:           enable_kernel_vsx();
> drivers/crypto/vmx/aes_cbc.c:           enable_kernel_vsx();
> drivers/crypto/vmx/aes_ctr.c:   enable_kernel_vsx();
> drivers/crypto/vmx/aes_ctr.c:   enable_kernel_vsx();
> drivers/crypto/vmx/aes_ctr.c:                   enable_kernel_vsx();
> drivers/crypto/vmx/ghash.c:     enable_kernel_vsx();
> drivers/crypto/vmx/ghash.c:                     enable_kernel_vsx();
> drivers/crypto/vmx/ghash.c:                     enable_kernel_vsx();
> drivers/crypto/vmx/ghash.c:                     enable_kernel_vsx();
>
>
> That appears to all be controlled by CONFIG_CRYPTO_DEV_VMX_ENCRYPT, which
> depends on CONFIG_CRYPTO_DEV_VMX, which depends on PPC64.
>
> So that looks like it will break terribly if VSX is turned off.
>
> We do have an automated test build with VSX turned off, but it doesn't have
> CONFIG_CRYPTO_DEV_VMX enabled :/
>
>
> Having said all that, why are you building a ppc64 kernel with VSX turned off?
>
> cheers
>
>

I'm pretty sure my problem is that I'm building a 32bit powerpc with 
CONFIG_CRYPTO_DEV_VMX_ENCRYPT=y, though it is hard to tell for sure with 
the interleaved build output from 4 parallel builds (powerpc-smp 
powerpc64-smp powerpc-e500mc powerpc64-emb). Your proposed patch 
("[PATCH v2] crypto: vmx - VMX crypto should depend on CONFIG_VSX") 
fixes my problems (and makes more sense then my patch), so I suddenly 
don't care as much.

rtg
Michael Ellerman Sept. 10, 2015, 12:52 a.m. UTC | #5 
On Wed, 2015-09-09 at 07:31 -0600, Tim Gardner wrote:
> On 09/08/2015 08:13 PM, Michael Ellerman wrote:
> > On Tue, 2015-09-08 at 17:19 -0600, Tim Gardner wrote:
> >> On 09/08/2015 04:47 PM, Paul Mackerras wrote:
> >>> On Tue, Sep 08, 2015 at 12:13:11PM -0600, tim.gardner@canonical.com wrote:
> >>>> From: Tim Gardner <tim.gardner@canonical.com>
> >>>>
> >>>> commit 72cd7b44bc99 ("powerpc: Uncomment and make enable_kernel_vsx()
> >>>> routine available") neglected to define an empty inline replacement for
> >>>> enable_kernel_vsx() when CONFIG_VSX=n.
> >>>
> >>> If code that wants to call enable_kernel_vsx() is getting compiled in
> >>> when CONFIG_VSX=n, that's a worry.  Is this patch motivated by an
> >>> actual compile failure?  If so what was the failure?
> >>
> >> I was having link failures after backporting 'crypto: nx' patches to a
> >> 4.2 based kernel. You may have a point in that the upstream Kconfig will
> >> not allow those files to be compiled if CONFIG_VSX=n. I will check in my
> >> morning if to see if I can reproduce the same link error in mainline.
> >
> > I suspect the problem is the "vmx" crypto actually.
> >
> > $ git grep enable_kernel_vsx drivers/
> > drivers/crypto/vmx/aes.c:       enable_kernel_vsx();
> > drivers/crypto/vmx/aes.c:               enable_kernel_vsx();
> > drivers/crypto/vmx/aes.c:               enable_kernel_vsx();
> > drivers/crypto/vmx/aes_cbc.c:   enable_kernel_vsx();
> > drivers/crypto/vmx/aes_cbc.c:           enable_kernel_vsx();
> > drivers/crypto/vmx/aes_cbc.c:           enable_kernel_vsx();
> > drivers/crypto/vmx/aes_ctr.c:   enable_kernel_vsx();
> > drivers/crypto/vmx/aes_ctr.c:   enable_kernel_vsx();
> > drivers/crypto/vmx/aes_ctr.c:                   enable_kernel_vsx();
> > drivers/crypto/vmx/ghash.c:     enable_kernel_vsx();
> > drivers/crypto/vmx/ghash.c:                     enable_kernel_vsx();
> > drivers/crypto/vmx/ghash.c:                     enable_kernel_vsx();
> > drivers/crypto/vmx/ghash.c:                     enable_kernel_vsx();
> >
> >
> > That appears to all be controlled by CONFIG_CRYPTO_DEV_VMX_ENCRYPT, which
> > depends on CONFIG_CRYPTO_DEV_VMX, which depends on PPC64.
> >
> > So that looks like it will break terribly if VSX is turned off.
> >
> > We do have an automated test build with VSX turned off, but it doesn't have
> > CONFIG_CRYPTO_DEV_VMX enabled :/
> >
> >
> > Having said all that, why are you building a ppc64 kernel with VSX turned off?
> 
> I'm pretty sure my problem is that I'm building a 32bit powerpc with 
> CONFIG_CRYPTO_DEV_VMX_ENCRYPT=y, though it is hard to tell for sure with 
> the interleaved build output from 4 parallel builds (powerpc-smp 
> powerpc64-smp powerpc-e500mc powerpc64-emb). 

OK. It shouldn't be possible to have CONFIG_CRYPTO_DEV_VMX_ENCRYPT=y for a
32-bit kernel.

I didn't know you guys were building a powerpc64-emb kernel, which by the looks
is ~= CONFIG_PPC_BOOK3E_64.

I'm fairly certain that will be the problem, as it's a 64-bit kernel, but does
not have VSX.

> Your proposed patch ("[PATCH v2] crypto: vmx - VMX crypto should depend on
> CONFIG_VSX") fixes my problems (and makes more sense then my patch), so I
> suddenly don't care as much.

OK great. Sorry for the screw up, I'll try and keep a better eye on what's
going in via the crypto tree in future.

cheers
diff mbox

Patch

diff --git a/arch/powerpc/include/asm/switch_to.h b/arch/powerpc/include/asm/switch_to.h
index 15cca17..dea61a0 100644
--- a/arch/powerpc/include/asm/switch_to.h
+++ b/arch/powerpc/include/asm/switch_to.h
@@ -29,7 +29,6 @@  static inline void save_early_sprs(struct thread_struct *prev) {}
 
 extern void enable_kernel_fp(void);
 extern void enable_kernel_altivec(void);
-extern void enable_kernel_vsx(void);
 extern int emulate_altivec(struct pt_regs *);
 extern void __giveup_vsx(struct task_struct *);
 extern void giveup_vsx(struct task_struct *);
@@ -69,10 +68,14 @@  static inline void giveup_altivec(struct task_struct *t)
 
 #ifdef CONFIG_VSX
 extern void flush_vsx_to_thread(struct task_struct *);
+extern void enable_kernel_vsx(void);
 #else
 static inline void flush_vsx_to_thread(struct task_struct *t)
 {
 }
+static inline void enable_kernel_vsx(void)
+{
+}
 #endif
 
 #ifdef CONFIG_SPE