Herbert, I'm currently busy fixing some endianness related sparse errors reported by this kbuild test robot and this triggered my to rethink some endian conversion being done in the inside-secure driver. I actually wonder what the endianness is of the input key data, e.g. the "u8 *key" parameter to the setkey function. I also wonder what the endianness is of the key data in a structure like "crypto_aes_ctx", as filled in by the aes_expandkey function. Since I know my current endianness conversions work on a little endian CPU, I guess the big question is whether the byte order of this key data is _CPU byte order_ or always some _fixed byte order_ (e.g. as per algorithm specification). I know I have some customers using big-endian CPU's, so I do care, but I unfortunately don't have any platform available to test this with. Regards, Pascal van Leeuwen Silicon IP Architect, Multi-Protocol Engines @ Verimatrix www.insidesecure.com