Messages in this thread | | | Subject | Re: [PATCH RESEND] net: can: Introduce MEN 16Z192-00 CAN controller driver | From | Oliver Hartkopp <> | Date | Thu, 11 Aug 2016 13:46:55 +0200 |
| |
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
| |