VCAN and CAN-FD DLC versus data length

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi all.

I just ran into some curious behaviour with the vcan driver in regards to CAN-FD and the DLC.

If I send a CAN-FD frame with a length, which is not directly representable by the DLC field, the vcan driver conserves this value. E.g. a Length of 11 is sent and received in userspace, even though there is no DLC representation for 11.

I talked to a colleague about this and we could not think of a case, in which this behaviour presents a problem. It is just a small discrepancy from how a real CAN would behave.

cansend from the can-utils package actually makes sure not to use a data length, which is not directly representable. This is the output of a candump oagainst a patched version, which does not "fix" the length.

$ candump any & ./patched-cansend vcan0 123##011223344556677889900AA
  vcan0  123  [11]  11 22 33 44 55 66 77 88 99 00 AA

Does anyone have a real case, which would warrant a patch to the vcan driver to change this? Or should the CAN stack even return EINVAL on a data length, that is not representable?

Regards
  Andre



[Index of Archives]     [Automotive Discussions]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux]     [Linux OMAP]     [Linux MIPS]     [eCos]     [Asterisk Internet PBX]     [Linux API]     [CAN Bus]

  Powered by Linux