On Tue, 02 Feb 2021 08:35:14 +0100, Marc Kleine-Budde wrote:

On 2/2/21 1:22 AM, Vincent MAILHOL wrote:
[...]

quoted

quoted

Right, it would be nice to sort this out. I prefer to keep the
functionality, since we got customers using it.

Basically, I would see this as an expert function: add a
CAN_CTRLMODE_TX_ERR and have the user explicitly enable the
feature through netlink when configuring the interface. The
rationale is to prevent by default an unprivileged application
from messing with the bus.

The CAN_CTRLMODE_TX_ERR would be a per device option. Another option might be a
sockopt, where you have to enable the TX_ERR explicitly. I'm not sure, which
option is the best here.

a sockopt is only correct if it can detect that the device underneath
has CAN_CTRLMODE_TX_ERR capability.

So I'd think we start with adding the CAN_CTRLMODE_TX_ERR to the driver level.

It would allow to see if a driver will behave properly with CAN_ERR_FLAG
can_frames in the tx path.

quoted

If CAN_CTRLMODE_TX_ERR is on the device generates an error
flag. Else, the CAN_ERR_FLAG is simply ignored (masked out).
The CAN ID, DLC and payload of the TX error frames are
ignored (i.e. reserved for future).

IMO, can_frames in the tx path with CAN_ERR_FLAG should be dropped
if the driver can't handle them. vcan in this regard is capable of
handling those, as does the kvaser usb.

I think it's wrong that CAN_ERR_FLAG messages would appear as regular
frame on CAN, as happens today if I understood well.

quoted

I do not see the need for more complex logic at the moment
because your device is only capable of generating one type of
error flags: the active error. If one day a device has the
ability to generate both the active and passive error flags, we
should then define how to send those (maybe by putting a flag in
the payload, similar to what is done on the RX path).

ack.

Kurt