History log of /drivers/s390/crypto/zcrypt_api.h
Revision Date Author Comments
25985edcedea6396277003854657b5f3cb31a628 31-Mar-2011 Lucas De Marchi <lucas.demarchi@profusion.mobi> Fix common misspellings

Fixes generated by 'codespell' and manually reviewed.

Signed-off-by: Lucas De Marchi <lucas.demarchi@profusion.mobi>
c2567f8ffa2704f6f2f81013e9a590deca5a865f 05-Jan-2011 Felix Beck <felix.beck@de.ibm.com> [S390] zcrypt: cope with cca restriction of cex3

The cca on the crypto adapter has a restriction in the size of the
exponent if a key with a modulus bigger than 2048 bit is used. Thus
in that case we have to avoid that the crypto device driver thinks
the adapter is defect and sets it offline. Therfore a new member for
the zcrypt_device struct called max_exp_bit_length is introduced. This
will be set the first time the cca returns the error code function
not implemented. If this is done with an adapter twice it will return
-EINVAL.

Signed-off-by: Felix Beck <felix.beck@de.ibm.com>
Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
8e89b6be76927751af5608490158100974b339e6 07-Dec-2009 Felix Beck <felix.beck@de.ibm.com> [S390] zcrypt: use definitions for cex3

New definitions are added for CEX3 device types. They will be set
in the according probe functions. CEX3 device types will be handled
in the same modules as CEX2 device types. In the first step they are
the same as CEX2 types, but they can be adjusted for further
characteristics of CEX3 easily.

Signed-off-by: Felix Beck <felix.beck@de.ibm.com>
Signed-off-by: Ralph Wuerthner <ralph.wuerthner@de.ibm.com>
Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
1a89dd8f0b4d7eca2dd4abffb736f37676e1b073 14-Jul-2008 Felix Beck <felix.beck@de.ibm.com> [S390] Cleanup zcrypt printk messages.

Signed-off-by: Felix Beck <felix.beck@de.ibm.com>
Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
Signed-off-by: Heiko Carstens <heiko.carstens@de.ibm.com>
2a2cf6b18626e66b7898013dfa4df8fe2feca568 17-Apr-2008 Harvey Harrison <harvey.harrison@gmail.com> [S390] replace remaining __FUNCTION__ occurrences

__FUNCTION__ is gcc-specific, use __func__

Signed-off-by: Harvey Harrison <harvey.harrison@gmail.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
Signed-off-by: Heiko Carstens <heiko.carstens@de.ibm.com>
2f7c8bd6dc6540aa3275c0ad9f657401985c00e9 17-Apr-2008 Ralph Wuerthner <rwuerthn@de.ibm.com> [S390] zcrypt: add support for large random numbers

This patch allows user space applications to access large amounts of
truly random data. The random data source is the build-in hardware
random number generator on the CEX2C cards.

Signed-off-by: Ralph Wuerthner <rwuerthn@de.ibm.com>
Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
Signed-off-by: Heiko Carstens <heiko.carstens@de.ibm.com>
5432114baf0300286a6ca1b0aea549492a379432 20-Sep-2006 Ralph Wuerthner <rwuerthn@de.ibm.com> [S390] zcrypt secure key cryptography extension.

Allow the user space to send extended cprb messages directly to the
PCIXCC / CEX2C cards. This allows the CCA library to construct special
crypto requests that use "secure" keys that are stored on the card.

Signed-off-by: Ralph Wuerthner <rwuerthn@de.ibm.com>
Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
2dbc2418bac32a18a372ae9aec386f0fe9174389 20-Sep-2006 Martin Schwidefsky <schwidefsky@de.ibm.com> [S390] zcrypt user space interface.

The user space interface of the zcrypt device driver implements the old
user space interface as defined by the old z90crypt driver. Everything
is there, the /dev/z90crypt misc character device, all the lovely ioctls
and the /proc file. Even writing to the z90crypt proc file to configure
the crypto device still works. It stands to reason to remove the proc
write function someday since a much cleaner configuration via the sysfs
is now available.

The ap bus device drivers register crypto cards to the zcrypt user
space interface. The request router of the user space interface
picks one of the registered cards based on the predicted latency
for the request and calls the driver via a callback found in the
zcrypt_ops of the device. The request router only knows which
operations the card can do and the minimum / maximum number of bits
a request can have.

Signed-off-by: Cornelia Huck <cornelia.huck@de.ibm.com>
Signed-off-by: Ralph Wuerthner <rwuerthn@de.ibm.com>
Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>