Hi Oliver, On Sun. 31 Jan 2021 at 21:59, Oliver Hartkopp <socketcan@xxxxxxxxxxxx> wrote: > Hi Vincent, > > On 31.01.21 07:22, Vincent MAILHOL wrote: > > Hello, > > > > The socket CAN API handles the CAN errors (as reported by the > > microcontroller) by emitting some RX CAN frames with the > > CAN_ERR_FLAG set. > > Yes. This is the only intention. > > > My question concerns the transmission path: I would like to > > understand how drivers should handle *TX* CAN frames which have > > the CAN_ERR_FLAG set. > > > > The socket API allows sending such frames. For example doing: > > cansend can0 20000123#0011223344556677 > > will generate such frames and it will reach the xmit() function of > > the driver. > > The reason to pass the frame as-is to the driver layer (including > CAN_ERR_FLAG) is the possibility to test the correct behavior on the RX > path, e.g. when you use the vcan driver. ACK. I was not thinking of the virtual interfaces. This is a valid use case. > On the sending path the CAN_ERR_FLAG has no functionality so far - at > least it was not defined by the community. > > > However, contrary to the other flags (EFF, RTR, FDF, BRS), the > > ERR flag is not present on the data link layer. Instead, the data > > link layer is responsible for detecting errors and signaling those > > as soon as they occur (thus interrupting the transmission). > > > > While the ISO standard does not explicitly forbid having upper > > layers generating such frames, it is not documented. Also, I am > > not aware of CAN controllers allowing to generate error frames on > > demand. > > There are specialized CAN testers, e.g. IIRC Vector CANstress that can > generate error frames on specific conditions (e.g. when detecting a > specific CAN ID). Thanks for the references! > But I heave not seen CAN controllers that provide such functionality. > > > My initial expectation is that those error frames only make > > sense in the RX path and that we should drop such TX frames in, > > for example, can_dropped_invalid_skb(). > > No. As written above the bit is defined to be valid in the RX path only > and it makes sense for testing. ACK. My follow-up question would be: how should the driver handle such frames? Drop them or ignore them? >From what you just explained, I now think that ignoring it is the best solution (e.g. mask the CAN ID with either CAN_EFF_MASK or CAN_SFF_MASK and send it as a normal frame). Does that make sense? > > However, after looking at the code of other drivers, it appears > > that one (and only one) of them: the Kvaser hydra, does actually > > check this CAN_ERR_FLAG flag in the TX path: > > https://elixir.bootlin.com/linux/v5.11-rc5/source/drivers/net/can/usb/kvaser_usb/kvaser_usb_hydra.c#L1421 > > > > I would be thankful if anyone knowledgeable about the Kvaser hydra > > could explain to me how the device handles those error frames. > > o_O - Yes, would be interested too!! > > > Also, please comment if you are aware of any use cases for TX > > error frames. > > Done. And thanks for that! > Best regards, > Oliver
