lkml.org 
[lkml]   [2016]   [Aug]   [11]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [PATCH RESEND] net: can: Introduce MEN 16Z192-00 CAN controller driver
From
Date


On 08/11/2016 10:58 AM, Andreas Werner wrote:
> On Thu, Aug 11, 2016 at 10:45:00AM +0200, Oliver Hartkopp wrote:


>> 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.
>>
>
> I am not sure if we have a way to change the IP but i will try to talk with
> my IC designer. He will be available next week.
>
> Your idea sounds good. I will check a few more driver to get more information
> how they did the implementation.
>

I just looked into your patch at
http://marc.info/?l=linux-can&m=146952497113100&w=2

The

struct men_z192_cf_buf {
u32 can_id;
u32 data[2];
u32 length;
};

has a u32 for the length which is masked by

#define MEN_Z192_CFBUF_LEN GENMASK(3, 0)

in men_z192_read_frame() and is just copied in men_z192_xmit()

writel(cf->can_dlc, &cf_buf->length);

as only 4 bits are used in the u32 length you probably already can use
the upper 16 bits for the discussed IFF_ECHO purpose.

Don't know how your IP core handles this u32 length when you enable the
loopback - maybe the upper 16 bits are still there in the receive path
and you can implement this idea directly :-)

Regards,
Oliver

\
 
 \ /
  Last update: 2016-08-11 14:41    [W:0.048 / U:3.040 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site