Skip to contentSkip to conversation

crypto: Use padlock.ko only as a module

PATCH In review Simon Arlott 3 participants 4 messages Apr 28, 2007 – Apr 29, 2007 Crypto API

lore
Share & tools
lore
#0 lore raw

PATCH 1/1 crypto: Use padlock.ko only as a module

The padlock.ko module is completely useless when compiled in because it can't do anything and gets run too early to output 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.

---
drivers/crypto/Makefile | 4 +++-

1 files changed, 3 insertions(+), 1 deletions(-)
drivers/crypto/Makefile +3 -1
index 6059cf8..f0f7a73 100644
@@ -1,4 +1,6 @@
-obj-$(CONFIG_CRYPTO_DEV_PADLOCK) += padlock.o
+ifeq ($(CONFIG_CRYPTO_DEV_PADLOCK),m)
+obj-m += padlock.o
+endif

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

Signature · 4 lines
1.5.0.1

-- 
Simon Arlott
#1 lore raw
Quoted 20 lines · On Sat, 28 Apr 2007 17:44:42 +0100 Simon Arlott wrote:

The padlock.ko module is completely useless when compiled in because it can't do anything and gets run too early to output 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.
---
 drivers/crypto/Makefile |    4 +++-
 1 files changed, 3 insertions(+), 1 deletions(-)
drivers/crypto/Makefile +0 -0
index 6059cf8..f0f7a73 100644

drivers/crypto/Makefile line 6

Quoted 7 lines
drivers/crypto/Makefile +3 -1
@@ -1,4 +1,6 @@
-obj-$(CONFIG_CRYPTO_DEV_PADLOCK) += padlock.o
+ifeq ($(CONFIG_CRYPTO_DEV_PADLOCK),m)
+obj-m += padlock.o
+endif
 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

I think that we prefer to enforce config symbols in Kconfig files, not in Makefiles. E.g.,

---
 drivers/crypto/Kconfig |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/crypto/Kconfig +1 -1
@@ -2,7 +2,7 @@ menu "Hardware crypto devices"
 
 config CRYPTO_DEV_PADLOCK
 	tristate "Support for VIA PadLock ACE"
-	depends on X86_32
+	depends on X86_32 && m
 	select CRYPTO_ALGAPI
 	default m
 	help

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

#2 lore raw
Quoted 16 lines · Randy Dunlap

drivers/crypto/Makefile line 6

Quoted 11 lines · On Sat, 28 Apr 2007 17:44:42 +0100 Simon Arlott wrote:

The padlock.ko module is completely useless when compiled in because it can't do anything and gets run too early to output anything useful.

drivers/crypto/Makefile +3 -1
@@ -1,4 +1,6 @@
-obj-$(CONFIG_CRYPTO_DEV_PADLOCK) += padlock.o
+ifeq ($(CONFIG_CRYPTO_DEV_PADLOCK),m)
+obj-m += padlock.o
+endif
 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

I think that we prefer to enforce config symbols in Kconfig files, not in Makefiles. E.g.,

No, that would cause the wrong behaviour in this case. The two modules that depend on it for no reason work fine compiled in.

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.

Quoted 15 lines
---
 drivers/crypto/Kconfig |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/crypto/Kconfig +1 -1
@@ -2,7 +2,7 @@ menu "Hardware crypto devices"
 
 config CRYPTO_DEV_PADLOCK
 	tristate "Support for VIA PadLock ACE"
-	depends on X86_32
+	depends on X86_32 && m
 	select CRYPTO_ALGAPI
 	default m
 	help
Signature · 1 line
Simon Arlott
#3 lore raw

Hi Scott,

Quoted 3 lines · Simon Arlott

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.

And if it is so simple to do the same in userspace like you suggest, than that's much better.

Best Regards

Ingo Oeser