On 2/2/21 9:23 AM, Kurt Van Dijck 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. ACK The user space use case would be: - fd = socket() - bind(fd, "can0") - setsockopt(fd, SOCKOPT_TX_ERR) The raw_setsockopt() in the kernel can check the CAN devices supported ctrl modes. > So I'd think we start with adding the CAN_CTRLMODE_TX_ERR to the driver > level. ACK > It would allow to see if a driver will behave properly with CAN_ERR_FLAG > can_frames in the tx path. ACK >>> 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. Makes sense. The implementation steps could be: - convert can_dropped_invalid_skb() from static inline to regular function - add check for CAN_ERR_FLAG and enabled CAN_CTRLMODE_TX_ERR to can_dropped_invalid_skb() > I think it's wrong that CAN_ERR_FLAG messages would appear as regular > frame on CAN, as happens today if I understood well. ACK 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
