It seems that the driver uses something like crypto_.*_ctx_aligned() of his own.
Replace it with the API's functions. Compile tested.
Signed-off-by: Sebastian Siewior <[email protected]>
--- a/drivers/crypto/padlock-aes.c
+++ b/drivers/crypto/padlock-aes.c
@@ -297,30 +297,10 @@ aes_hw_extkey_available(uint8_t key_len)
return 0;
}
-static inline struct aes_ctx *aes_ctx_common(void *ctx)
-{
- unsigned long addr = (unsigned long)ctx;
- unsigned long align = PADLOCK_ALIGNMENT;
-
- if (align <= crypto_tfm_ctx_alignment())
- align = 1;
- return (struct aes_ctx *)ALIGN(addr, align);
-}
-
-static inline struct aes_ctx *aes_ctx(struct crypto_tfm *tfm)
-{
- return aes_ctx_common(crypto_tfm_ctx(tfm));
-}
-
-static inline struct aes_ctx *blk_aes_ctx(struct crypto_blkcipher *tfm)
-{
- return aes_ctx_common(crypto_blkcipher_ctx(tfm));
-}
-
static int aes_set_key(struct crypto_tfm *tfm, const u8 *in_key,
unsigned int key_len)
{
- struct aes_ctx *ctx = aes_ctx(tfm);
+ struct aes_ctx *ctx = crypto_tfm_ctx_aligned(tfm);
const __le32 *key = (const __le32 *)in_key;
u32 *flags = &tfm->crt_flags;
uint32_t i, t, u, v, w;
@@ -442,13 +422,13 @@ static inline u8 *padlock_xcrypt_cbc(con
static void aes_encrypt(struct crypto_tfm *tfm, u8 *out, const u8 *in)
{
- struct aes_ctx *ctx = aes_ctx(tfm);
+ struct aes_ctx *ctx = crypto_tfm_ctx_aligned(tfm);
padlock_xcrypt_ecb(in, out, ctx->E, &ctx->cword.encrypt, 1);
}
static void aes_decrypt(struct crypto_tfm *tfm, u8 *out, const u8 *in)
{
- struct aes_ctx *ctx = aes_ctx(tfm);
+ struct aes_ctx *ctx = crypto_tfm_ctx_aligned(tfm);
padlock_xcrypt_ecb(in, out, ctx->D, &ctx->cword.decrypt, 1);
}
@@ -477,7 +457,7 @@ static int ecb_aes_encrypt(struct blkcip
struct scatterlist *dst, struct scatterlist *src,
unsigned int nbytes)
{
- struct aes_ctx *ctx = blk_aes_ctx(desc->tfm);
+ struct aes_ctx *ctx = crypto_blkcipher_ctx_aligned(desc->tfm);
struct blkcipher_walk walk;
int err;
@@ -499,7 +479,7 @@ static int ecb_aes_decrypt(struct blkcip
struct scatterlist *dst, struct scatterlist *src,
unsigned int nbytes)
{
- struct aes_ctx *ctx = blk_aes_ctx(desc->tfm);
+ struct aes_ctx *ctx = crypto_blkcipher_ctx_aligned(desc->tfm);
struct blkcipher_walk walk;
int err;
@@ -543,7 +523,7 @@ static int cbc_aes_encrypt(struct blkcip
struct scatterlist *dst, struct scatterlist *src,
unsigned int nbytes)
{
- struct aes_ctx *ctx = blk_aes_ctx(desc->tfm);
+ struct aes_ctx *ctx = crypto_blkcipher_ctx_aligned(desc->tfm);
struct blkcipher_walk walk;
int err;
@@ -567,7 +547,7 @@ static int cbc_aes_decrypt(struct blkcip
struct scatterlist *dst, struct scatterlist *src,
unsigned int nbytes)
{
- struct aes_ctx *ctx = blk_aes_ctx(desc->tfm);
+ struct aes_ctx *ctx = crypto_blkcipher_ctx_aligned(desc->tfm);
struct blkcipher_walk walk;
int err;
On Thu, Aug 02, 2007 at 10:10:09AM +0200, Sebastian Siewior wrote:
> It seems that the driver uses something like crypto_.*_ctx_aligned() of his own.
> Replace it with the API's functions. Compile tested.
>
> Signed-off-by: Sebastian Siewior <[email protected]>
Actually this is intentional as it allows the align
operation to be completely optimised out.
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <[email protected]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
* Herbert Xu | 2007-08-02 16:58:16 [+0800]:
>On Thu, Aug 02, 2007 at 10:10:09AM +0200, Sebastian Siewior wrote:
>> It seems that the driver uses something like crypto_.*_ctx_aligned() of his own.
>> Replace it with the API's functions. Compile tested.
>>
>> Signed-off-by: Sebastian Siewior <[email protected]>
>
>Actually this is intentional as it allows the align
>operation to be completely optimised out.
The only difference I can see is, that crypto_tfm_alg_alignmask() is
replaced with a static defined number instead of a lookup in a struct.
IS this the optimization?
Sebastian
On Thu, Aug 02, 2007 at 11:23:51AM +0200, Sebastian Siewior wrote:
>
> The only difference I can see is, that crypto_tfm_alg_alignmask() is
> replaced with a static defined number instead of a lookup in a struct.
> IS this the optimization?
Yes, the fact that the alignment mask is a constant allows
it to be optimised away.
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <[email protected]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
* Herbert Xu | 2007-08-02 17:28:25 [+0800]:
>On Thu, Aug 02, 2007 at 11:23:51AM +0200, Sebastian Siewior wrote:
>>
>> The only difference I can see is, that crypto_tfm_alg_alignmask() is
>> replaced with a static defined number instead of a lookup in a struct.
>> IS this the optimization?
>
>Yes, the fact that the alignment mask is a constant allows
>it to be optimised away.
If this is that important, isn't it better to add/ replace the current
_aligned call with such an optimized one? Or applies this kind of
optimization only to this special driver where it is very expensive
otherwise?
>Cheers,
Sebastian
On Thu, Aug 02, 2007 at 03:09:33PM +0200, Sebastian Siewior wrote:
>
> If this is that important, isn't it better to add/ replace the current
> _aligned call with such an optimized one? Or applies this kind of
> optimization only to this special driver where it is very expensive
> otherwise?
In this particular case we have a CPU that's relatively
poor at branching but very fast at doing AES so yes it
is special.
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <[email protected]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt