Answering myself ... >>> Our options are: >>> leave as it is, or combinations of these: >>> >>> 1) drop frames with RTR && dlc != 0 >>> 2) set dlc = 0 if RTR is set >>> 3) set data = to 0 if RTR is set >>> >>> a) during RX >>> b) during TX >> >> Thanks for the explanations, now I understand what it's used for. >> >> So far it seems that 3)+a) is a good option. Next question, where to >> implement this? >> I) in each driver, skip copy of data if RTR is set >> (remember, we use alloc_can_skb(), data is preset to 0) > > This would be my favourite and also CPU saving IMO. > > The omit of the copying is just done e.g. in the sja1000 driver: > > http://lxr.linux.no/#linux+v2.6.36/drivers/net/can/sja1000/sja1000.c#L349 > > But in the sja1000 the DLC is not set in the RTR case - and therefore remains > zero. > > The question is, if a DLC != 0 is really worth anything on the RX side. AFAIK > the RTR frames intention is only to request a specific CAN-ID - independent > from any DLC. > > Gerhard, do you have any reference, how a possible DLC values in RTR frames > can be used?
The BOSCH CAN Spec says about RTR frames: There is no DATA FIELD, independent of the values of the DATA LENGTH CODE which may be signed any value within the admissible range 0...8. The value is the DATA LENGTH CODE of the corresponding DATA FRAME. So indeed this needs to by fixed in the sja1000: - always read CAN-identifier _and_ DLC - copy CAN data on behalf of the RTR bit Looks like this needs to be assured/fixed in each driver anyway. Regards, Oliver _______________________________________________ Socketcan-core mailing list [email protected] https://lists.berlios.de/mailman/listinfo/socketcan-core
