All of lore.kernel.org
 help / color / mirror / Atom feed
* [PATCH] crypto: Remove pointless padlock module
@ 2007-04-28 23:40 Simon Arlott
  2007-04-29  1:59 ` Randy Dunlap
  0 siblings, 1 reply; 9+ messages in thread
From: Simon Arlott @ 2007-04-28 23:40 UTC (permalink / raw)
  To: Linux Kernel Mailing List; +Cc: randy.dunlap, herbert, michal

When this is compiled in it is run too early to do anything useful:
[    6.052000] padlock: No VIA PadLock drivers have been loaded.
[    6.052000] padlock: Using VIA PadLock ACE for AES algorithm.
[    6.052000] padlock: Using VIA PadLock ACE for SHA1/SHA256 algorithms.

When it's a module it isn't doing anything special, the same functionality 
can be provided in userspace by "probeall padlock padlock-aes padlock-sha" 
in modules.conf if it is required.

Signed-off-by: Simon Arlott <simon@fire.lp0.eu>
Cc: Herbert Xu <herbert@gondor.apana.org.au>
Cc: Michal Ludvig <michal@logix.cz>
---
 drivers/crypto/Kconfig   |   16 ++----------
 drivers/crypto/Makefile  |    1 -
 drivers/crypto/padlock.c |   58 ----------------------------------------------
 3 files changed, 3 insertions(+), 72 deletions(-)
 delete mode 100644 drivers/crypto/padlock.c

diff --git a/drivers/crypto/Kconfig b/drivers/crypto/Kconfig
index ff8c4be..f85cecc 100644
--- a/drivers/crypto/Kconfig
+++ b/drivers/crypto/Kconfig
@@ -1,10 +1,10 @@
 menu "Hardware crypto devices"
 
 config CRYPTO_DEV_PADLOCK
-	tristate "Support for VIA PadLock ACE"
-	depends on X86_32
+	bool "Support for VIA PadLock ACE"
+	depends on CRYPTO && X86_32
+	default y
 	select CRYPTO_ALGAPI
-	default m
 	help
 	  Some VIA processors come with an integrated crypto engine
 	  (so called VIA PadLock ACE, Advanced Cryptography Engine)
@@ -14,16 +14,6 @@ config CRYPTO_DEV_PADLOCK
 	  The instructions are used only when the CPU supports them.
 	  Otherwise software encryption is used.
 
-	  Selecting M for this option will compile a helper module
-	  padlock.ko that should autoload all below configured
-	  algorithms. Don't worry if your hardware does not support
-	  some or all of them. In such case padlock.ko will
-	  simply write a single line into the kernel log informing
-	  about its failure but everything will keep working fine.
-
-	  If you are unsure, say M. The compiled module will be
-	  called padlock.ko
-
 config CRYPTO_DEV_PADLOCK_AES
 	tristate "PadLock driver for AES algorithm"
 	depends on CRYPTO_DEV_PADLOCK
diff --git a/drivers/crypto/Makefile b/drivers/crypto/Makefile
index 6059cf8..d070030 100644
--- a/drivers/crypto/Makefile
+++ b/drivers/crypto/Makefile
@@ -1,4 +1,3 @@
-obj-$(CONFIG_CRYPTO_DEV_PADLOCK) += padlock.o
 obj-$(CONFIG_CRYPTO_DEV_PADLOCK_AES) += padlock-aes.o
 obj-$(CONFIG_CRYPTO_DEV_PADLOCK_SHA) += padlock-sha.o
 obj-$(CONFIG_CRYPTO_DEV_GEODE) += geode-aes.o
diff --git a/drivers/crypto/padlock.c b/drivers/crypto/padlock.c
deleted file mode 100644
index d6d7dd5..0000000
--- a/drivers/crypto/padlock.c
+++ /dev/null
@@ -1,58 +0,0 @@
-/*
- * Cryptographic API.
- *
- * Support for VIA PadLock hardware crypto engine.
- *
- * Copyright (c) 2006  Michal Ludvig <michal@logix.cz>
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License as published by
- * the Free Software Foundation; either version 2 of the License, or
- * (at your option) any later version.
- *
- */
-
-#include <linux/module.h>
-#include <linux/init.h>
-#include <linux/errno.h>
-#include <linux/crypto.h>
-#include <linux/cryptohash.h>
-#include <linux/interrupt.h>
-#include <linux/kernel.h>
-#include <linux/scatterlist.h>
-#include "padlock.h"
-
-static int __init padlock_init(void)
-{
-	int success = 0;
-
-	if (crypto_has_cipher("aes-padlock", 0, 0))
-		success++;
-
-	if (crypto_has_hash("sha1-padlock", 0, 0))
-		success++;
-
-	if (crypto_has_hash("sha256-padlock", 0, 0))
-		success++;
-
-	if (!success) {
-		printk(KERN_WARNING PFX "No VIA PadLock drivers have been loaded.\n");
-		return -ENODEV;
-	}
-
-	printk(KERN_NOTICE PFX "%d drivers are available.\n", success);
-
-	return 0;
-}
-
-static void __exit padlock_fini(void)
-{
-}
-
-module_init(padlock_init);
-module_exit(padlock_fini);
-
-MODULE_DESCRIPTION("Load all configured PadLock algorithms.");
-MODULE_LICENSE("GPL");
-MODULE_AUTHOR("Michal Ludvig");
-
-- 
1.5.0.1

-- 
Simon Arlott

^ permalink raw reply related	[flat|nested] 9+ messages in thread

* Re: [PATCH] crypto: Remove pointless padlock module
  2007-04-28 23:40 [PATCH] crypto: Remove pointless padlock module Simon Arlott
@ 2007-04-29  1:59 ` Randy Dunlap
  2007-04-29  8:01   ` [PATCH (v2)] " Simon Arlott
  0 siblings, 1 reply; 9+ messages in thread
From: Randy Dunlap @ 2007-04-29  1:59 UTC (permalink / raw)
  To: Simon Arlott; +Cc: Linux Kernel Mailing List, herbert, michal

Simon Arlott wrote:
> When this is compiled in it is run too early to do anything useful:
> [    6.052000] padlock: No VIA PadLock drivers have been loaded.
> [    6.052000] padlock: Using VIA PadLock ACE for AES algorithm.
> [    6.052000] padlock: Using VIA PadLock ACE for SHA1/SHA256 algorithms.
> 
> When it's a module it isn't doing anything special, the same 
> functionality can be provided in userspace by "probeall padlock 
> padlock-aes padlock-sha" in modules.conf if it is required.
> 
> Signed-off-by: Simon Arlott <simon@fire.lp0.eu>
> Cc: Herbert Xu <herbert@gondor.apana.org.au>
> Cc: Michal Ludvig <michal@logix.cz>
> ---
> drivers/crypto/Kconfig   |   16 ++----------
> drivers/crypto/Makefile  |    1 -
> drivers/crypto/padlock.c |   58 
> ----------------------------------------------
> 3 files changed, 3 insertions(+), 72 deletions(-)
> delete mode 100644 drivers/crypto/padlock.c
> 
> diff --git a/drivers/crypto/Kconfig b/drivers/crypto/Kconfig
> index ff8c4be..f85cecc 100644
> --- a/drivers/crypto/Kconfig
> +++ b/drivers/crypto/Kconfig
> @@ -1,10 +1,10 @@
> menu "Hardware crypto devices"
> 
> config CRYPTO_DEV_PADLOCK
> -    tristate "Support for VIA PadLock ACE"
> -    depends on X86_32
> +    bool "Support for VIA PadLock ACE"
> +    depends on CRYPTO && X86_32

All of drivers/crypto/Kconfig already depends on CRYPTO, so just
	depends on X86_32
should be enough.

> +    default y
>     select CRYPTO_ALGAPI
> -    default m
>     help
>       Some VIA processors come with an integrated crypto engine
>       (so called VIA PadLock ACE, Advanced Cryptography Engine)


-- 
~Randy
*** Remember to use Documentation/SubmitChecklist when testing your code ***

^ permalink raw reply	[flat|nested] 9+ messages in thread

* [PATCH (v2)] crypto: Remove pointless padlock module
  2007-04-29  1:59 ` Randy Dunlap
