Another endianness question: I have some data structure that can be either little or big endian, depending on the exact use case. Currently, I have it defined as u32. This causes sparse errors when accessing it using cpu_to_Xe32() and Xe32_to_cpu(). Now, for the big endian case, I could use htonl()/ntohl() instead, but this is inconsistent with all other endian conversions in the driver ... and there's no little endian alternative I'm aware of. So I don't really like that approach. Alternatively, I could define a union of both a big and little endian version of the data but that would require touching a lot of legacy code (unless I use a C11 anonymous union ... not sure if that would be allowed?) and IMHO is a bit silly. Is there some way of telling sparse to _not_ check for "correct" use of these functions for a certain variable? Regards, Pascal van Leeuwen Silicon IP Architect, Multi-Protocol Engines @ Verimatrix www.insidesecure.com > -----Original Message----- > From: Pascal Van Leeuwen > Sent: Monday, October 21, 2019 11:04 AM > To: linux-crypto@xxxxxxxxxxxxxxx; herbert@xxxxxxxxxxxxxxxxxxx > Subject: Key endianness? > > 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
