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. > Thanks for testing! > > I enhanced the mail subject to wake up the maintainers ;-) Maybe Marc is on holiday. Wolfgang. _______________________________________________ Socketcan-users mailing list [email protected] https://lists.berlios.de/mailman/listinfo/socketcan-users