@ 2007-04-29  8:01   ` Simon Arlott
  2007-05-02  4:50     ` Herbert Xu
  2007-05-18  6:45     ` Herbert Xu
  0 siblings, 2 replies; 9+ messages in thread
From: Simon Arlott @ 2007-04-29  8:01 UTC (permalink / raw)
  To: Randy Dunlap; +Cc: Linux Kernel Mailing List, herbert, michal, ioe-lkml

When this is compiled in it is run too early to do anything useful:
[    6.052000] padlock: No VIA PadLock drivers have been loaded.
[    6.052000] padlock: Using VIA PadLock ACE for AES algorithm.
[    6.052000] padlock: Using VIA PadLock ACE for SHA1/SHA256 algorithms.

When it's a module it isn't doing anything special, the same functionality 
can be provided in userspace by "probeall padlock padlock-aes padlock-sha" 
in modules.conf if it is required.

Signed-off-by: Simon Arlott <simon@fire.lp0.eu>
Cc: Herbert Xu <herbert@gondor.apana.org.au>
Cc: Michal Ludvig <michal@logix.cz>
---
On 29/04/07 02:59, Randy Dunlap wrote:
> Simon Arlott wrote:
>> +    depends on CRYPTO && X86_32
> 
> All of drivers/crypto/Kconfig already depends on CRYPTO, so just
>     depends on X86_32
> should be enough.

Ok, I've changed this for geode too.

On 29/04/07 08:28, Ingo Oeser wrote:
> On Sunday 29 April 2007, Simon Arlott wrote:
>> > Ideally I'd just remove that module completely, all it does is 
>> > trigger the loading of the other two modules when modules are 
>> > used - so I'll submit a patch for that instead.
> 
> That's much better! 
> 
> When you force a feature to be a module on a kernel without 
> module support, it will effectivly be disabled.

Well that's mostly the point - it shouldn't get compiled in - ever, 
but it also has other modules depending on it in Kconfig that 
shouldn't need to be modules.

 drivers/crypto/Kconfig   |   16 ++----------
 drivers/crypto/Makefile  |    1 -
 drivers/crypto/padlock.c |   58 ----------------------------------------------
 3 files changed, 3 insertions(+), 72 deletions(-)
 delete mode 100644 drivers/crypto/padlock.c

diff --git a/drivers/crypto/Kconfig b/drivers/crypto/Kconfig
index ff8c4be..f21fe66 100644
--- a/drivers/crypto/Kconfig
+++ b/drivers/crypto/Kconfig
@@ -1,10 +1,10 @@
 menu "Hardware crypto devices"
 
 config CRYPTO_DEV_PADLOCK
-	tristate "Support for VIA PadLock ACE"
+	bool "Support for VIA PadLock ACE"
 	depends on X86_32
 	select CRYPTO_ALGAPI
-	default m
+	default y
 	help
 	  Some VIA processors come with an integrated crypto engine
 	  (so called VIA PadLock ACE, Advanced Cryptography Engine)
@@ -14,16 +14,6 @@ config CRYPTO_DEV_PADLOCK
 	  The instructions are used only when the CPU supports them.
 	  Otherwise software encryption is used.
 
-	  Selecting M for this option will compile a helper module
-	  padlock.ko that should autoload all below configured
-	  algorithms. Don't worry if your hardware does not support
-	  some or all of them. In such case padlock.ko will
-	  simply write a single line into the kernel log informing
-	  about its failure but everything will keep working fine.
-
-	  If you are unsure, say M. The compiled module will be
-	  called padlock.ko
-
 config CRYPTO_DEV_PADLOCK_AES
 	tristate "PadLock driver for AES algorithm"
 	depends on CRYPTO_DEV_PADLOCK
@@ -55,7 +45,7 @@ source "arch/s390/crypto/Kconfig"
 
 config CRYPTO_DEV_GEODE
 	tristate "Support for the Geode LX AES engine"
-	depends on CRYPTO && X86_32 && PCI
+	depends on X86_32 && PCI
 	select CRYPTO_ALGAPI
 	select CRYPTO_BLKCIPHER
 	default m
diff --git a/drivers/crypto/Makefile b/drivers/crypto/Makefile
index 6059cf8..d070030 100644
--- a/drivers/crypto/Makefile
+++ b/drivers/crypto/Makefile
@@ -1,4 +1,3 @@
-obj-$(CONFIG_CRYPTO_DEV_PADLOCK) += padlock.o
 obj-$(CONFIG_CRYPTO_DEV_PADLOCK_AES) += padlock-aes.o
 obj-$(CONFIG_CRYPTO_DEV_PADLOCK_SHA) += padlock-sha.o
 obj-$(CONFIG_CRYPTO_DEV_GEODE) += geode-aes.o
diff --git a/drivers/crypto/padlock.c b/drivers/crypto/padlock.c
deleted file mode 100644
index d6d7dd5..0000000
--- a/drivers/crypto/padlock.c
+++ /dev/null
@@ -1,58 +0,0 @@
-/*
- * Cryptographic API.
- *
- * Support for VIA PadLock hardware crypto engine.
- *
- * Copyright (c) 2006  Michal Ludvig <michal@logix.cz>
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License as published by
- * the Free Software Foundation; either version 2 of the License, or
- * (at your option) any later version.
- *
- */
-
-#include <linux/module.h>
-#include <linux/init.h>
-#include <linux/errno.h>
-#include <linux/crypto.h>
-#include <linux/cryptohash.h>
-#include <linux/interrupt.h>
-#include <linux/kernel.h>
-#include <linux/scatterlist.h>
-#include "padlock.h"
-
-static int __init padlock_init(void)
-{
-	int success = 0;
-
-	if (crypto_has_cipher("aes-padlock", 0, 0))
-		success++;
-
-	if (crypto_has_hash("sha1-padlock", 0, 0))
-		success++;
-
-	if (crypto_has_hash("sha256-padlock", 0, 0))
-		success++;
-
-	if (!success) {
-		printk(KERN_WARNING PFX "No VIA PadLock drivers have been loaded.\n");
-		return -ENODEV;
-	}
-
-	printk(KERN_NOTICE PFX "%d drivers are available.\n", success);
-
-	return 0;
-}
-
-static void __exit padlock_fini(void)
-{
-}
-
-module_init(padlock_init);
-module_exit(padlock_fini);
-
-MODULE_DESCRIPTION("Load all configured PadLock algorithms.");
-MODULE_LICENSE("GPL");
-MODULE_AUTHOR("Michal Ludvig");
-
-- 
1.5.0.1

-- 
Simon Arlott

^ permalink raw reply related	[flat|nested] 9+ messages in thread

* Re: [PATCH (v2)] crypto: Remove pointless padlock module
  2007-04-29  8:01   ` [PATCH (v2)] " Simon Arlott
