Correct bitfield bits position and manage bus endianness #15
Conversation
While bitfield should follow exactly datasheet's information, endianness must be handled for bus transport which is always little. This fix converts endianness to/from bus for data to be handled by arch endianness (big or little). Signed-off-by: Yannick Lanz <yannick.lanz@wifx.net>
|
This is an interesting alternate approach.. I, see it does make it quite a bit harder to match the bitfields to the microchip documentation |
|
Small note before moving too far, I tested it on little endian arch and ran only key, info, test and bench commands. I still need to test provision on unprogrammed atecc. |
I don't understand, my patch uses exactly the same bitfield definitions than the datasheet |
You're right in that they are the same definition, but the bit indices used in the documentation line up with what is in the code today.. vs reading them inverted to match a big endian definition? |
|
This how bitfield should be managed, they are always represented as "endian free" in datasheet then bus endianess must be managed. This is, at least from what I know, how it is managed over the whole Linux kernel for exemple (look at ntoh and hton function) |
Oh I agree.. my point is that the microchip ecc documentation talks about bits 0-3 being the auth_key in KeyConfig and your change makes it bits 8-11. Which makes it harder to follow |
|
It's like we don't have the same data sheet, I wrote you an email to talk more about its content, I don't know if you received it. |
| @@ -27,6 +27,8 @@ impl From<KeyConfigType> for u8 { | |||
| } | |||
| } | |||
|
|
|||
| // Should probably be removed as it should manage bus endianness while | |||
There was a problem hiding this comment.
how is this managing bus endianness? Need to be able to construct a Key/SlotConfig from bytes right?
While bitfield should follow exactly datasheet's information, endianness must be handled for bus transport which is always little.
This fix converts endianness to/from bus for data to be handled by arch endianness (big or little).
This pull request aims to replace #13 in a more cleaner way.