[PATCH v2 0/5] ARM: add module autoloading support for crypto modules

[PATCH v2 0/5] ARM: add module autoloading support for crypto modules

[Ard Biesheuvel]

This series wires up the crypto modules that use the ARM 32-bit versions of
the ARMv8 Crypto Extensions to udev autoloading, by exposing the HWCAP2
feature bits via the CPU modalias. This is very similar to the arm64
implementation, with the notable exception that ARM has its CPU feature
definitions split across HWCAP and HWCAP2.

Given that the crypto feature bits are all exposed via HWCAP2, and considering
that there are currently no features exposed via HWCAP that are relevant to
udev module autoloading, exposing HWCAP2 only should be sufficient, at least
for now.

Changes since v1:
- rebase onto v4.10-rc2

Ard Biesheuvel (5):
  ARM: wire up HWCAP2 feature bits to the CPU modalias
  crypto: arm/aes-ce - enable module autoloading based on CPU feature
    bits
  crypto: arm/ghash-ce - enable module autoloading based on CPU feature
    bits
  crypto: arm/sha1-ce - enable module autoloading based on CPU feature
    bits
  crypto: arm/sha2-ce - enable module autoloading based on CPU feature
    bits

 arch/arm/Kconfig                  |  1 +
 arch/arm/crypto/aes-ce-glue.c     |  6 ++--
 arch/arm/crypto/ghash-ce-glue.c   |  6 ++--
 arch/arm/crypto/sha1-ce-glue.c    |  5 ++-
 arch/arm/crypto/sha2-ce-glue.c    |  5 ++-
 arch/arm/include/asm/cpufeature.h | 32 ++++++++++++++++++++
 6 files changed, 41 insertions(+), 14 deletions(-)
 create mode 100644 arch/arm/include/asm/cpufeature.h

-- 
2.7.4

[PATCH v2 1/5] ARM: wire up HWCAP2 feature bits to the CPU modalias

[Ard Biesheuvel]

Wire up the generic support for exposing CPU feature bits via the
modalias in /sys/device/system/cpu. This allows udev to automatically
load modules for things like crypto algorithms that are implemented
using optional instructions.

Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
---
 arch/arm/Kconfig                  |  1 +
 arch/arm/include/asm/cpufeature.h | 32 ++++++++++++++++++++
 2 files changed, 33 insertions(+)

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 5fab553fd03a..3758466365ee 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -21,6 +21,7 @@ config ARM
 	select GENERIC_ALLOCATOR
 	select GENERIC_ATOMIC64 if (CPU_V7M || CPU_V6 || !CPU_32v6K || !AEABI)
 	select GENERIC_CLOCKEVENTS_BROADCAST if SMP
+	select GENERIC_CPU_AUTOPROBE
 	select GENERIC_EARLY_IOREMAP
 	select GENERIC_IDLE_POLL_SETUP
 	select GENERIC_IRQ_PROBE
diff --git a/arch/arm/include/asm/cpufeature.h b/arch/arm/include/asm/cpufeature.h
new file mode 100644
index 000000000000..134bd4c63d53
--- /dev/null
+++ b/arch/arm/include/asm/cpufeature.h
@@ -0,0 +1,32 @@
+/*
+ * Copyright (C) 2017 Linaro Ltd. <ard.biesheuvel@linaro.org>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#ifndef __ASM_CPUFEATURE_H
+#define __ASM_CPUFEATURE_H
+
+#include <asm/hwcap.h>
+
+/*
+ * Due to the fact that ELF_HWCAP is a 32-bit type on ARM, and given the number
+ * of optional CPU features it defines, ARM's CPU capability bits have been
+ * distributed over separate elf_hwcap and elf_hwcap2 variables, each of which
+ * covers a subset of the available CPU features.
+ *
+ * Currently, only a few of those are suitable for automatic module loading
+ * (which is the primary use case of this facility) and those happen to be all
+ * covered by HWCAP2. So let's only expose those via the CPU modalias for now.
+ */
+#define MAX_CPU_FEATURES	(8 * sizeof(elf_hwcap2))
+#define cpu_feature(x)		ilog2(HWCAP2_ ## x)
+
+static inline bool cpu_have_feature(unsigned int num)
+{
+	return elf_hwcap2 & (1UL << num);
+}
+
+#endif
-- 
2.7.4

