; Stephen Warren; Varun Wadekar
Subject: [PATCH] crypto: tegra: remove driver
From: Stephen Warren
This driver has never been hooked up in any board file, and cannot be
instantiated via device tree. I've been told that, at least on Tegra20, the HW
is slower at crypto than the main CPU. I ha
Looks good. Please add my ACK.
Thanks.
-Original Message-
From: Jingoo Han [mailto:jg1@samsung.com]
Sent: Wednesday, February 12, 2014 9:57 AM
To: 'Herbert Xu'
Cc: 'David Miller'; linux-crypto@vger.kernel.org; 'Jingoo Han'; 'Stephen
Warren';
On Friday 13 January 2012 11:05 AM, Herbert Xu wrote:
On Fri, Dec 16, 2011 at 11:25:53AM +, Varun Wadekar wrote:
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.
Both patches
Add Herbert and David
On Friday 16 December 2011 04:55 PM, Varun Wadekar wrote:
driver supports ecb/cbc/ofb/ansi_x9.31rng modes,
128, 192 and 256-bit key sizes
Signed-off-by: Varun Wadekar
---
drivers/crypto/Kconfig | 11 +
drivers/crypto/Makefile|1 +
drivers/crypto/tegra
Add Herbert and David
On Friday 16 December 2011 04:55 PM, Varun Wadekar wrote:
From: Henning Heinold
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.
Acked-by: Olof Johansson
Signed-off
ay 16 December 2011 04:55 PM, Varun Wadekar wrote:
driver supports ecb/cbc/ofb/ansi_x9.31rng modes,
128, 192 and 256-bit key sizes
Signed-off-by: Varun Wadekar
---
drivers/crypto/Kconfig | 11 +
drivers/crypto/Makefile|1 +
drivers/crypto/tegra-aes.c |
driver supports ecb/cbc/ofb/ansi_x9.31rng modes,
128, 192 and 256-bit key sizes
Signed-off-by: Varun Wadekar
---
drivers/crypto/Kconfig | 11 +
drivers/crypto/Makefile|1 +
drivers/crypto/tegra-aes.c | 1096
drivers/crypto/tegra-aes.h
From: Henning Heinold
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.
Acked-by: Olof Johansson
Signed-off-by: Henning Heinold
Signed-off-by: Varun Wadekar
---
arch/arm/mach-tegra
---
Fixed the compilation issues that Henning reported. The driver now
builds as a module. Use devm_* apis. Fixed other comments from StephenW
and KimP.
Henning Heinold (1):
arm: tegra: export tegra_chip_uid
Varun Wadekar (1):
crypto: driver for Tegra AES hardware
arch/arm/mach-tegra
driver supports ecb/cbc/ofb/ansi_x9.31rng modes,
128, 192 and 256-bit key sizes
Signed-off-by: Varun Wadekar
---
drivers/crypto/Kconfig | 11 +
drivers/crypto/Makefile|1 +
drivers/crypto/tegra-aes.c | 1102
drivers/crypto/tegra-aes.h
From: Henning Heinold
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.
Signed-off-by: Henning Heinold
Signed-off-by: Varun Wadekar
---
arch/arm/mach-tegra/fuse.c |2 ++
1 files
reported. The driver now
builds as a module. Use devm_* apis. Fixed other comments from StephenW
and KimP.
Henning Heinold (1):
arm: tegra: export tegra_chip_uid
Varun Wadekar (1):
crypto: driver for Tegra AES hardware
arch/arm/mach-tegra/fuse.c |2 +
drivers/crypto/Kconfig | 11
>> you're losing free performance.
> I am really not comfortable having garbage in the keytable.
Kim, do you have any other solution in mind?
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.kernel.org
More majordomo info at h
>>> 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, th
> 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
driver supports ecb/cbc/ofb/ansi_x9.31rng modes,
128, 192 and 256-bit key sizes
Signed-off-by: Varun Wadekar
---
drivers/crypto/Kconfig | 11 +
drivers/crypto/Makefile|1 +
drivers/crypto/tegra-aes.c | 1102
drivers/crypto/tegra-aes.h
From: Henning Heinold
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.
Signed-off-by: Henning Heinold
Signed-off-by: Varun Wadekar
---
arch/arm/mach-tegra/fuse.c |2 ++
1 files
pilation issues that Henning reported. The driver now
builds as a module. Use devm_* apis. Fixed other comments from StephenW
and KimP.
Henning Heinold (1):
arm: tegra: export tegra_chip_uid
Varun Wadekar (1):
crypto: driver for Tegra AES hardware
arch/arm/mach-tegra/fuse.c |2 +
drivers
driver supports ecb/cbc/ofb/ansi_x9.31rng modes,
128, 192 and 256-bit key sizes
Change-Id: I3f923576ac80894cdd35b2db8e214e7d18e19c21
Signed-off-by: Varun Wadekar
---
drivers/crypto/Kconfig | 11 +
drivers/crypto/Makefile|1 +
drivers/crypto/tegra-aes.c | 1102
From: Henning Heinold
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
Signed-off-by: Varun Wadekar
rytpo driver patch sending the tegra_chip_uid as well.
Henning Heinold (1):
arm: tegra: export tegra_chip_uid
Varun Wadekar (1):
crypto: driver for Tegra AES hardware
arch/arm/mach-tegra/fuse.c |2 +
drivers/crypto/Kconfig | 11 +
drivers/crypto/Makefile|1 +
dri
> 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, ctx->keylen);
> memset(dd->ivkey_base + ctx->keylen, 0, AES_HW_KEY_TABLE_LENGTH_BY
Driver supports ecb/cbc/ofb/ansi_x9.31rng modes,
128, 192 and 256-bit key sizes
Signed-off-by: Varun Wadekar
---
v4: Depends on "[PATCH v1] arm: tegra: export tegra_chip_uid"
in order to build tegra-aes as a module
drivers/crypto/Kconfig | 11 +
drivers/crypto/Makefile
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.
Original author: Henning Heinold
Signed-off-by: Henning Heinold
Signed-off-by: Varun Wadekar
---
arch/arm/mach-tegra/fuse.c |2 ++
1
>> Why?
> To avoid redundant work; there's little point memset()ing a region that's
> going to be copied over the top of immediately afterwards.
>
The length used for memset is different from the length being copied
over. I am initially memsetting the entire key struct (which contains
the key + o
>> +/* assign new context to device */
>> +ctx->dd = dd;
>> +dd->ctx = ctx;
>> +
>> +if (ctx->flags & FLAGS_NEW_KEY) {
>> +/* copy the key */
>> +memset(dd->ivkey_base, 0, AES_HW_KEY_TABLE_LENGTH_BYTES);
>> +memcpy(dd->ivkey_base, ctx->key, ctx->
>>> + /* Initialize the vde clock */
>>> + dd->aes_clk = clk_get(dev, "vde");
>> That clock doesn't exist in the mainline kernel; "bsev" exists for device
>> "tegra-aes"...
>>
> We need to use the "vde" clock. I will submit a patch to add the "vde"
> clock. "bsev" might not be needed at the mo
>> +cmdq[1] = (u32)dd->ivkey_phys_base;
>> +
>> +for (i = 0; i < ARRAY_SIZE(cmdq); i++)
>> +aes_writel(dd, cmdq[i], ICMDQUE_WR);
> ARRAY_SIZE is 2 here - why not use a single temporary variable and
> two individual aes_writel()s?
Removed 'i' and kept cmdq as it is. Adding 2 mo
>> +res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> Don't you need to call request_mem_region() between get_resource() and
> ioremap()?
I am remapping the module register space. Used IORESOURCE_IO instead.
>
>
>> +/* Initialize the vde clock */
>> +dd->aes_clk = clk_get(dev, "
On Friday 04 November 2011 07:24 PM, Henning Heinold wrote:
> Hi Varun,
>
> thanks that you come up with an "official" patch for the aes-stuff.
>
> Against which tree you did test the patch?
I tested it against Linus's master branch but unfortunately, some other
changes crept inside this patch due
30 matches
Mail list logo
