On 07/19/2011 09:01 PM, Wolfgang Grandegger wrote: > Hi Oliver, > > On 07/19/2011 06:39 PM, Oliver Hartkopp wrote: >> On 19.07.2011 18:18, Mike Brown wrote: >>> On 07/19/2011 10:40 AM, Oliver Hartkopp wrote: >>>> On 19.07.2011 17:35, Mike Brown wrote: >>>>> On 07/19/2011 09:51 AM, Oliver Hartkopp wrote: >>>>>> When the sent CAN frames are not pushed into the rx queue on successful >>>>>> transmit IFF_ECHO must not be set in the device flags. >>>>> I didn't dig this deep into the flexcan driver but did got deep enough to >>>>> see >>>>> this flag being set as well. If read the SocketCAN documentation >>>>> correctly, >>>>> then if the driver doesn't set this flag then the PF_CAN layer should >>>>> handle >>>>> the loopback??? I'm trying to get a build with the flag cleared in >>>>> flexcan.c >>>> Yes - that's a good test! >>>> >>>> Feedback is appreciated :-) >>> Clearing the IFF_ECHO flag in flexcan.c fixes the problem. I can now run >>> cansend and candump on the same CAN interface. >>> >>> # candump -a can0,0:0 >>> can0 1 [1] 48 'H' >>> >>> # cansend can0 001#48 >>> # >>> >>> Safe to assume that the flexcan driver doesn't support loopback as described >>> then? >>> >>> http://lxr.linux.no/#linux+v2.6.39/Documentation/networking/can.txt#L580 >> >> Yes. Sigh. >> >> So this can be temporarily fixed by removing the line which sets IFF_ECHO ... >> but of course should be fixed by implementing the can_echo_skb stuff. > >>> dev->flags |= IFF_ECHO; /* we support local echo in hardware */ > > IIRC, loopback is really done in hardware and the driver is working > properly on ARM processors.
See: https://lists.berlios.de/pipermail/socketcan-core/2010-June/004432.html Wolfgang. _______________________________________________ Socketcan-users mailing list [email protected] https://lists.berlios.de/mailman/listinfo/socketcan-users