[PATCH v2 2/5] crypto: arm/aes-ce - enable module autoloading based on CPU feature bits

[Ard Biesheuvel]

Make the module autoloadable by tying it to the CPU feature bit that
describes whether the optional instructions it relies on are implemented
by the current CPU.

Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
---
 arch/arm/crypto/aes-ce-glue.c | 6 ++----
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/arch/arm/crypto/aes-ce-glue.c b/arch/arm/crypto/aes-ce-glue.c
index 8857531915bf..98c68ad101e5 100644
--- a/arch/arm/crypto/aes-ce-glue.c
+++ b/arch/arm/crypto/aes-ce-glue.c
@@ -14,6 +14,7 @@
 #include <crypto/aes.h>
 #include <crypto/internal/simd.h>
 #include <crypto/internal/skcipher.h>
+#include <linux/cpufeature.h>
 #include <linux/module.h>
 #include <crypto/xts.h>
 
@@ -428,9 +429,6 @@ static int __init aes_init(void)
 	int err;
 	int i;
 
-	if (!(elf_hwcap2 & HWCAP2_AES))
-		return -ENODEV;
-
 	err = crypto_register_skciphers(aes_algs, ARRAY_SIZE(aes_algs));
 	if (err)
 		return err;
@@ -454,5 +452,5 @@ static int __init aes_init(void)
 	return err;
 }
 
-module_init(aes_init);
+module_cpu_feature_match(AES, aes_init);
 module_exit(aes_exit);
-- 
2.7.4

[PATCH v2 3/5] crypto: arm/ghash-ce - enable module autoloading based on CPU feature bits

[Ard Biesheuvel]

Make the module autoloadable by tying it to the CPU feature bit that
describes whether the optional instructions it relies on are implemented
by the current CPU.

Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
---
 arch/arm/crypto/ghash-ce-glue.c | 6 ++----
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/arch/arm/crypto/ghash-ce-glue.c b/arch/arm/crypto/ghash-ce-glue.c
index 7546b3c02466..6bac8bea9f1e 100644
--- a/arch/arm/crypto/ghash-ce-glue.c
+++ b/arch/arm/crypto/ghash-ce-glue.c
@@ -15,6 +15,7 @@
 #include <crypto/cryptd.h>
 #include <crypto/internal/hash.h>
 #include <crypto/gf128mul.h>
+#include <linux/cpufeature.h>
 #include <linux/crypto.h>
 #include <linux/module.h>
 
@@ -311,9 +312,6 @@ static int __init ghash_ce_mod_init(void)
 {
 	int err;
 
-	if (!(elf_hwcap2 & HWCAP2_PMULL))
-		return -ENODEV;
-
 	err = crypto_register_shash(&ghash_alg);
 	if (err)
 		return err;
@@ -334,5 +332,5 @@ static void __exit ghash_ce_mod_exit(void)
 	crypto_unregister_shash(&ghash_alg);
 }
 
-module_init(ghash_ce_mod_init);
+module_cpu_feature_match(PMULL, ghash_ce_mod_init);
 module_exit(ghash_ce_mod_exit);
-- 
2.7.4

[PATCH v2 4/5] crypto: arm/sha1-ce - enable module autoloading based on CPU feature bits

[Ard Biesheuvel]

Make the module autoloadable by tying it to the CPU feature bit that
describes whether the optional instructions it relies on are implemented
by the current CPU.

Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
---
 arch/arm/crypto/sha1-ce-glue.c | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/arch/arm/crypto/sha1-ce-glue.c b/arch/arm/crypto/sha1-ce-glue.c
