netdev - 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: <4CB4117C.4070207@grandegger.com>
Date:	Tue, 12 Oct 2010 09:42:52 +0200
From:	Wolfgang Grandegger <wg@...ndegger.com>
To:	Masayuki Ohtake <masa-korg@....okisemi.com>
CC:	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, mkl@...gutronix.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

Hi Ohtake,

On 10/12/2010 09:09 AM, Masayuki Ohtake wrote:
> Hi Wolfgang,
> 
> 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.
> 
> 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

OK, let's say the CPU or software starts processing the message FIFO.

> 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

The software could continues searching the FIFO for valid messages. Then
it would find C first.

> Userspace Copies C from Driver
> Userspace raceived packet order is like below
> A-B-D-C

I'm still optimistic that it could be handled properly by software, it
might be tricky though.

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

To be clear. Out-of-order reception is not allowed!

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

See above. I agree if the software cannot assure in-order reception. But
it's not yet obvious to me that it cannot be achieved. I will have a
closer look to the manual. Just one RX message object without any
further buffering is really bad as message losses are likely to happen.

Wolfgang.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html