@@ -396,6 +396,14 @@ static const char *crypto_hwcaps[] = {
"xmpmul", "xmontmul", "xmontsqr",
};
+/* crypto_hwcaps[] is indexed by CFR bit. The machine description names
+ * the Montgomery operations with one string each where CFR splits them
+ * into a multiply and a square, so those names need a list of their own.
+ */
+static const char * const crypto_mdesc_hwcaps[] __initconst = {
+ "mont", "xmont",
+};
+
void cpucap_info(struct seq_file *m)
{
unsigned long caps = sparc64_elf_hwcap;
@@ -506,6 +514,12 @@ static unsigned long __init mdesc_cpu_hwcap_list(void)
known = true;
}
}
+ for (i = 0; i < ARRAY_SIZE(crypto_mdesc_hwcaps); i++) {
+ if (!strcmp(prop, crypto_mdesc_hwcaps[i])) {
+ caps |= HWCAP_SPARC_CRYPTO;
+ known = true;
+ }
+ }
if (!known)
pr_info("CPU CAPS: unknown hwcap-list entry '%s'\n",
crypto_hwcaps[] is indexed by CFR bit, and mdesc_cpu_hwcap_list() reuses it to match hwcap-list strings. Those are two different namespaces. CFR has a bit each for the Montgomery multiply and square, while the machine description names the pair with one string, so "mont" and "xmont" match nothing. Nothing breaks today: any recognised crypto name sets HWCAP_SPARC_CRYPTO, and a chip offering the Montgomery operations offers "aes" too. It is still wrong, since a machine description listing only the Montgomery names would leave HWCAP_SPARC_CRYPTO clear. Match them from a list of their own rather than adding them to crypto_hwcaps[], where they would claim a CFR bit that means something else. Signed-off-by: Stian Halseth <stian@itx.no> --- arch/sparc/kernel/setup_64.c | 14 ++++++++++++++ 1 file changed, 14 insertions(+)