When loading aes via the module alias, a padlock module failing to
load due to missing hardware is not particularly notable. With
v2.6.27-rc1~1107^2~14 (crypto: padlock - Make module loading quieter
when hardware isn't available, 2008-07-03), the padlock-aes module
suppresses the relevant messages when the "quiet" flag is in use; but
better to suppress this particular message completely, since the
administrator can already distinguish such errors by the absence of a
message indicating initialization failing or succeeding.
This avoids occasional messages in syslog of the form
padlock_aes: VIA PadLock not detected.
Signed-off-by: Jonathan Nieder <[email protected]>
---
Herbert Xu wrote:
> Ralf Jung <[email protected]> wrote:
>> With current Debian testing (Kernel 2.6.39), I am getting this error on each
>> boot:
>> FATAL: Error inserting padlock_sha (/lib/modules/2.6.39-2-
>> amd64/kernel/drivers/crypto/padlock-sha.ko): No such device
[...]
> That message comes from user-space and needs to be fixed there.
Thanks. Indeed, I was sloppy when reading the original report and
thought he was talking about a different message. Sorry for the
noise.
drivers/crypto/padlock-aes.c | 4 +---
1 files changed, 1 insertions(+), 3 deletions(-)
diff --git a/drivers/crypto/padlock-aes.c b/drivers/crypto/padlock-aes.c
index db33d300..29b9469f 100644
--- a/drivers/crypto/padlock-aes.c
+++ b/drivers/crypto/padlock-aes.c
@@ -508,10 +508,8 @@ static int __init padlock_init(void)
int ret;
struct cpuinfo_x86 *c = &cpu_data(0);
- if (!cpu_has_xcrypt) {
- printk(KERN_NOTICE PFX "VIA PadLock not detected.\n");
+ if (!cpu_has_xcrypt)
return -ENODEV;
- }
if (!cpu_has_xcrypt_enabled) {
printk(KERN_NOTICE PFX "VIA PadLock detected, but not enabled.
Hmm, strange...\n");
--
1.7.6
--
To UNSUBSCRIBE, email to [email protected]
with a subject of "unsubscribe". Trouble? Contact [email protected]
