On 2021-02-02 11:00, Vincent MAILHOL wrote:> The echo would be special
here. We have to remember that the
payload of the CAN_ERR_FLAG frames is an arbitrary design. This
payload has no meaning for the data link.
When we echo back the frame, only the DLC, CAN ID and payload of
the TX frame are irrelevant (except for vcan).
My current idea would be to follow what Kvaser did: they send the
frame and the device reports the error flag (c.f. the example
given by Jimmy above). So the echo feature would not be used
for error flags.
@Jimmy, could you confirm my understanding? Do you use the echo
functionality for error flags in the Kvaser driver?
I had to double check how this works.
When we get an skb with a frame where CAN_EFF_FLAG is set,
we will set the corresponding bit for the CAN controller, and
copy the rest of frame content (id, flags and data), and call
can_put_echo_skb(). Same as we do for all other packages.
We will receive a "TX ACK" for this package (from the USB device), and
we call can_get_echo_skb(). However, it looks like the "TX ACK" is
dropped, probably because CAN_EFF_FLAG is set.
We will also receive the generated error frame, and eventually call
netif_rx(skb). It is the same behavior for all the devices connected to
the bus.
The "TX ACK" path in the kvaser_usb driver is wrong, and it happens to
be that the ACK is not passed to the user. We also increment the
tx_packets and tx_bytes (depending on the data in the frame) stats.
I'll fix this once we know what the API should look like.
Regards,
jimmy
