On 15.12.20 16:05, Marc Kleine-Budde wrote:
On 12/15/20 3:51 PM, Oliver Hartkopp wrote:+static const u8 len2dll_len[] = { + 0, 1, 2, 3, 4, 5, 6, 7, 8, /* 0 - 8 */ + 12, 12, 12, 12, /* 9 - 12 */ + 16, 16, 16, 16, /* 13 - 16 */ + 20, 20, 20, 20, /* 17 - 20 */ + 24, 24, 24, 24, /* 21 - 24 */ + 32, 32, 32, 32, 32, 32, 32, 32, /* 25 - 32 */ + 40, 40, 40, 40, 40, 40, 40, 40, /* 33 - 40 */ + 48, 48, 48, 48, 48, 48, 48, 48 /* 41 - 48 */ +};I totally misunderstood what you wanted to do in my previous email. I thought that the numbers were placeholders and that the final goal was to take into account the CRC as you previously mentioned in your first email.Sorry, should have been clearer about functionality of that table/function.This function is just here to sanitize the data length, right? Then we could simply name it can_fd_sanitize_len().sanitized_len sounds good.Yes and once you are a it: Won't it make more sense to use return can_fd_dlc2len(can_fd_len2dlc(len));I'm using that construct in the mcp251xfd driver, too. Will remove the table....
I'm not really sure whether it's more efficient to have multiple tables or more code and testing ...
instead of creating a new table telling the same as the existing static const u8 len2dlc[] table?Can we get rid of the pad table in ISOTP aswell? :)
Ah, that one is a bit different (see the first line). Nice try :-D Oliver