index 80bc2fcd241a..555f72b5e659 100644
--- a/arch/arm/crypto/sha1-ce-glue.c
+++ b/arch/arm/crypto/sha1-ce-glue.c
@@ -11,6 +11,7 @@
 #include <crypto/internal/hash.h>
 #include <crypto/sha.h>
 #include <crypto/sha1_base.h>
+#include <linux/cpufeature.h>
 #include <linux/crypto.h>
 #include <linux/module.h>
 
@@ -82,8 +83,6 @@ static struct shash_alg alg = {
 
 static int __init sha1_ce_mod_init(void)
 {
-	if (!(elf_hwcap2 & HWCAP2_SHA1))
-		return -ENODEV;
 	return crypto_register_shash(&alg);
 }
 
@@ -92,5 +91,5 @@ static void __exit sha1_ce_mod_fini(void)
 	crypto_unregister_shash(&alg);
 }
 
-module_init(sha1_ce_mod_init);
+module_cpu_feature_match(SHA1, sha1_ce_mod_init);
 module_exit(sha1_ce_mod_fini);
-- 
2.7.4

[PATCH v2 5/5] crypto: arm/sha2-ce - enable module autoloading based on CPU feature bits

[Ard Biesheuvel]

Make the module autoloadable by tying it to the CPU feature bit that
describes whether the optional instructions it relies on are implemented
by the current CPU.

Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
---
 arch/arm/crypto/sha2-ce-glue.c | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/arch/arm/crypto/sha2-ce-glue.c b/arch/arm/crypto/sha2-ce-glue.c
index 0755b2d657f3..df4dcef054ae 100644
--- a/arch/arm/crypto/sha2-ce-glue.c
+++ b/arch/arm/crypto/sha2-ce-glue.c
@@ -11,6 +11,7 @@
 #include <crypto/internal/hash.h>
 #include <crypto/sha.h>
 #include <crypto/sha256_base.h>
+#include <linux/cpufeature.h>
 #include <linux/crypto.h>
 #include <linux/module.h>
 
