On 02.02.21 11:00, Vincent MAILHOL wrote:

quoted

quoted

If CAN_CTRLMODE_TX_ERR has been added to the kernel and
can_dropped_invalid_skb() is updated, then a CAN frame with CAN_ERR_FLAG set
would be either send as an error frame or dropped by can_dropped_invalid_skb().

So it would be echoed only if the driver supports CAN_CTRLMODE_TX_ERR and it's
enabled.

ACK.

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.

In fact I would suggest to think a about a proper API (aka CAN frame 
content definition) for outgoing CAN frames with the CAN_ERR_FLAG set.

The CAN_ERR_FLAG has been renamed in the documentation to indicate 
"error messages" from the CAN controller, as an error frame is something 
completely different.

Now as we are talking about having CAN_ERR_FLAG in the TX path besides 
the vcan testing stuff, we should think about an API for the really 
outgoing frames.

We could not only think about "create an error frame right now" but also 
think about a more intelligent CAN node, which also offers to destroy 
one or more specific CAN ID(s) at a specific bit position after 
detecting that CAN ID.

We could use the CAN_RTR_FLAG and the data[] section of the outgoing 
error CAN frames for such an API.

Regards,
Oliver