netdev - Re: [PATCH RESEND] net: can: Introduce MEN 16Z192-00 CAN controller driver

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:	Thu, 11 Aug 2016 13:46:55 +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 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