Hello people, I've been observing that when a CAN controller is in the BUS-OFF state, write syscall returns success, which seems quite confusing to me. So far I've learned this issue is most probably caused by upper (net and can) layers (so this is not specific for certain controller driver). When a driver calls can_bus_off, it sets carrier-off and triggers linkwatch_* actions that deactivate net queues and substitute a struct qdisc with `noop_qdisc`. Upon sending a frame, it's enqueue function - noop_enqueue - just returns NET_XMIT_CN, which is transformed by net_xmit_errno macro to zero, that's passed by net/can/af_can.c:can_send up to a userspace caller of write as success. According to description for qdisc return codes in include/linux/netdevice.h, NET_XMIT_CN stands for `congestion notification` and further /* NET_XMIT_CN is special. It does not guarantee that this packet is lost. It * indicates that the device will soon be dropping packets, or already drops * some packets of the same priority; prompting us to send less aggressively. */ Is this behavior appropriate for a node in BUS-OFF state? I'd rather expect such controller would be always dropping all frames (not just soon and some) until reset. In current situation a caller of write gets success even if his frame is lost for sure. Is there any specific reason for this? Of course he can be notified by receiving error frame, but why don't just return error in can_send? I'm observing this behavior during continuing work on the CTU CAN FD IP Core project (http://canbus.pages.fel.cvut.cz/) and on D_CAN controller integrated on Altera SoC. Though I believe it's not specifically linked to these controllers only. Best regards Jaroslav Beran
