On 07/19/2011 02: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.
I'm running on an Freescale P1010 processor (QorIQ family).
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