@ 2007-05-02  4:50     ` Herbert Xu
  2007-05-18  6:45     ` Herbert Xu
  1 sibling, 0 replies; 9+ messages in thread
From: Herbert Xu @ 2007-05-02  4:50 UTC (permalink / raw)
  To: Simon Arlott; +Cc: Randy Dunlap, Linux Kernel Mailing List, michal, ioe-lkml

On Sun, Apr 29, 2007 at 09:01:10AM +0100, Simon Arlott wrote:
> 
> Well that's mostly the point - it shouldn't get compiled in - ever, 
> but it also has other modules depending on it in Kconfig that 
> shouldn't need to be modules.

Patch applied.  Thanks!
-- 
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [PATCH (v2)] crypto: Remove pointless padlock module
  2007-04-29  8:01   ` [PATCH (v2)] " Simon Arlott
  2007-05-02  4:50     ` Herbert Xu
@ 2007-05-18  6:45     ` Herbert Xu
  2007-05-19 19:28       ` Simon Arlott
  1 sibling, 1 reply; 9+ messages in thread
From: Herbert Xu @ 2007-05-18  6:45 UTC (permalink / raw)
  To: Simon Arlott; +Cc: Randy Dunlap, Linux Kernel Mailing List, michal, ioe-lkml

On Sun, Apr 29, 2007 at 09:01:10AM +0100, Simon Arlott wrote:
> When this is compiled in it is run too early to do anything useful:
> [    6.052000] padlock: No VIA PadLock drivers have been loaded.
> [    6.052000] padlock: Using VIA PadLock ACE for AES algorithm.
> [    6.052000] padlock: Using VIA PadLock ACE for SHA1/SHA256 algorithms.
> 
> When it's a module it isn't doing anything special, the same functionality 
> can be provided in userspace by "probeall padlock padlock-aes padlock-sha" 
> in modules.conf if it is required.

