linux-kernel - Re: [MeeGo-Dev][PATCH v3] Topcliff: Update PCH

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <4CB414A2.8020202@pengutronix.de>
Date:	Tue, 12 Oct 2010 09:56:18 +0200
From:	Marc Kleine-Budde <mkl@...gutronix.de>
To:	Masayuki Ohtake <masa-korg@....okisemi.com>
CC:	Wolfgang Grandegger <wg@...ndegger.com>,
	David Miller <davem@...emloft.net>,
	andrew.chih.howe.khor@...el.com, sameo@...ux.intel.com,
	margie.foster@...el.com, netdev@...r.kernel.org,
	linux-kernel@...r.kernel.org, yong.y.wang@...el.com,
	socketcan-core@...ts.berlios.de, joel.clark@...el.com,
	morinaga526@....okisemi.com, kok.howg.ewe@...el.com,
	chripell@...e.org, qi.wang@...el.com
Subject: Re: [MeeGo-Dev][PATCH v3] Topcliff: Update PCH_CAN driver to 2.6.35

Hello Masayuki,

On 10/12/2010 09:09 AM, Masayuki Ohtake wrote:
> We have implemented our CAN driver with FIFO mode, and
> We are testing our CAN driver with FIFO mode.
> However, we have found Our CAN hardware spec is different from our anticipated.
> Our CAN HW FIFO is not common FIFO.
> Using  FIFO mode, there is possibility received packets are out-of-order.

It's called a FIFO in the Documentation, but it's not a real FIFO as we
all hoped.

> e.g.
> Recv packet-A from NW and set to FIFO.
>   |A|
> 
> Recv packet-B from NW and set to FIFO.
>   |A|B|
> 
> Recv packet-C is about to set to FIFO
>   |A|B|(C)|
> 
> Userspace Copies A from Driver
> Userspace Copies B from Driver
>   |   |   |(C)|
> 
> packet-C set to FIFO (C is not head.)
> Recv packet-D from NW(Next packet is set to head)
>   |D|   |C|
> 
> Userspace Copies D from Driver
> Userspace Copies C from Driver
> Userspace raceived packet order is like below
> A-B-D-C

I just had a small peak at the datasheet. It seems you can implement the
same scheme for rx as on the at91, if you enough rx buffers. In the at91
driver I use 8+4 = 12 buffers for rx. Have a look at the driver, the rx
path is documented.

The driver uses 8 + 4 rx buffers, the trick is that a buffer in read but
_not_ marked as free, if I understand the intel datasheet correctly this
is by not resetting the NEWDAT bit. Becasue the driver doesn't free the
buffers it knows that the next CAN frame is in the next buffer. After
reading the 8th buffer, the first 8 buffers (0-7) are marked as free.
Then the driver continues to read buffers 8-11, they might have been
filled before marking 0-7 as free. Then the driver continues from the
beginning.

> So, I think normal-mode is better than FIFO-mode.

> I will revert like the following spec.
>   Rx 1 Message Object
>   Tx 1 Message Object
> 
> Could you agree the above ?

ahh common...the hardware doesn't seem that bad :)

cheers, Marc

-- 
Pengutronix e.K.                  | Marc Kleine-Budde           |
Industrial Linux Solutions        | Phone: +49-231-2826-924     |
Vertretung West/Dortmund          | Fax:   +49-5121-206917-5555 |
Amtsgericht Hildesheim, HRA 2686  | http://www.pengutronix.de   |


Download attachment "signature.asc" of type "application/pgp-signature" (263 bytes)