The tegra crypto driver uses the tegra_chip_uid API for the RNG
calculation. If one wants to build tegra-aes as a module, then
tegra_chip_uid needs to be exported.
I have also posted arm: tegra: export tegra_chip_uid to the mach-tegra
maintainers to get this patch into their tree, but for
From: Henning Heinold hein...@inf.fu-berlin.de
The crypto driver will need this api to use
it in the RNG calculations. In order to build
the crypto driver as a module, tegra_chip_uid
has to be exported.
Change-Id: I1372c06b8cfef74699ea9cd5cfca92648bcd982b
Signed-off-by: Henning Heinold
driver supports ecb/cbc/ofb/ansi_x9.31rng modes,
128, 192 and 256-bit key sizes
Change-Id: I3f923576ac80894cdd35b2db8e214e7d18e19c21
Signed-off-by: Varun Wadekar vwade...@nvidia.com
---
drivers/crypto/Kconfig | 11 +
drivers/crypto/Makefile|1 +
drivers/crypto/tegra-aes.c | 1102
v6:
---
Fixed the subject line in the cover letter and removed the
'Change-Id: ' lines from the commits
v5:
---
The tegra crypto driver uses the tegra_chip_uid API for the RNG
calculation. If one wants to build tegra-aes as a module, then
tegra_chip_uid needs to be exported.
I have also
driver supports ecb/cbc/ofb/ansi_x9.31rng modes,
128, 192 and 256-bit key sizes
Signed-off-by: Varun Wadekar vwade...@nvidia.com
---
drivers/crypto/Kconfig | 11 +
drivers/crypto/Makefile|1 +
drivers/crypto/tegra-aes.c | 1102
On Wed, 16 Nov 2011 12:44:50 +0530
Varun Wadekar vwade...@nvidia.com wrote:
That doesn't make the duplicate memset/copy cease to be redundant.
Why not copy the key to where it goes, then memset the rest of the data;
wouldn't that be as simple as:
memcpy(dd-ivkey_base, ctx-key,
it's not - it saves writes.
Are you ok with this solution? Either way I wan to start with a clear
key table before programming the hardware.
why do you need to clear the entire key table if it will be
overwritten anyway?
If you set a 128-bit key and then set a 128-bit key, the remaining
On Wed, 16 Nov 2011 14:35:00 +0530
Varun Wadekar vwade...@nvidia.com wrote:
it's not - it saves writes.
Are you ok with this solution? Either way I wan to start with a clear
key table before programming the hardware.
the hardware doesn't care.
why do you need to clear the entire key
why do you need to clear the entire key table if it will be
overwritten anyway?
If you set a 128-bit key and then set a 128-bit key, the remaining
bits still remain in the key table. Similarly, if we use updated IV in
one operation and want to use the initial IV for the next, the updated
From: Lee Nipper lee.nip...@gmail.com
Add these hmac algorithms to talitos:
hmac(md5),
hmac(sha1),
hmac(sha224),
hmac(sha256),
hmac(sha384),
hmac(sha512).
These are all type ahash.
Signed-off-by: Lee Nipper lee.nip...@gmail.com
Fixed up to not register HMAC algorithms on
talitos prints every algorithm it registers at module load time.
Algorithms are being added that make for an excessively noisy console
(latest HMACs patch makes an SEC 3.1 print 20 lines).
Instead, display the SEC h/w version number, and inform the
user of algorithm registration status in
Add a reg member to the channel struct and use it to
access channels.
Signed-off-by: Kim Phillips kim.phill...@freescale.com
---
drivers/crypto/talitos.c | 37 ++---
drivers/crypto/talitos.h | 31 ---
2 files changed, 38
Some later SEC v3.x are equipped with a second IRQ line.
By correctly assigning IRQ affinity, this feature can be
used to increase performance on dual core parts, like the
MPC8572E and P2020E.
The existence of the 2nd IRQ is determined from the device
node's interrupt property. If present, the
specifically, add these algorithm combinations:
authenc-hmac-md5-cbc-aes-caam
authenc-hmac-md5-cbc-des3_ede-caam
authenc-hmac-md5-cbc-des-caam
Signed-off-by: Kim Phillips kim.phill...@freescale.com
---
drivers/crypto/caam/caamalg.c | 57 +
14 matches
Mail list logo
