[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1d81436b-4ad2-a34f-e2e1-accde0b16a47@hartkopp.net>
Date: Thu, 11 Aug 2016 10:45:00 +0200
From: Oliver Hartkopp <socketcan@...tkopp.net>
To: Andreas Werner <andreas.werner@....de>
Cc: Wolfgang Grandegger <wg@...ndegger.com>, mkl@...gutronix.de,
linux-can@...r.kernel.org, netdev@...r.kernel.org,
linux-kernel@...r.kernel.org, davem@...emloft.net,
jthumshirn@...e.de, andy@...nerandy.de, michael.miehling@....de
Subject: Re: [PATCH RESEND] net: can: Introduce MEN 16Z192-00 CAN controller
driver
On 08/11/2016 09:14 AM, Andreas Werner wrote:
> On Wed, Aug 10, 2016 at 10:28:45PM +0200, Oliver Hartkopp wrote:
>> Just check 'git grep IFF_ECHO'. Even grcan.c and janz-ican3.c have IFF_ECHO
>> set - but implement it in a different way without using the provided
>> machanism from dev.c .
>>
>
> Ok I am with you.
Great :-)
>> A local loopback inside the CAN controller which is generated after
>> successful transmit is an excellent implementation with excellent
>> timestamps. The only problem for you is to detect the looped CAN frames and
>> match them to the skb pointer of the outgoing frame to 'receive' the correct
>> echo skb.
>>
>
> At the moment, i think there is no way to detect those looped frames.
> I will talk to our IC designer and discuss this issue with him. Maybe we
> have the possibility to get a local loopback inside the CAN controller.
> This seems to be the best way to do it.
When you still have the possibility to change the IP core I would
suggest to create some kind of 16/32 bit value which you can pass to the
CAN controller along with the CAN frame to be sent.
And when this frame comes back due to the loopback you can use this
non-zero 16/32 bit value to match into a list of tx skb pointers for
IFF_ECHO.
E.g. when this 16/32 bit value is zero this CAN frame obviously was
received from another CAN node.
Just an idea.
Regards,
Oliver
Powered by blists - more mailing lists