Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Auto merge of #3357 - de-vri-es:can-frame-len8-dlc, r=JohnTitor
Expose `len8_dlc` field of `can_frame` struct. The `can_frame` struct on Linux has a `len8_dlc` field which can be used to stuff a few extra bits in the `dlc` field of the actual CAN frame on the wire (only allowed when the data length itself is 8, and if the hardware CAN controller allows it). However, that field is not currently exposed. This PR exposes it as `pub len8_dlc: u8` so we can get those extra 2.8 bits from our CAN frames 😅 It would have been nice to name the current `can_dlc` field as `len`, instead of the old deprecated name, but I guess that ship has sailed. Upstream documentation: https://www.kernel.org/doc/html/latest/networking/can.html#how-to-use-socketcan > ```c > struct can_frame { > canid_t can_id; /* 32 bit CAN_ID + EFF/RTR/ERR flags */ > union { > /* CAN frame payload length in byte (0 .. CAN_MAX_DLEN) > * was previously named can_dlc so we need to carry that > * name for legacy support > */ > __u8 len; > __u8 can_dlc; /* deprecated */ > }; > __u8 __pad; /* padding */ > __u8 __res0; /* reserved / padding */ > __u8 len8_dlc; /* optional DLC for 8 byte payload length (9 .. 15) */ > __u8 data[8] __attribute__((aligned(8))); > }; > ``` > > Remark: The len element contains the payload length in bytes and should be used instead of can_dlc. The deprecated can_dlc was misleadingly named as it always contained the plain payload length in bytes and not the so called 'data length code' (DLC). > > To pass the raw DLC from/to a Classical CAN network device the len8_dlc element can contain values 9 .. 15 when the len element is 8 (the real payload length for all DLC values greater or equal to 8).
- Loading branch information