* [PATCH] powerpc: define empty enable_kernel_vsx() when CONFIG_VSX=n
@ 2015-09-08 18:13 tim.gardner
2015-09-08 22:47 ` Paul Mackerras
0 siblings, 1 reply; 6+ messages in thread
From: tim.gardner @ 2015-09-08 18:13 UTC (permalink / raw)
To: linuxppc-dev, linux-kernel
Cc: Tim Gardner, Benjamin Herrenschmidt, Paul Mackerras,
Michael Ellerman, Leonidas Da Silva Barbosa, Herbert Xu
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(-)
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
--
1.9.1
^ permalink raw reply related [flat|nested] 6+ messages in thread* Re: [PATCH] powerpc: define empty enable_kernel_vsx() when CONFIG_VSX=n
2015-09-08 18:13 [PATCH] powerpc: define empty enable_kernel_vsx() when CONFIG_VSX=n tim.gardner
@ 2015-09-08 22:47 ` Paul Mackerras
2015-09-08 23:19 ` Tim Gardner
0 siblings, 1 reply; 6+ messages in thread
From: Paul Mackerras @ 2015-09-08 22:47 UTC (permalink / raw)
To: tim.gardner
Cc: linuxppc-dev, linux-kernel, Benjamin Herrenschmidt,
Michael Ellerman, Leonidas Da Silva Barbosa, Herbert Xu
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.
^ permalink raw reply [flat|nested] 6+ messages in thread* Re: [PATCH] powerpc: define empty enable_kernel_vsx() when CONFIG_VSX=n
2015-09-08 22:47 ` Paul Mackerras
@ 2015-09-08 23:19 ` Tim Gardner
2015-09-09 2:13 ` Michael Ellerman
0 siblings, 1 reply; 6+ messages in thread
From: Tim Gardner @ 2015-09-08 23:19 UTC (permalink / raw)
To: Paul Mackerras
Cc: linuxppc-dev, linux-kernel, Benjamin Herrenschmidt,
Michael Ellerman, Leonidas Da Silva Barbosa, Herbert Xu
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
--
Tim Gardner tim.gardner@canonical.com
^ permalink raw reply [flat|nested] 6+ messages in thread* Re: [PATCH] powerpc: define empty enable_kernel_vsx() when CONFIG_VSX=n
2015-09-08 23:19 ` Tim Gardner
@ 2015-09-09 2:13 ` Michael Ellerman
2015-09-09 13:31 ` Tim Gardner
0 siblings, 1 reply; 6+ messages in thread
From: Michael Ellerman @ 2015-09-09 2:13 UTC (permalink / raw)
To: Tim Gardner
Cc: Paul Mackerras, linuxppc-dev, linux-kernel,
Benjamin Herrenschmidt, Leonidas Da Silva Barbosa, Herbert Xu
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
^ permalink raw reply [flat|nested] 6+ messages in thread* Re: [PATCH] powerpc: define empty enable_kernel_vsx() when CONFIG_VSX=n
2015-09-09 2:13 ` Michael Ellerman
@ 2015-09-09 13:31 ` Tim Gardner
2015-09-10 0:52 ` Michael Ellerman
0 siblings, 1 reply; 6+ messages in thread
From: Tim Gardner @ 2015-09-09 13:31 UTC (permalink / raw)
To: Michael Ellerman
Cc: Paul Mackerras, linuxppc-dev, linux-kernel,
Benjamin Herrenschmidt, Leonidas Da Silva Barbosa, Herbert Xu
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
--
Tim Gardner tim.gardner@canonical.com
^ permalink raw reply [flat|nested] 6+ messages in thread* Re: [PATCH] powerpc: define empty enable_kernel_vsx() when CONFIG_VSX=n
2015-09-09 13:31 ` Tim Gardner
@ 2015-09-10 0:52 ` Michael Ellerman
0 siblings, 0 replies; 6+ messages in thread
From: Michael Ellerman @ 2015-09-10 0:52 UTC (permalink / raw)
To: Tim Gardner
Cc: Paul Mackerras, linuxppc-dev, linux-kernel,
Benjamin Herrenschmidt, Leonidas Da Silva Barbosa, Herbert Xu
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
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2015-09-10 0:52 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2015-09-08 18:13 [PATCH] powerpc: define empty enable_kernel_vsx() when CONFIG_VSX=n tim.gardner
2015-09-08 22:47 ` Paul Mackerras
2015-09-08 23:19 ` Tim Gardner
2015-09-09 2:13 ` Michael Ellerman
2015-09-09 13:31 ` Tim Gardner
2015-09-10 0:52 ` Michael Ellerman
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).