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. > 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). > > 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). > > What do you think of the above? Sounds good. Marc -- Pengutronix e.K. | Marc Kleine-Budde | Embedded Linux | https://www.pengutronix.de | Vertretung West/Dortmund | Phone: +49-231-2826-924 | Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
Attachment:
signature.asc
Description: OpenPGP digital signature
