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 <jrnieder@xxxxxxxxx>
---
Herbert Xu wrote:
> Ralf Jung <ralfjung-e@xxxxxx> 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 from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
