On Tue, 02 Feb 2021 08:35:14 +0100, Marc Kleine-Budde wrote: > On 2/2/21 1:22 AM, Vincent MAILHOL wrote: > [...] > > >> 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. > > > 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. > > > > 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