BTW, I noticed that this prevented CRYPTO_ALGAPI from being marked as m
since it was selected by CRYPTO_DEV_PADLOCK.  So I'm turning it into a
tristate again.

Cheers,
-- 
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
d158325e407864793c5b0fbc85c74702753333b9
diff --git a/drivers/crypto/Kconfig b/drivers/crypto/Kconfig
index e678a33..bb90cbd 100644
--- a/drivers/crypto/Kconfig
+++ b/drivers/crypto/Kconfig
@@ -1,10 +1,10 @@
 menu "Hardware crypto devices"
 
 config CRYPTO_DEV_PADLOCK
-	bool "Support for VIA PadLock ACE"
+	tristate "Support for VIA PadLock ACE"
 	depends on X86_32
 	select CRYPTO_ALGAPI
-	default y
+	default m
 	help
 	  Some VIA processors come with an integrated crypto engine
 	  (so called VIA PadLock ACE, Advanced Cryptography Engine)

^ permalink raw reply related	[flat|nested] 9+ messages in thread

* Re: [PATCH (v2)] crypto: Remove pointless padlock module
  2007-05-18  6:45     ` Herbert Xu
@ 2007-05-19 19:28       ` Simon Arlott
  2007-05-20  2:40         ` Dave Jones
  2007-05-20  3:15         ` Herbert Xu
  0 siblings, 2 replies; 9+ messages in thread
