@Marc, all,
are you fine with that patch and the naming too?
If so, I would go further and provide a patch with the complete netlink
code in can-dev - and maybe a first driver adaption to support len8_dlc
for Classical CAN.
Best regards,
Oliver
On 24.10.20 15:00, Oliver Hartkopp wrote:
On 24.10.20 14:00, Vincent MAILHOL wrote:
I did some tests:
* Applied the patch
* Modified my driver
* Modified drivers/net/can/dev.c:can_changelink() to force the
CAN_CTRLMODE_CC_LEN8_DLC on (this is just me being lazy to do it
from userland).
Good choice for a test. Modifying the ip tool is not that tricky - but
you need to clone that stuff, etc.
* Modified cansend and candump from can-utils to be able to
respectively send and print DLCs greater than 8.
Yes, there will be even more effort on can-utils as it also has an
impact on logfile formats, etc.
E.g. the value between [] in candump was 'len' so far - we could probaly
make them () when we might show the DLC values.
And the logfile format gets the length implicit from the number of
printed data bytes, which is always the 'len'.
So we would need to discuss, where we would need command line options to
enable the CC len8_dlc feature.
* Set up two channels can0 and can1 and connected those to the same
bus.
* Ran 'cangen can0' and 'candump any' simultaneously.
Results of candump:
can0 539 [8] 05 21 8C 5C F7 B0 7C 69
can1 539 [8] 05 21 8C 5C F7 B0 7C 69
can0 47E [1] 53
can1 47E [1] 53
can0 317 [6] E5 00 B5 73 66 CF
can1 317 [6] E5 00 B5 73 66 CF
can0 524 [E] 64 C3 B0 6E 55 7A D7 2E
can1 524 [E] 64 C3 B0 6E 55 7A D7 2E
can0 39C [D] 63 18 96 69 F6 7A AB 36
can1 39C [D] 63 18 96 69 F6 7A AB 36
can0 60D [F] F2 C6 B6 1D 80 FB BC 7E
can1 60D [F] F2 C6 B6 1D 80 FB BC 7E
can0 5DD [9] 7E 55 56 5B C0 23 B0 53
can1 5DD [9] 7E 55 56 5B C0 23 B0 53
can0 573 [E] 20 8E A3 31 1B 54 B2 16
can1 573 [E] 20 8E A3 31 1B 54 B2 16
can0 470 [3] 31 9C 06
can1 470 [3] 31 9C 06
can0 465 [4] 93 75 A2 08
can1 465 [4] 93 75 A2 08
Works fine :-)
Excellent job!!
Thanks Vincent!
Best,
Oliver