@@ -100,8 +101,6 @@ static struct shash_alg algs[] = { {
 
 static int __init sha2_ce_mod_init(void)
 {
-	if (!(elf_hwcap2 & HWCAP2_SHA2))
-		return -ENODEV;
 	return crypto_register_shashes(algs, ARRAY_SIZE(algs));
 }
 
@@ -110,5 +109,5 @@ static void __exit sha2_ce_mod_fini(void)
 	crypto_unregister_shashes(algs, ARRAY_SIZE(algs));
 }
 
-module_init(sha2_ce_mod_init);
+module_cpu_feature_match(SHA2, sha2_ce_mod_init);
 module_exit(sha2_ce_mod_fini);
-- 
2.7.4

[PATCH v2 0/5] ARM: add module autoloading support for crypto modules

[Ard Biesheuvel]

On 11 January 2017 at 17:01, Ard Biesheuvel <ard.biesheuvel@linaro.org> wrote:
> This series wires up the crypto modules that use the ARM 32-bit versions of
> the ARMv8 Crypto Extensions to udev autoloading, by exposing the HWCAP2
> feature bits via the CPU modalias. This is very similar to the arm64
> implementation, with the notable exception that ARM has its CPU feature
> definitions split across HWCAP and HWCAP2.
>
> Given that the crypto feature bits are all exposed via HWCAP2, and considering
> that there are currently no features exposed via HWCAP that are relevant to
> udev module autoloading, exposing HWCAP2 only should be sufficient, at least
> for now.
>
> Changes since v1:
> - rebase onto v4.10-rc2
>
> Ard Biesheuvel (5):
>   ARM: wire up HWCAP2 feature bits to the CPU modalias

Ping?

>   crypto: arm/aes-ce - enable module autoloading based on CPU feature
>     bits
>   crypto: arm/ghash-ce - enable module autoloading based on CPU feature
>     bits
>   crypto: arm/sha1-ce - enable module autoloading based on CPU feature
>     bits
>   crypto: arm/sha2-ce - enable module autoloading based on CPU feature
>     bits
>
>  arch/arm/Kconfig                  |  1 +
>  arch/arm/crypto/aes-ce-glue.c     |  6 ++--
>  arch/arm/crypto/ghash-ce-glue.c   |  6 ++--
>  arch/arm/crypto/sha1-ce-glue.c    |  5 ++-
>  arch/arm/crypto/sha2-ce-glue.c    |  5 ++-
>  arch/arm/include/asm/cpufeature.h | 32 ++++++++++++++++++++
>  6 files changed, 41 insertions(+), 14 deletions(-)
>  create mode 100644 arch/arm/include/asm/cpufeature.h
>
> --
> 2.7.4
>

[PATCH v2 0/5] ARM: add module autoloading support for crypto modules

[Ard Biesheuvel]

On 19 January 2017 at 18:23, Ard Biesheuvel <ard.biesheuvel@linaro.org> wrote:
> On 11 January 2017 at 17:01, Ard Biesheuvel <ard.biesheuvel@linaro.org> wrote:
>> This series wires up the crypto modules that use the ARM 32-bit versions of
>> the ARMv8 Crypto Extensions to udev autoloading, by exposing the HWCAP2
>> feature bits via the CPU modalias. This is very similar to the arm64
>> implementation, with the notable exception that ARM has its CPU feature
>> definitions split across HWCAP and HWCAP2.
>>
>> Given that the crypto feature bits are all exposed via HWCAP2, and considering
>> that there are currently no features exposed via HWCAP that are relevant to
>> udev module autoloading, exposing HWCAP2 only should be sufficient, at least
>> for now.
>>
>> Changes since v1:
>> - rebase onto v4.10-rc2
>>
>> Ard Biesheuvel (5):
>>   ARM: wire up HWCAP2 feature bits to the CPU modalias
>
> Ping?
>

Ping?

[PATCH v2 0/5] ARM: add module autoloading support for crypto modules

[Ard Biesheuvel]

On 31 January 2017 at 13:47, Ard Biesheuvel <ard.biesheuvel@linaro.org> wrote:
> On 19 January 2017 at 18:23, Ard Biesheuvel <ard.biesheuvel@linaro.org> wrote:
>> On 11 January 2017 at 17:01, Ard Biesheuvel <ard.biesheuvel@linaro.org> wrote:
>>> This series wires up the crypto modules that use the ARM 32-bit versions of
>>> the ARMv8 Crypto Extensions to udev autoloading, by exposing the HWCAP2
>>> feature bits via the CPU modalias. This is very similar to the arm64
>>> implementation, with the notable exception that ARM has its CPU feature
>>> definitions split across HWCAP and HWCAP2.
>>>
>>> Given that the crypto feature bits are all exposed via HWCAP2, and considering
>>> that there are currently no features exposed via HWCAP that are relevant to
>>> udev module autoloading, exposing HWCAP2 only should be sufficient, at least
>>> for now.
>>>
>>> Changes since v1:
>>> - rebase onto v4.10-rc2
>>>
>>> Ard Biesheuvel (5):
>>>   ARM: wire up HWCAP2 feature bits to the CPU modalias
>>
>> Ping?
>>
>
> Ping?

Ping?

[PATCH v2 0/5] ARM: add module autoloading support for crypto modules

[Russell King - ARM Linux]

On Wed, Feb 15, 2017 at 05:16:47PM +0000, Ard Biesheuvel wrote:
> On 31 January 2017 at 13:47, Ard Biesheuvel <ard.biesheuvel@linaro.org> wrote:
> > On 19 January 2017 at 18:23, Ard Biesheuvel <ard.biesheuvel@linaro.org> wrote:
> >> On 11 January 2017 at 17:01, Ard Biesheuvel <ard.biesheuvel@linaro.org> wrote:
> >>> This series wires up the crypto modules that use the ARM 32-bit versions of
> >>> the ARMv8 Crypto Extensions to udev autoloading, by exposing the HWCAP2
> >>> feature bits via the CPU modalias. This is very similar to the arm64
> >>> implementation, with the notable exception that ARM has its CPU feature
> >>> definitions split across HWCAP and HWCAP2.
> >>>
> >>> Given that the crypto feature bits are all exposed via HWCAP2, and considering
> >>> that there are currently no features exposed via HWCAP that are relevant to
> >>> udev module autoloading, exposing HWCAP2 only should be sufficient, at least
> >>> for now.
> >>>
> >>> Changes since v1:
> >>> - rebase onto v4.10-rc2
> >>>
> >>> Ard Biesheuvel (5):
> >>>   ARM: wire up HWCAP2 feature bits to the CPU modalias
> >>
> >> Ping?
> >>
> >
> > Ping?
> 
> Ping?

Sorry, but whom are you pinging?

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.

[PATCH v2 0/5] ARM: add module autoloading support for crypto modules

[Ard Biesheuvel]

On 15 February 2017 at 19:24, Russell King - ARM Linux
<linux@armlinux.org.uk> wrote:
> On Wed, Feb 15, 2017 at 05:16:47PM +0000, Ard Biesheuvel wrote:
>> On 31 January 2017 at 13:47, Ard Biesheuvel <ard.biesheuvel@linaro.org> wrote:
>> > On 19 January 2017 at 18:23, Ard Biesheuvel <ard.biesheuvel@linaro.org> wrote:
>> >> On 11 January 2017 at 17:01, Ard Biesheuvel <ard.biesheuvel@linaro.org> wrote:
>> >>> This series wires up the crypto modules that use the ARM 32-bit versions of
>> >>> the ARMv8 Crypto Extensions to udev autoloading, by exposing the HWCAP2
>> >>> feature bits via the CPU modalias. This is very similar to the arm64
>> >>> implementation, with the notable exception that ARM has its CPU feature
>> >>> definitions split across HWCAP and HWCAP2.
>> >>>
>> >>> Given that the crypto feature bits are all exposed via HWCAP2, and considering
>> >>> that there are currently no features exposed via HWCAP that are relevant to
>> >>> udev module autoloading, exposing HWCAP2 only should be sufficient, at least
>> >>> for now.
>> >>>
>> >>> Changes since v1:
>> >>> - rebase onto v4.10-rc2
>> >>>
>> >>> Ard Biesheuvel (5):
>> >>>   ARM: wire up HWCAP2 feature bits to the CPU modalias
>> >>
>> >> Ping?
>> >>
>> >
>> > Ping?
>>
>> Ping?
>
> Sorry, but whom are you pinging?
>

You. This is something you were going to look at, then couldn't find
the email and asked me to resend, which I did.

http://marc.info/?l=linux-crypto-vger&m=147678795532341&w=2
http://marc.info/?l=linux-arm-kernel&m=148415420105771

[PATCH v2 0/5] ARM: add module autoloading support for crypto modules

[Russell King - ARM Linux]

On Wed, Feb 15, 2017 at 07:29:39PM +0000, Ard Biesheuvel wrote:
> On 15 February 2017 at 19:24, Russell King - ARM Linux
> <linux@armlinux.org.uk> wrote:
> > On Wed, Feb 15, 2017 at 05:16:47PM +0000, Ard Biesheuvel wrote:
> >> On 31 January 2017 at 13:47, Ard Biesheuvel <ard.biesheuvel@linaro.org> wrote:
> >> > On 19 January 2017 at 18:23, Ard Biesheuvel <ard.biesheuvel@linaro.org> wrote:
> >> >> On 11 January 2017 at 17:01, Ard Biesheuvel <ard.biesheuvel@linaro.org> wrote:
> >> >>> This series wires up the crypto modules that use the ARM 32-bit versions of
> >> >>> the ARMv8 Crypto Extensions to udev autoloading, by exposing the HWCAP2
> >> >>> feature bits via the CPU modalias. This is very similar to the arm64
> >> >>> implementation, with the notable exception that ARM has its CPU feature
> >> >>> definitions split across HWCAP and HWCAP2.
> >> >>>
> >> >>> Given that the crypto feature bits are all exposed via HWCAP2, and considering
> >> >>> that there are currently no features exposed via HWCAP that are relevant to
> >> >>> udev module autoloading, exposing HWCAP2 only should be sufficient, at least
> >> >>> for now.
> >> >>>
> >> >>> Changes since v1:
> >> >>> - rebase onto v4.10-rc2
> >> >>>
> >> >>> Ard Biesheuvel (5):
> >> >>>   ARM: wire up HWCAP2 feature bits to the CPU modalias
> >> >>
> >> >> Ping?
> >> >>
> >> >
> >> > Ping?
> >>
> >> Ping?
> >
> > Sorry, but whom are you pinging?
> >
> 
> You. This is something you were going to look at, then couldn't find
> the email and asked me to resend, which I did.
> 
> http://marc.info/?l=linux-crypto-vger&m=147678795532341&w=2
> http://marc.info/?l=linux-arm-kernel&m=148415420105771

Right, I'd forgotten, and as it wasn't sent _TO_ me, I wasn't paying
attention.  If you want me to do something, then always send _TO_ me.
Don't just CC me.

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.

[PATCH v2 0/5] ARM: add module autoloading support for crypto modules

[Russell King - ARM Linux]

On Wed, Jan 11, 2017 at 05:01:53PM +0000, Ard Biesheuvel wrote:
> This series wires up the crypto modules that use the ARM 32-bit versions of
> the ARMv8 Crypto Extensions to udev autoloading, by exposing the HWCAP2
> feature bits via the CPU modalias. This is very similar to the arm64
> implementation, with the notable exception that ARM has its CPU feature
> definitions split across HWCAP and HWCAP2.

Note that Aarch64 has:

MODALIAS=cpu:type:aarch64:feature:,0000,0001,0002,0003,0004,0005,0006,0007

which looks weird with the first numeric entry starting with a ','.

Now as for ARM, yes, we have the hwcap feature split across the two
(because HWCAP2 didn't exist originally.)  What I'm concerned about
is that restricting the initial implementation to HWCAP2 bits means
that we'd have to rework all users if we wanted to include the HWCAP
bits later on (consider what the change would be to add HWCAP_x
support to this later on.)

I would much rather we start out now with an offset of 32 on the
numeric value exposed to userspace, so that should we want to extend
it to the HWCAP field, we can do so safely.

While we're stuffing HWCAP2 with new bits, please note that it is
also limited to 32 bits, just like the HWCAP field is.

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.

[PATCH v2 0/5] ARM: add module autoloading support for crypto modules

[Ard Biesheuvel]

On 15 February 2017 at 20:00, Russell King - ARM Linux
<linux@armlinux.org.uk> wrote:
> On Wed, Jan 11, 2017 at 05:01:53PM +0000, Ard Biesheuvel wrote:
>> This series wires up the crypto modules that use the ARM 32-bit versions of
>> the ARMv8 Crypto Extensions to udev autoloading, by exposing the HWCAP2
>> feature bits via the CPU modalias. This is very similar to the arm64
>> implementation, with the notable exception that ARM has its CPU feature
>> definitions split across HWCAP and HWCAP2.
>
> Note that Aarch64 has:
>
> MODALIAS=cpu:type:aarch64:feature:,0000,0001,0002,0003,0004,0005,0006,0007
>
> which looks weird with the first numeric entry starting with a ','.
>

IIRC this is deliberate, since the udev code matches the feature field
for *nnnn*, which is what the module alias exposes.

> Now as for ARM, yes, we have the hwcap feature split across the two
> (because HWCAP2 didn't exist originally.)  What I'm concerned about
> is that restricting the initial implementation to HWCAP2 bits means
> that we'd have to rework all users if we wanted to include the HWCAP
> bits later on (consider what the change would be to add HWCAP_x
> support to this later on.)
>
> I would much rather we start out now with an offset of 32 on the
> numeric value exposed to userspace, so that should we want to extend
> it to the HWCAP field, we can do so safely.
>

OK, that is easily done.

> While we're stuffing HWCAP2 with new bits, please note that it is
> also limited to 32 bits, just like the HWCAP field is.
>

Yes, I am aware of that. But there aren't /that/ many optional
features that lend themselves for module autoloading.

[PATCH v2 0/5] ARM: add module autoloading support for crypto modules

[Russell King - ARM Linux]

On Wed, Feb 15, 2017 at 08:04:07PM +0000, Ard Biesheuvel wrote:
> On 15 February 2017 at 20:00, Russell King - ARM Linux
> <linux@armlinux.org.uk> wrote:
> > On Wed, Jan 11, 2017 at 05:01:53PM +0000, Ard Biesheuvel wrote:
> >> This series wires up the crypto modules that use the ARM 32-bit versions of
> >> the ARMv8 Crypto Extensions to udev autoloading, by exposing the HWCAP2
> >> feature bits via the CPU modalias. This is very similar to the arm64
> >> implementation, with the notable exception that ARM has its CPU feature
> >> definitions split across HWCAP and HWCAP2.
> >
> > Note that Aarch64 has:
> >
> > MODALIAS=cpu:type:aarch64:feature:,0000,0001,0002,0003,0004,0005,0006,0007
> >
> > which looks weird with the first numeric entry starting with a ','.
> >
> 
> IIRC this is deliberate, since the udev code matches the feature field
> for *nnnn*, which is what the module alias exposes.

I noticed, feature:*0000* matches both "feature:0000" and "feature:,0000".

> Yes, I am aware of that. But there aren't /that/ many optional
> features that lend themselves for module autoloading.

Yes.  Once we've exhausted the HWCAP2 space, we'll either have to add
HWCAP3 or finish off using the unused 11 in the HWCAP space.

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.

[PATCH v2 0/5] ARM: add module autoloading support for crypto modules

[Ard Biesheuvel]

On 15 February 2017 at 20:07, Russell King - ARM Linux
<linux@armlinux.org.uk> wrote:
> On Wed, Feb 15, 2017 at 08:04:07PM +0000, Ard Biesheuvel wrote:
>> On 15 February 2017 at 20:00, Russell King - ARM Linux
>> <linux@armlinux.org.uk> wrote:
>> > On Wed, Jan 11, 2017 at 05:01:53PM +0000, Ard Biesheuvel wrote:
>> >> This series wires up the crypto modules that use the ARM 32-bit versions of
>> >> the ARMv8 Crypto Extensions to udev autoloading, by exposing the HWCAP2
>> >> feature bits via the CPU modalias. This is very similar to the arm64
>> >> implementation, with the notable exception that ARM has its CPU feature
>> >> definitions split across HWCAP and HWCAP2.
>> >
>> > Note that Aarch64 has:
>> >
>> > MODALIAS=cpu:type:aarch64:feature:,0000,0001,0002,0003,0004,0005,0006,0007
>> >
>> > which looks weird with the first numeric entry starting with a ','.
>> >
>>
>> IIRC this is deliberate, since the udev code matches the feature field
>> for *nnnn*, which is what the module alias exposes.
>
> I noticed, feature:*0000* matches both "feature:0000" and "feature:,0000".
>

Right. It's been a while since I ported that code from x86 to generic,
and I don't remember making many changes to it.

>> Yes, I am aware of that. But there aren't /that/ many optional
>> features that lend themselves for module autoloading.
>
> Yes.  Once we've exhausted the HWCAP2 space, we'll either have to add
> HWCAP3 or finish off using the unused 11 in the HWCAP space.
>

For now, we should be fine. I will respin with the + 32 added.