From: Simon Arlott @ 2007-05-19 19:28 UTC (permalink / raw)
  To: Herbert Xu; +Cc: Randy Dunlap, Linux Kernel Mailing List, michal, ioe-lkml

On 18/05/07 07:45, Herbert Xu wrote:
> On Sun, Apr 29, 2007 at 09:01:10AM +0100, Simon Arlott wrote:
>> When this is compiled in it is run too early to do anything useful:
>> [    6.052000] padlock: No VIA PadLock drivers have been loaded.
>> [    6.052000] padlock: Using VIA PadLock ACE for AES algorithm.
>> [    6.052000] padlock: Using VIA PadLock ACE for SHA1/SHA256 algorithms.
>>
>> When it's a module it isn't doing anything special, the same functionality 
>> can be provided in userspace by "probeall padlock padlock-aes padlock-sha" 
>> in modules.conf if it is required.
> 
> BTW, I noticed that this prevented CRYPTO_ALGAPI from being marked as m
> since it was selected by CRYPTO_DEV_PADLOCK.  So I'm turning it into a
> tristate again.

It should be a bool that doesn't select anything, the AES and SHA modules 
will select CRYPTO_ALGAPI. It could also depend on MVIAC3_2 || MVIA_C7 
instead of X86_32.

-- 
Simon Arlott

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [PATCH (v2)] crypto: Remove pointless padlock module
  2007-05-19 19:28       ` Simon Arlott
@ 2007-05-20  2:40         ` Dave Jones
  2007-05-20  3:15         ` Herbert Xu
  1 sibling, 0 replies; 9+ messages in thread
From: Dave Jones @ 2007-05-20  2:40 UTC (permalink / raw)
  To: Simon Arlott
  Cc: Herbert Xu, Randy Dunlap, Linux Kernel Mailing List, michal, ioe-lkml

On Sat, May 19, 2007 at 08:28:17PM +0100, Simon Arlott wrote:

 > > BTW, I noticed that this prevented CRYPTO_ALGAPI from being marked as m
 > > since it was selected by CRYPTO_DEV_PADLOCK.  So I'm turning it into a
 > > tristate again.
 > 
 > It should be a bool that doesn't select anything, the AES and SHA modules 
 > will select CRYPTO_ALGAPI. It could also depend on MVIAC3_2 || MVIA_C7 
 > instead of X86_32.

Don't forget it's possible to build 'generic' x86 kernels, which would
also want this module.

	Dave

-- 
http://www.codemonkey.org.uk

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [PATCH (v2)] crypto: Remove pointless padlock module
  2007-05-19 19:28       ` Simon Arlott
  2007-05-20  2:40         ` Dave Jones
@ 2007-05-20  3:15         ` Herbert Xu
  2007-05-20  6:54           ` Simon Arlott
  1 sibling, 1 reply; 9+ messages in thread
From: Herbert Xu @ 2007-05-20  3:15 UTC (permalink / raw)
  To: Simon Arlott; +Cc: Randy Dunlap, Linux Kernel Mailing List, michal, ioe-lkml

On Sat, May 19, 2007 at 08:28:17PM +0100, Simon Arlott wrote:
> 
> It should be a bool that doesn't select anything, the AES and SHA modules 
> will select CRYPTO_ALGAPI. It could also depend on MVIAC3_2 || MVIA_C7 
> instead of X86_32.

Having it as a tristate means that we don't have to duplicate the
dependencies and selects that each padlock algorithm would otherwise
do.  So is there actually a problem with it being a tristate?

Cheers,
-- 
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [PATCH (v2)] crypto: Remove pointless padlock module
  2007-05-20  3:15         ` Herbert Xu
