crypto/aes: add unsigned to ints that can't go

* Key length can't go negative, "unsigned int" is preferred to "int"
* E-Key is most frequently accessed struct member

---
 aes.c |    4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

@@ -77,9 +77,9 @@ byte(const u32 x, const unsigned n)
 #define u32_out(to, from) (*(u32 *)(to) = cpu_to_le32(from))
 
 struct aes_ctx {
-	int key_length;
 	u32 E[60];
 	u32 D[60];
+	unsigned int key_length;
 };
 
 #define E_KEY ctx->E

@@ -378,7 +378,7 @@ static void aes_decrypt(void *ctx_arg, u
 {
 	const struct aes_ctx *ctx = ctx_arg;
 	u32 b0[4], b1[4];
-	const int key_len = ctx->key_length;
+	const unsigned int key_len = ctx->key_length;
 	const u32 *kp = D_KEY + key_len + 20;
 
 	b0[0] = u32_in (in) ^ E_KEY[key_len + 24];

_______________________________________________
Kernel-janitors mailing list
[email protected]
https://lists.osdl.org/mailman/listinfo/kernel-janitors

I've checked alpha and s390 (defconfigs):

* just rearranging doesn't change anything wrt size(1)
* just adding "unsigned" increases size of aes.o. In alpha case by 0x30 bytes.

* Alexey Dobriyan <[email protected]>:

At my place (ppc32) it does:

15069 crypto/aes.orig.ko
14973 crypto/aes.ko

14224 crypto/aes.orig.o
14152 crypto/aes.o

However, I guess the explanation was not quite right: having had a look at the asm output, it looks to me like it's the D-Key who actually benefits from a smaller offset.

That means Jeff Garzik is wrong, and the janitor's TODO list needs to be changed? ;)
(Quote: "unsigned int" is preferred to "int", it generates better asm code on all platforms except sh5.)

Cheers,
n.

_______________________________________________
Kernel-janitors mailing list
[email protected]
https://lists.osdl.org/mailman/listinfo/kernel-janitors