public inbox for linux-arm-kernel@lists.infradead.org
 help / color / mirror / Atom feed
From: linux@armlinux.org.uk (Russell King - ARM Linux)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v2 0/5] ARM: add module autoloading support for crypto modules
Date: Wed, 15 Feb 2017 20:00:02 +0000	[thread overview]
Message-ID: <20170215200002.GF27312@n2100.armlinux.org.uk> (raw)
In-Reply-To: <1484154118-22139-1-git-send-email-ard.biesheuvel@linaro.org>

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.

  parent reply	other threads:[~2017-02-15 20:00 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-01-11 17:01 [PATCH v2 0/5] ARM: add module autoloading support for crypto modules Ard Biesheuvel
2017-01-11 17:01 ` [PATCH v2 1/5] ARM: wire up HWCAP2 feature bits to the CPU modalias Ard Biesheuvel
2017-01-11 17:01 ` [PATCH v2 2/5] crypto: arm/aes-ce - enable module autoloading based on CPU feature bits Ard Biesheuvel
2017-01-11 17:01 ` [PATCH v2 3/5] crypto: arm/ghash-ce " Ard Biesheuvel
2017-01-11 17:01 ` [PATCH v2 4/5] crypto: arm/sha1-ce " Ard Biesheuvel
2017-01-11 17:01 ` [PATCH v2 5/5] crypto: arm/sha2-ce " Ard Biesheuvel
2017-01-19 18:23 ` [PATCH v2 0/5] ARM: add module autoloading support for crypto modules Ard Biesheuvel
2017-01-31 13:47   ` Ard Biesheuvel
2017-02-15 17:16     ` Ard Biesheuvel
2017-02-15 19:24       ` Russell King - ARM Linux
2017-02-15 19:29         ` Ard Biesheuvel
2017-02-15 19:35           ` Russell King - ARM Linux
2017-02-15 20:00 ` Russell King - ARM Linux [this message]
2017-02-15 20:04   ` Ard Biesheuvel
2017-02-15 20:07     ` Russell King - ARM Linux
2017-02-15 20:38       ` Ard Biesheuvel

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=20170215200002.GF27312@n2100.armlinux.org.uk \
    --to=linux@armlinux.org.uk \
    --cc=linux-arm-kernel@lists.infradead.org \
    /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