Hi Sebastian,
>># modprobe alchemy-aes
>>alg: skcipher: setkey failed on test 2 for ecb-aes-alchemy: flags=200000
>># modprobe tcrypt mode=10
>>alg: skcipher: setkey failed on test 3 for cbc-aes-alchemy: flags=0
>>alg: skcipher: Failed to load transform for cbc(aes): -2
>>alg: skcipher: Failed to load transform for cbc(aes): -2
>>tcrypt: one or more tests failed!
>>FATAL: Error inserting tcrypt
>>(/lib/modules/2.6.34-rc6-db1200-00214-g9f84af9/kernel/crypto/tcrypt.ko):
>>Unknown symbol in module, or unknown parameter (see dmesg)
>
>>The error in "test 3 for cbc-aes-alchemy" probably comes from the inability
>>to process keys larger than 128 bits.
> You have to fix this, you have to be able to handle other keys as well.
> In case your hardware does not support it, you have to handle this in
> software. Look at the geode driver, via or s390. All of them have
> fallbacks for. If you fail the self test, you driver will no be used
> afaik.
Ah, I wondered what those were used for. I'll fix the driver to use them
as well. Interestingly the algos provided are marked as tested in
/proc/crypto though. I assumed the cryptoapi knows that the hw algo
can't handle these keylengths (it didn't even call the setkeys callback
before throwing the error) and fall back on software aes instead.
>>diff --git a/drivers/crypto/alchemy-aes.c b/drivers/crypto/alchemy-aes.c
>>new file mode 100644
>>index 0000000..14e8ace
>>--- /dev/null
>>+++ b/drivers/crypto/alchemy-aes.c
>>+static int __init alchemy_aes_load(void)
>>+{
>>+ /* FIXME: hier sollte auch noch der PRId des prozessors getestet
>>+ * werden; Au1210 (0x0503xxxx) und einige Au1300 haben lt. Daten-
>>+ * blatt keine AES engine.
>>+ */
> You German right? You should handle this in SoC code. So if you figure
> out, that you have an engine here you add the device. If you don't have
> it you don't do it and the probe call won't be called. Also the module
> won't be loaded by udev.
Hm, I'll think about it.
>>+ /* need to do 8bit accesses to memory to get correct data */
>>+ __alchemy_aes_memid = au1xxx_ddma_add_device(&alchemy_aes_mem_dbdev);
>>+ if (!__alchemy_aes_memid)
>>+ return -ENODEV;
> What does it do? You don't want to add devices here. If you need
> something additional do it in SoC code and pass it via platform_data.
The dbdma code needs templates to get the memory access width right,
this adds a template for use with the AES engine. Every instance could
use the same template that's why it's registered in the module_init callback.
(see drivers/mmc/au1xmmc.c for instance; yes this is a workaround for
a shortcoming of the alchemy dbdma framework).
Thanks!
Manuel Lauss
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
