From: Andi Kleen <andi@firstfloor.org>
To: linux-kernel@vger.kernel.org
Cc: kay.sievers@vrfy.org, trenn@suse.de,
Andi Kleen <ak@linux.intel.com>,
davej@redhat.com, axboe@kernel.dk, hpa@zytor.com,
herbert@gondor.hengli.com.au, ying.huang@intel.com
Subject: [PATCH 02/10] crypto: Add support for x86 cpuid auto loading for x86 crypto drivers
Date: Wed, 7 Dec 2011 16:41:15 -0800 [thread overview]
Message-ID: <1323304882-27953-3-git-send-email-andi@firstfloor.org> (raw)
In-Reply-To: <1323304882-27953-1-git-send-email-andi@firstfloor.org>
From: Andi Kleen <ak@linux.intel.com>
Add support for auto-loading of crypto drivers based on cpuid features.
This enables auto-loading of the VIA and Intel specific drivers
for AES, hashing and CRCs.
Requires the earlier infrastructure patch to add x86 modinfo.
I kept it all in a single patch for now.
I dropped the printks when the driver cpuid doesn't match (imho
drivers never should print anything in such a case)
One drawback is that udev doesn't know if the drivers are used or not,
so they will be unconditionally loaded at boot up. That's better
than not loading them at all, like it often happens.
Cc: davej@redhat.com
Cc: trenn@suse.de
Cc: kay.sievers@vrfy.org
Cc: axboe@kernel.dk
Cc: hpa@zytor.com
Cc: herbert@gondor.apana.org.au
Cc: ying.huang@intel.com
Signed-off-by: Andi Kleen <ak@linux.intel.com>
---
arch/x86/crypto/aesni-intel_glue.c | 12 +++++++++---
arch/x86/crypto/crc32c-intel.c | 11 ++++++++---
arch/x86/crypto/ghash-clmulni-intel_glue.c | 12 ++++++++----
drivers/crypto/padlock-aes.c | 9 ++++++++-
drivers/crypto/padlock-sha.c | 16 ++++++++--------
5 files changed, 41 insertions(+), 19 deletions(-)
diff --git a/arch/x86/crypto/aesni-intel_glue.c b/arch/x86/crypto/aesni-intel_glue.c
index 545d0ce..4a34a77 100644
--- a/arch/x86/crypto/aesni-intel_glue.c
+++ b/arch/x86/crypto/aesni-intel_glue.c
@@ -28,6 +28,7 @@
#include <crypto/aes.h>
#include <crypto/cryptd.h>
#include <crypto/ctr.h>
+#include <asm/cpu_device_id.h>
#include <asm/i387.h>
#include <asm/aes.h>
#include <crypto/scatterwalk.h>
@@ -1253,14 +1254,19 @@ static struct crypto_alg __rfc4106_alg = {
};
#endif
+
+static struct x86_cpu_id aesni_cpu_id[] = {
+ X86_FEATURE_MATCH(X86_FEATURE_AES),
+ {}
+};
+MODULE_DEVICE_TABLE(x86cpu, aesni_cpu_id);
+
static int __init aesni_init(void)
{
int err;
- if (!cpu_has_aes) {
- printk(KERN_INFO "Intel AES-NI instructions are not detected.\n");
+ if (!x86_match_cpu(aesni_cpu_id))
return -ENODEV;
- }
if ((err = crypto_fpu_init()))
goto fpu_err;
diff --git a/arch/x86/crypto/crc32c-intel.c b/arch/x86/crypto/crc32c-intel.c
index b9d0026..0fe11a9 100644
--- a/arch/x86/crypto/crc32c-intel.c
+++ b/arch/x86/crypto/crc32c-intel.c
@@ -31,6 +31,7 @@
#include <crypto/internal/hash.h>
#include <asm/cpufeature.h>
+#include <asm/cpu_device_id.h>
#define CHKSUM_BLOCK_SIZE 1
#define CHKSUM_DIGEST_SIZE 4
@@ -173,13 +174,17 @@ static struct shash_alg alg = {
}
};
+static struct x86_cpu_id crc32c_cpu_id[] = {
+ X86_FEATURE_MATCH(X86_FEATURE_XMM4_2),
+ {}
+};
+MODULE_DEVICE_TABLE(x86cpu, crc32c_cpu_id);
static int __init crc32c_intel_mod_init(void)
{
- if (cpu_has_xmm4_2)
- return crypto_register_shash(&alg);
- else
+ if (!x86_match_cpu(crc32c_cpu_id))
return -ENODEV;
+ return crypto_register_shash(&alg);
}
static void __exit crc32c_intel_mod_fini(void)
diff --git a/arch/x86/crypto/ghash-clmulni-intel_glue.c b/arch/x86/crypto/ghash-clmulni-intel_glue.c
index 976aa64..4d5b128 100644
--- a/arch/x86/crypto/ghash-clmulni-intel_glue.c
+++ b/arch/x86/crypto/ghash-clmulni-intel_glue.c
@@ -20,6 +20,7 @@
#include <crypto/gf128mul.h>
#include <crypto/internal/hash.h>
#include <asm/i387.h>
+#include <asm/cpu_device_id.h>
#define GHASH_BLOCK_SIZE 16
#define GHASH_DIGEST_SIZE 16
@@ -294,15 +295,18 @@ static struct ahash_alg ghash_async_alg = {
},
};
+static struct x86_cpu_id pcmul_cpu_id[] = {
+ X86_FEATURE_MATCH(X86_FEATURE_PCLMULQDQ), /* Pickle-Mickle-Duck */
+ {}
+};
+MODULE_DEVICE_TABLE(x86cpu, pcmul_cpu_id);
+
static int __init ghash_pclmulqdqni_mod_init(void)
{
int err;
- if (!cpu_has_pclmulqdq) {
- printk(KERN_INFO "Intel PCLMULQDQ-NI instructions are not"
- " detected.\n");
+ if (!x86_match_cpu(pcmul_cpu_id))
return -ENODEV;
- }
err = crypto_register_shash(&ghash_alg);
if (err)
diff --git a/drivers/crypto/padlock-aes.c b/drivers/crypto/padlock-aes.c
index 29b9469..37b2e94 100644
--- a/drivers/crypto/padlock-aes.c
+++ b/drivers/crypto/padlock-aes.c
@@ -19,6 +19,7 @@
#include <linux/percpu.h>
#include <linux/smp.h>
#include <linux/slab.h>
+#include <asm/cpu_device_id.h>
#include <asm/byteorder.h>
#include <asm/processor.h>
#include <asm/i387.h>
@@ -503,12 +504,18 @@ static struct crypto_alg cbc_aes_alg = {
}
};
+static struct x86_cpu_id padlock_cpu_id[] = {
+ X86_FEATURE_MATCH(X86_FEATURE_XCRYPT),
+ {}
+};
+MODULE_DEVICE_TABLE(x86cpu, padlock_cpu_id);
+
static int __init padlock_init(void)
{
int ret;
struct cpuinfo_x86 *c = &cpu_data(0);
- if (!cpu_has_xcrypt)
+ if (!x86_match_cpu(padlock_cpu_id))
return -ENODEV;
if (!cpu_has_xcrypt_enabled) {
diff --git a/drivers/crypto/padlock-sha.c b/drivers/crypto/padlock-sha.c
index 06bdb4b..9266c0e 100644
--- a/drivers/crypto/padlock-sha.c
+++ b/drivers/crypto/padlock-sha.c
@@ -22,6 +22,7 @@
#include <linux/interrupt.h>
#include <linux/kernel.h>
#include <linux/scatterlist.h>
+#include <asm/cpu_device_id.h>
#include <asm/i387.h>
struct padlock_sha_desc {
@@ -526,6 +527,12 @@ static struct shash_alg sha256_alg_nano = {
}
};
+static struct x86_cpu_id padlock_sha_ids[] = {
+ X86_FEATURE_MATCH(X86_FEATURE_PHE),
+ {}
+};
+MODULE_DEVICE_TABLE(x86cpu, padlock_sha_ids);
+
static int __init padlock_init(void)
{
int rc = -ENODEV;
@@ -533,15 +540,8 @@ static int __init padlock_init(void)
struct shash_alg *sha1;
struct shash_alg *sha256;
- if (!cpu_has_phe) {
- printk(KERN_NOTICE PFX "VIA PadLock Hash Engine not detected.\n");
- return -ENODEV;
- }
-
- if (!cpu_has_phe_enabled) {
- printk(KERN_NOTICE PFX "VIA PadLock detected, but not enabled. Hmm, strange...\n");
+ if (!x86_match_cpu(padlock_sha_ids) || !cpu_has_phe_enabled)
return -ENODEV;
- }
/* Register the newly added algorithm module if on *
* VIA Nano processor, or else just do as before */
--
1.7.4.4
next prev parent reply other threads:[~2011-12-08 0:43 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-12-08 0:41 Updated cpu module autoprobing patchkit Andi Kleen
2011-12-08 0:41 ` [PATCH 01/10] Add driver auto probing for x86 features Andi Kleen
2011-12-08 1:57 ` H. Peter Anvin
2011-12-08 9:35 ` Jean Delvare
2011-12-08 14:45 ` Andi Kleen
2011-12-09 20:16 ` Jean Delvare
2011-12-09 20:24 ` Andi Kleen
2011-12-09 20:28 ` Jean Delvare
2011-12-16 1:25 ` H. Peter Anvin
2011-12-08 0:41 ` Andi Kleen [this message]
2011-12-08 0:41 ` [PATCH 03/10] intel-idle: convert to x86_cpu_id auto probing Andi Kleen
2011-12-08 0:41 ` [PATCH 04/10] ACPI: Load acpi-cpufreq from processor driver automatically Andi Kleen
2011-12-08 0:41 ` [PATCH 05/10] HWMON: Convert via-cputemp to x86 cpuid autoprobing Andi Kleen
2011-12-08 10:51 ` Jean Delvare
2011-12-08 0:41 ` [PATCH 06/10] HWMON: Convert coretemp " Andi Kleen
2011-12-08 2:40 ` Guenter Roeck
2011-12-08 7:24 ` Jean Delvare
2011-12-08 16:09 ` Guenter Roeck
2011-12-08 16:13 ` Jean Delvare
2011-12-08 20:58 ` Andi Kleen
2011-12-08 14:35 ` Andi Kleen
2011-12-08 0:41 ` [PATCH 07/10] cpufreq: Add support for x86 cpuinfo auto loading Andi Kleen
2011-12-08 1:07 ` Dave Jones
2011-12-08 1:13 ` Andi Kleen
2011-12-08 1:24 ` Dave Jones
2011-12-08 4:01 ` Andi Kleen
2011-12-08 8:49 ` Borislav Petkov
2011-12-08 14:37 ` Andi Kleen
2011-12-16 1:19 ` H. Peter Anvin
2011-12-16 2:12 ` Andi Kleen
2011-12-08 0:41 ` [PATCH 08/10] x86: autoload microcode driver on Intel and AMD systems Andi Kleen
2011-12-08 0:41 ` [PATCH 09/10] x86: Add a test module for cpu loading Andi Kleen
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1323304882-27953-3-git-send-email-andi@firstfloor.org \
--to=andi@firstfloor.org \
--cc=ak@linux.intel.com \
--cc=axboe@kernel.dk \
--cc=davej@redhat.com \
--cc=herbert@gondor.hengli.com.au \
--cc=hpa@zytor.com \
--cc=kay.sievers@vrfy.org \
--cc=linux-kernel@vger.kernel.org \
--cc=trenn@suse.de \
--cc=ying.huang@intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®