On 21.10.2010 16:56, Marc Kleine-Budde wrote: > On 10/21/2010 02:28 PM, Marc Kleine-Budde wrote: >> Moin, >> >> the socket CAN implementation allows sending of CAN frames with RTR set >> and dlc != 0. My question is what should be received? >> >> I've tested several CAN cores (sja1000, mcp2515, at91_can) and all >> receive the RTR bit and set the dlc correct, but the data is not handled >> as expected. On the at91 and mcp2515 it seems that we get the old >> mailbox data, on the sja1000 we get the old data but shifted by several >> bytes. >> >> 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? Regards, Oliver > II) somewhere in the framework, set data to 0 if RTR is set. > > cheers, Marc > > > > _______________________________________________ > Socketcan-core mailing list > [email protected] > https://lists.berlios.de/mailman/listinfo/socketcan-core _______________________________________________ Socketcan-core mailing list [email protected] https://lists.berlios.de/mailman/listinfo/socketcan-core