@ 2007-05-20  6:54           ` Simon Arlott
  0 siblings, 0 replies; 9+ messages in thread
From: Simon Arlott @ 2007-05-20  6:54 UTC (permalink / raw)
  To: Herbert Xu; +Cc: Randy Dunlap, Linux Kernel Mailing List, michal, ioe-lkml

On 20/05/07 04:15, Herbert Xu wrote:
> On Sat, May 19, 2007 at 08:28:17PM +0100, Simon Arlott wrote:
>> It should be a bool that doesn't select anything, the AES and SHA modules 
>> will select CRYPTO_ALGAPI. It could also depend on MVIAC3_2 || MVIA_C7 
>> instead of X86_32.
> 
> Having it as a tristate means that we don't have to duplicate the
> dependencies and selects that each padlock algorithm would otherwise
> do.  So is there actually a problem with it being a tristate?

It has nothing to compile as a module, so M makes no sense. Each algorithm 
already selects CRYPTO_ALGAPI indirectly.

-- 
Simon Arlott

^ permalink raw reply	[flat|nested] 9+ messages in thread

end of thread, other threads:[~2007-05-20  6:54 UTC | newest]

Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2007-04-28 23:40 [PATCH] crypto: Remove pointless padlock module Simon Arlott
2007-04-29  1:59 ` Randy Dunlap
2007-04-29  8:01   ` [PATCH (v2)] " Simon Arlott
2007-05-02  4:50     ` Herbert Xu
2007-05-18  6:45     ` Herbert Xu
2007-05-19 19:28       ` Simon Arlott
2007-05-20  2:40         ` Dave Jones
2007-05-20  3:15         ` Herbert Xu
2007-05-20  6:54           ` Simon Arlott

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.